#33 ✓hold
Jay Phillips

Call Threads waiting for with_next_message() hang indefinitely

Reported by Jay Phillips | August 29th, 2008 @ 02:12 AM

When a dialplan Thread is sleeping due to with_next_message(), a call hangup will NOT kill the Thread. The Thread stays alive for as long as the process does.

For the time being, this can be worked-around by manually catching hangups via AMI and sending a message to the dialplan which causes it to exit gracefully.

The framework-level solution I believe is to subclass the Queue class and use this custom subclass in for Call#inbox(). It will override the Queue#<<() method with an implementation that checks for the :cancel symbol and sets a property in the Queue subclass to disable any further use of with_next_message() by raising an exception. The :cancel message is still passed along to the Queue.

The documentation of with_next_message() (and its supporting methods) should mention that :cancel can be sent at any time.

Comments and changes to this ticket

  • Jay Phillips

    Jay Phillips September 18th, 2008 @ 09:51 PM

    • State changed from “new” to “open”
    • Tag changed from dialplan to dialplan
  • Jay Phillips
  • Jay Phillips

    Jay Phillips March 29th, 2009 @ 08:24 PM

    • Title changed from “Call Threads waiting for a message hang indefinitely” to “Call Threads waiting for with_next_message() hang indefinitely”
  • Alexander Pilafian

    Alexander Pilafian May 17th, 2009 @ 04:49 PM

    I fixed this bug on my github fork of adhearsion (username sikanrong, of course), have requested a pull - anyway you should add me to the project so I can reassign or close bugs myself!

  • Alexander Pilafian

    Alexander Pilafian May 17th, 2009 @ 04:51 PM

    oh right, and in my last comment - that attachment is a really simple adhearsion app that will fail before my commit and pass afterwards. it's like a test case (for now), although i didn't actually write any spec yet. If you run the app before the commit, when you hang up the thread continues until you manually kill adhearsion. After my changes, the thread gracefully quits when you hang up. woohoo!!

  • Alexander Pilafian

    Alexander Pilafian May 20th, 2009 @ 07:22 AM

    so, i updated my commit after discussing with jay.

    Now, the auditing for the agi server is turned on such that the overridable methods are accessible, like 'disconnecting', which is what i now use to pass the :cancel signal to the call messaging queue.

    The problem (still) is that the 'disconnecting' message from AGI will not actually get called until AFTER the serve call is finished, which is a big problem. SO, in the end,

    unless we make a new thread to actually send NOOP messages to agi to check for disconnection manually, we can not send the correct message to kill the queue and have adhearsion exit gracefully (unless you count AMI).

    On the flip side of all this though, pure-agi stuff will work just fine, so long as the user doesn't do something as stupid as

    with_next_message{|msg| puts msg.to_s}

    ...or something similar. not sure if it's even worth it to safeguard against this.

  • Jay Phillips

    Jay Phillips June 4th, 2009 @ 02:57 AM

    This just has to check the socket connections status. When the GServer socket disconnects, it should just update the Call object and put its inbox into the "closed" state.

  • Ben Langfeld

    Ben Langfeld September 21st, 2011 @ 04:05 PM

    • State changed from “open” to “hold”
    • Milestone order changed from “0” to “0”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Shared Ticket Bins

People watching this ticket