Domenico,
Let me see if I got this right. Reading the implementation of
SipProtocolServerBase::handleMessage(OsMsg& eventMessage) the only event
it is concerned with is of subtype SipProtocolServerBase::SIP_SERVER_GC
it eventually calls removeOldClients(0);
Grepping for removeOldClients in the entire sipXtackLib, it is already
called within SipUserAgent::garbageCollection() method which is called
from SipUserAgent::handleMessage(). I believe that this should be the
only place where garbage collection must be performed to avoid mutex
contentions or worse, deadlocks.
My recommendation is to still override the run method of the
SipTcpServer but to simply consume the event message without calling
handleMessage. This will make it evident to delevelopers looking at the
code later on that the run loop of the TCP server is meant to not handle
anything (as it is now). The second recommendation is (I know you
already suggested this to George) that the SipClient should never post a
SipProtocolServerBase::SIP_SERVER_GC and instead rely on the centralized
garbage collection performed by the SipUserAgent::garbageCollect() method.
Infact, the comment in SipClient post event is quite scary.
if (mpSipServer)
{
OsMsg message(OsMsg::OS_EVENT,
SipProtocolServerBase::SIP_SERVER_GC);
// If the SipServer's queue is full, don't wait, since
// that can cause deadlocks. The SipServer will eventually
// garbage-collect terminated clients spontaneously.
mpSipServer->postMessage(message,
OsTime::NO_WAIT);
}
Comments?
Joegen
On 04/28/2011 12:06 AM, Domenico Chierico wrote:
I was working on XX-8063 point (d
d-KERNEL:ERR:firstsoak.qantom.int:SipClientTcp:SipXProxy:"OsMsgQShared::doSendCore
message send failed for queue 'SipTcpServer-3' - no room, ret = 9"
this behaviour depend on some fact:
a) the SipTcpServer is service that don't run (start is never called on it)
b) SipClient sends a OsMsg to the SipTcpServer when it stops itself
c) the SipTcpServer is not running (nor ready to manage events on his queue)
so there are 2 possible solutions to the problem,
1) the simpler is to comment the send of OsMsg into sipclient so no such event
will go to the queue.
2) the second is to run SipTcpServer's main loop and fix the event handling.
The decision between those 2 solutions needs to be evaluated by someone with
more knowledge on the overall system.
I have attached here a patch[1] for the second solution.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
