[Asterisk-Dev] Asterisk Manager Interface losing events

C. Maj cmaj-SPAM at freedomcorpse.com
Mon May 9 09:18:00 MST 2005


On Sun, 8 May 2005, Tilghman Lesher waxed:

> On Sunday 08 May 2005 09:39, Geoff Nordli wrote:
> > > Geoff Nordli wrote:
> > > >I am building application that sits on the management interface
> > > > tracking all the events.
> > > >
> > > >Occasionally an event is misses which causes the application to
> > > > get out of sync with what is happening on the Asterisk side.
> > >
> > >Daniel Pocock wrote:
> > > I've seen this too.
> >
> > I am currently using the 1.0.7 stable.  Have any changes been made
> > on HEAD that would solve this?
>
> No, there haven't.  The main problem, I think, is that all messages
> are written to the remote client with ast_careful_write, which
> specifies a timeout and does not retry.  What probably needs to be
> done is to create a new thread for each client (not each message,
> as another poster suggested), which continually retries an output
> buffer.

To clarify, each client currently gets a new session thread
upon connection to the manager server socket.  What I am
proposing is a new thread to handle sending of events to
each of those connected session threads.  This would take
the responsibility away from the code calling manager_event.

Instead of waiting on the session lock to notify all those
sessions, it would wait on the new thread's pending message
queue lock.  There would be very little contention for this
new lock compared to the session lock because there's a lot
less work involved in just adding messages to a queue than
vs. calling ast_careful_write.  And it makes retries easier.

> In addition, we should probably write it as a double buffer:  the
> first for messages to be sent immediately, and the second for
> messages that are sent while ->blocking is set (which is set during

That makes sense.  It could also allow for interleaving the
response/event stuff, by issuing a "break" and "continue"
during responses when there's an event sent during a long
response.  You could just check the event buffer while in
the response loop.

> all responses to an Action).  Currently, any event which is attempted
> during a Response is simply dropped on the floor, instead of being
> retried.

I didn't realize that about events during responses, thanks.

--Chris


-- 
Chris Maj, Rochester
cmaj_at_freedomcorpse_dot_com
Pronunciation Guide: Maj == May



More information about the asterisk-dev mailing list