On 04/29/2011 11:16 PM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Joegen Baclor > [[email protected]] > > So I think the safest move (might not be the most elegant) is > to preserve the status quo and just get rid of the nasty queue is full > error message. > _______________________________________________ > > I hope you don't mean to prevent queue full situations from being logged. > There is a *reason* we put > that message in: If a queue fills and chokes the process so it doesn't do > any useful work, then there > is some way to determine *which* queue filled, and thus, which thread has > gotten blocked, so we have > some hope of finding and solving the problem. > > Dale Hi Dale,
Thanks for chiming in. I certainly did not mean "to prevent queue full situations from being logged". I apologize for being vague. What I mean is to get rid of the bug that causes that piece of log to appear when SipTcpClient objects are destroyed. The queue that is being filled up is the SipTcpServer queue which is not doing anything in the run method except wait for the exit event. In fact, SipTcpServer is not even start()'ed prior to the patch. This has been a long standing bug but is considered benign and is one of the items pointed out in this task (http://track.sipfoundry.org/browse/XX-8063). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
