On Tue, 2010-03-02 at 14:29 -0500, Dale Worley wrote:
> Currently, there is a problem in sipXrls, in that it tends to deadlock
> when the BLF lists are changed. The recent examples of this have all
> involved overflowing of message queues of threads that process
> subscriptions. This is caused by the tremendous size of the special
> ~~rl~F~~~id~xmpprlsclient resource list and the fact that the RLS does
> not incrementally change its internal list structure when the config
> file changes; it destroys and recreates all lists. This simple strategy
> causes a flurry of subscription creation/destruction when any change is
> made to the BLF lists, which risks overflowing the message queues of the
> threads which process subscription activity.
>
> I propose that we improve sipXrls to more incrementally update resource
> lists when they are changed as a way to reduce message traffic and avoid
> deadlocking.
>
> Comments?
Seems like a good idea.
It seems to me that it could do something like what the plugin classes
do on recreation:
* Move the existing active subscriptions to a temporary list
* For each element of the new configuration, check to see if there
is an existing subscription on the temporary list:
* if so move it back to the active list
* if not, create a new subscription on the active list
* When all of the new configuration has been processed, terminate
any subscriptions still on the temporary list
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
