[asterisk-dev] Asterisk Beacon Module Proposal

[George Joseph]

On Tue, May 12, 2015 at 10:59 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>
wrote:

> On Tue, May 12, 2015 at 10:39:04AM -0600, George Joseph wrote:
> > On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
> >
> > > On Tue, May 12, 2015 at 9:47 AM, George Joseph
> > > <george.joseph at fairview5.com> wrote:
> > > > On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen <
> tzafrir.cohen at xorcom.com
> > > >
> > > > wrote:
> > > >>
> > > >> On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote:
> > > >>
> > > >> > As for the other issues, why not just have asterisk fork itself on
> > > >> > startup
> > > >> > and reloads just to send the stats.  No separate executables, no
> AMI,
> > > no
> > > >> > cron, and you get the process separation so a segv or orthe rerror
> > > >> > doesn't
> > > >> > kill the main process.
> > > >> >
> > > >> > KISS!
> > > >>
> > > >> This makes it part of the asterisk service, as far as systemd is
> > > >> concerned.
> > > >
> > > > Is that a bad thing?  Did I miss something in the email chain?
> > >
> > > I wouldn't call it a "bad" thing, it's just an implementation choice
> > > that has its pluses and minuses.  If the main Asterisk process forks a
> > > copy of itself systemd will track the subprocess and kill it off when
> > > shutting down the main service.  However, you then need to add to
> > > Asterisk code to keep track of the subprocess, reap the process if the
> > > subprocess dies and restart the subprocess.  You'd still need some
> > > sort of remote API for the subprocess to gather the statistics from
> > > the main process, but it wouldn't have to be stable, even between
> > > minor releases, because each side would always be running the same
> > > code..
> > >
> > > Personally, I'd go with an external process that's a separate binary
> > > (or could even be written in a scripting language) that talks to an
> > > API presented by Asterisk.  The stats API would need to be a little
> > > more stable, but that wouldn't be a bad thing either.
> > >
> > >
> > Hmmm.  It just seems to me we're way over thinking this.   Separate
> > executables and a public APIs seems overkill for something that on;y
> needs
> > to run for a few seconds on startup and reload.
>
> Why does it only need to run on startup and reload? Shouldn't it
> send stats periodically?
>
>
The only volatile stats to be reported were active/total calls and I'd be
willing to give that up to keep the process simple.   Even if we did keep
the calls, and it reported a few times a day I still don't see the need for
 the complexity.   I don't want to have to set up cron jobs and worry about
extra services or have to go through exposing new APIs.  In the time we've
been discussing this, a basic module that does what we needed could have
been written.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150512/e996f492/attachment.html>