1

We have an application written against Mobicents SIP Servlets, currently this is using v2.1.547 but I have also tested against v3.1.633 with the same behavior noted.

Our application is working as a B2BUA, we have an incoming SIP call and we also have an outbound SIP call being placed to an MRF which is executing VXML. These two SIP calls are associated with a single SipApplicationSession - which is the concurrency model we have configured.

The scenario which recreates this 100% of the time is as follows:

  • inbound call placed to our application (call is not answered)
  • outbound call placed to MRF
  • inbound call hangsup
  • application attempts to terminate the SipSession associated with the outbound call

I am seeing this being logged:

2015-12-17 09:53:56,771 WARN [SipApplicationSessionImpl] (MSS-Executor-Thread-14) Failed to acquire session semaphore java.util.concurrent.Semaphore@55fcc0cb[Permits = 0] for 30 secs. We will unlock the semaphore no matter what because the transaction is about to timeout. THIS MIGHT ALSO BE CONCURRENCY CONTROL RISK. app Session is5faf5a3a-6a83-4f23-a30a-57d3eff3281c;SipController

I am willing to believe somehow our application might be triggering this behavior but I can't see how at the moment. I would have thought acquiring/releasing the Semaphore was all internal to the implementation so it should ensure something doesn't acquire the Semaphore and never release it?

Any pointers on how to get to the bottom of this would be appreciated, as I said it is 100% repeatable so getting logs etc is all possible.

James Mullen
  • 51
  • 2
  • 3

1 Answers1

0

It's hard to tell without seeing any logs or application code on how you access and schedule messages to be sent. But if you use the same SipApplicationSession in an asynchronous manner you may want to use our vendor specific asynchronous API https://mobicents.ci.cloudbees.com/job/MobicentsSipServlets-Release/lastSuccessfulBuild/artifact/documentation/jsr289-extensions-apidocs/org/mobicents/javax/servlet/sip/SipSessionsUtilExt.html#scheduleAsynchronousWork(java.lang.String,%20org.mobicents.javax.servlet.sip.SipApplicationSessionAsynchronousWork) which will guarantee that the access to the SipapplicationSession is serialized and avoid any concurrency issues.

jeand
  • 2,325
  • 14
  • 12
  • Thanks @jeand for the reply. – James Mullen Dec 23 '15 at 15:26
  • I've grabbed a log file from this occurring which you can grab from here : [link](https://www.dropbox.com/s/owbmgcw100a5mfw/mobicents_semaphore_issue.20151223?dl=0) The point at which the Semaphore is acquire and not released quickly after appears here: >2015-12-23 14:50:43,627 DEBUG [SipStandardContext] (http-bio-8000-exec-5) acquiring sipApplicationSession=262ffec0-d389-4cba-9468-f8500ec865d8;SipController since it is not present in our local thread of accessed sip application sessions At this point our application only appears to be getting a value from the session. – James Mullen Dec 23 '15 at 15:34