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? Dale _______________________________________________ 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/
