stipus wrote:
> Yes, I just saw that some of the calls are stuck in dropping state.
> 
> I also found the reason for the "Failed to find call to remove from stack"
> Message:
> 
> In CallManager::handleMessage() case CP_CALL_EXITED you can find:
>   call = removeCall(call) --> this one always succeeds
>   if( call ) delete call; --> this one runs CpPeerCall::~CpPeerCall()
> 
> and in CpPeerCall::~CpPeerCall() I can find:
> if( mpManager) mpManager->onCallDestroy( this );
> 
> and in CallManager::onCallDestroy()
> call = removeCall( call )  --> This one always fail with the message "Failed
> to find call to remove from stack"
> 
> ... still searching !!!
> 

The deadlock is from CpPeerCall->OsNatAgentTask::destroyBinding -> there
we try to stop a timer, but stopping a timer requires confirmation from
OsTimerTask. But OsTimerTask is trying to send a message to a queue that
is full (SipUserAgent), thus is blocked. SipUserAgent is trying to
acquire lock on mMapsLock, which is already taken by CpPeerCall. So we
have a circle and are blocked.

I made a hack by not stopping the timer in destroyBinding synchronously,
but asynchronously, without returing it to pool, but then I got a
deadlock elsewhere, again connected to stopping a timer.

Until something is done with timers, your only option is to make
SipUserAgent queue very long or unlimited, and not to put your
application under such high load.

>From what I have seen, there are many circles connected through OsTimer
and OsTimerTask, so something will have to be done to stop requiring
confirmation from OsTimerTask to OsTimer. These circles have to be cut
between OsTimer and OsTimerTask.

SipUserAgent is currently using a queue of size 100. But once we run out
of free space, OsTimerTask becomes blocked too, as it is trying to send
a message to SipUserAgent queue which is full. This is a very serious
problem, as then all times become very inaccurate.

Jaro
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

Reply via email to