2015-12-23 2 views
1

Nous avons une application écrite contre les servlets Mobicents SIP, actuellement cela utilise v2.1.547 mais j'ai aussi testé contre v3.1.633 avec le même comportement noté.Erreur de sémaphore connectée à la servlet mobicents sip

Notre application fonctionne en B2BUA, nous avons un appel SIP entrant et nous avons également un appel SIP sortant qui est placé vers un MRF qui exécute VXML. Ces deux appels SIP sont associés à un seul SipApplicationSession - qui est le modèle de concurrence que nous avons configuré.

Le scénario qui reconstitue ce 100% du temps est la suivante:

  • appel entrant placé à notre application (appel ne répond pas)
  • appel sortant placé pour MRF
  • appel entrant hangsup
  • application tente de mettre fin à la SipSession associée à l'appel sortant

Je suis Voyant cela étant connecté:

2015-12-17 09: 53: 56771 WARN [SipApplicationSessionImpl] (MSS-Exécuteur-thread-14) pas parvenus à acquérir sémaphores session [email protected] [Permis = 0] pendant 30 secondes. Nous allons débloquer le sémaphore, quoi qu'il arrive, car la transaction est sur le point d'expirer. CECI PEUT AUSSI ÊTRE RISQUE DE CONTRÔLE DE LA CONCURRENCE. application Session is5faf5a3a-6a83-4f23-A30a-57d3eff3281c; SipController

Je suis prêt à croire en quelque sorte notre application pourrait être le déclenchement de ce comportement, mais je ne peux pas voir comment le moment. J'aurais pensé que l'acquisition/libération du sémaphore était interne à la mise en œuvre, donc il faudrait s'assurer que quelque chose n'acquiert pas le sémaphore et ne le libère jamais?

Tout pointeur sur la façon d'arriver au fond de ce serait apprécié, comme je l'ai dit, il est répétable à 100%, donc l'obtention des journaux, etc est tout possible.

Répondre

0

Il est difficile de dire sans voir les journaux ou le code de l'application sur la façon dont vous accédez et planifiez les messages à envoyer. Mais si vous utilisez le même SipApplicationSession d'une manière asynchrone, vous pouvez utiliser notre API asynchrone spécifique au fournisseur 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) qui garantira que l'accès à SipapplicationSession est sérialisé et évitera les problèmes de simultanéité.

+0

Merci @jeand pour la réponse. –

+0

J'ai attrapé un fichier journal de ce qui se produit que vous pouvez prendre à partir d'ici: [link] (https://www.dropbox.com/s/owbmgcw100a5mfw/mobicents_semaphore_issue.20151223?dl=0) Le point auquel le sémaphore est acquérir et pas publié rapidement après apparaît ici: > 2015-12-23 14: 50: 43,627 DEBUG [SipStandardContext] (http-bio-8000-exec-5) l'acquisition de sipApplicationSession = 262ffec0-d389-4cba-9468- f8500ec865d8; SipController car il n'est pas présent dans notre thread local de sessions d'applications SIP accédées À ce stade, notre application semble seulement obtenir une valeur de la session. –