[Asterisk-java-users] Live's channel processing when reconnecting (was: AsteriskServerImpl reconnect processing)

[Stefan R. <ste...@re...>]

> I see that AsteriskServerImpl upon reconnects to the Asterisk server wi=
ll
> clears all the Channels in memory and do nothing about the
> originateCallBacks (it might have quite a number of callbacks registere=
d
> and they won't be freed until removed from originateCallbacks).
>=20
> l think we should only remove channels that are no longer returned by
> StatusAction() and also remove the callbacks that don't have any
> corresponding channels.

This one is really tricky.

You are right that a bunch of bugs are triggered in the live package
when a reconnect occurs. This mostly results in memory leaks due to
listeners not being removed.

Besides that the current reconnect behaviour is far too simplistic. It
simply removes all live objects and creates new ones based on Asterisk's
current state.
What can really happen to a LiveObject while we were disconnected is:
a) it has been removed (user hang up, config was changed so that a queue
no longer exists and so on)
b) state has changed (channel was linked to another, ...)
c) a new one has been created (new channel, etc.)

I think we have to somehow inform the users of the library of these
changes so they can act appropriatly. This is currently not done at all
resulting in lots of logic needed within the client to support reconnect
situations.

Especially a) and c) are tricky here: We don't receive all state changes
(e.g. extensions a channel has visited while we were disconnected) and
the time a channel was removed (which might be interesting to clients
that do accounting based on the state changes they receive). c) is less
problematic as it equals the situation we have when we initially connect
to Asterisk.
What we have though is a new and consistent state that we retrieve from
Asterisk (e.g. the result of the StatusAction for channels). So we could
synthesize events based on a diff of the state before we got
disconnected and the current state. These synthesized events could be
delivered to the client through the listener approach we already have in
place.
As far as I can see this is not a trivial task at all, but I don't see
much alternatives.

I would be very glad to receive your thoughts on this issue.

=3DStefan

--=20
reuter network consulting
Neusser Str. 110
50760 Koeln
Germany
Telefon: +49 221 1305699-0
Telefax: +49 221 1305699-90
E-Mail:  ste...@re...
Jabber:  ste...@re...