我们有针对Mobicents SIP Servlets编写的应用程序,目前使用的是v2.1.547,但我也针对v3.1.633进行了测试,注意到了相同的行为。
我们的应用程序作为B2BUA工作,我们有一个传入的SIP呼叫,我们还有一个出站SIP呼叫被放置到正在执行VXML的MRF。这两个SIP调用与单个SipApplicationSession相关联 - 这是我们配置的并发模型。
在100%的时间内重新创建此场景的场景如下:
我看到这是记录的:
2015-12-17 09:53:56,771 WARN [SipApplicationSessionImpl](MSS-Executor-Thread-14)无法获取会话信号量java.util.concurrent.Semaphore@55fcc0cb [Permits = 0] 30秒。我们将解锁信号量,无论因为事务即将超时。这可能也是一种控制风险。 app Session is5faf5a3a-6a83-4f23-a30a-57d3eff3281c; SipController
我愿意相信某种程度上我们的应用程序可能会引发这种行为,但我现在无法看到它。我本以为获取/发布Semaphore都是实现的内部因此它应该确保某些东西不能获得信号量而永远不会释放它?
关于如何到达底部的任何指示都会受到赞赏,因为我说它是100%可重复的,所以获取日志等都是可能的。
答案 0 :(得分:0)
如果没有看到有关如何访问和安排发送消息的日志或应用程序代码,很难说清楚。但是,如果以异步方式使用相同的SipApplicationSession,则可能需要使用我们的供应商特定的异步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),这将保证对SipapplicationSession的访问被序列化并避免任何并发问题。