Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Applications/app_queue
    • Labels:
      None
    • Mantis ID:
      4244
    • Regression:
      No

      Description

      If Agents make a attended transfer of a incoming call or queue-call (zap) to another queue, the queue_app stops responding after a while.
      This will eventually bring all comunication to a halt.

                • ADDITIONAL INFORMATION ******

      Incoming calls from Zap interface
      Agents logged on using AgentcallbackLogin on a cisco 7960 (SIP) from where the att. transfer is also initiated.
      The time between the attended transfer and the queue going into "non resonding mode" seems to be between "immediately" and several hours
      This behaviour has been observed om stable releases 1.0.2, 1.0.5, 1.0.7
      This Deadlock trigered by extension 8162

      1. bug_queue_log.txt
        0.7 kB
      2. dump7.dat
        75 kB
      3. queue_log_cvshead.txt
        0.4 kB
      4. queue_log_stable.txt
        0.4 kB

        Activity

        Hide
        Armando Leal added a comment -

        I just noticed something today, if I call queues with a SIP/ there is no deadlocks, but if I call them with Local/ they appear each time.

        messages:Oct 20 07:45:33 WARNING[2324] channel.c: Avoided initial deadlock for '0x41000c10', 10 retries!
        messages:Oct 20 09:39:28 WARNING[2324] channel.c: Avoided initial deadlock for '0x81d2f10', 10 retries!
        messages:Oct 20 09:51:09 WARNING[2324] channel.c: Avoided initial deadlock for '0x81cea68', 10 retries!
        messages:Oct 20 09:55:02 WARNING[2324] channel.c: Avoided initial deadlock for '0x81c2d20', 10 retries!
        messages:Oct 20 09:55:20 WARNING[2324] channel.c: Avoided initial deadlock for '0x81cb4c8', 10 retries!

        score*CLI> show queues
        cobranza has 0 calls (max unlimited) in 'rrmemory' strategy (12s holdtime), W:3, C:37, A:53, SL:2.7% within 0s
        Members:
        Local/504 (dynamic) (available) has taken 5 calls (last was 66 secs ago)
        No Callers

        so maybe there is the problem.

        Show
        Armando Leal added a comment - I just noticed something today, if I call queues with a SIP/ there is no deadlocks, but if I call them with Local/ they appear each time. messages:Oct 20 07:45:33 WARNING [2324] channel.c: Avoided initial deadlock for '0x41000c10', 10 retries! messages:Oct 20 09:39:28 WARNING [2324] channel.c: Avoided initial deadlock for '0x81d2f10', 10 retries! messages:Oct 20 09:51:09 WARNING [2324] channel.c: Avoided initial deadlock for '0x81cea68', 10 retries! messages:Oct 20 09:55:02 WARNING [2324] channel.c: Avoided initial deadlock for '0x81c2d20', 10 retries! messages:Oct 20 09:55:20 WARNING [2324] channel.c: Avoided initial deadlock for '0x81cb4c8', 10 retries! score*CLI> show queues cobranza has 0 calls (max unlimited) in 'rrmemory' strategy (12s holdtime), W:3, C:37, A:53, SL:2.7% within 0s Members: Local/504 (dynamic) (available) has taken 5 calls (last was 66 secs ago) No Callers so maybe there is the problem.
        Hide
        raarts added a comment -

        Yes, there definitely is a problem with Local. When we were using
        the Local channel, we experienced deadlocks twice a day. Since we
        stopped using them we experience them once every three days.

        So there are multiple causes for deadlocks.

        Show
        raarts added a comment - Yes, there definitely is a problem with Local. When we were using the Local channel, we experienced deadlocks twice a day. Since we stopped using them we experience them once every three days. So there are multiple causes for deadlocks.
        Hide
        Armando Leal added a comment -

        this bug is fixed on beta-2?, let me try out!!

        Show
        Armando Leal added a comment - this bug is fixed on beta-2?, let me try out!!
        Hide
        Chris A. Icide added a comment -

        I'm getting this error under CVS Head from 2005-11-03 (pulled it around 8pm Pacific time).

        I was getting it before under using HEAD from 2005-08-28. I've not been able to track it down to anything specific yet. I have a pretty complicated dialplan and high traffic load. It seems to start intermittently with a few 'channel.c:783 channel_find_locked:' then shortly thereafter I get them anytime a call is attempted, and the system continues to run, but no calls can be processed, and issueing a stop or restart command at the CLI results in a CLI that takes commands but doesn't do anything.

        Show
        Chris A. Icide added a comment - I'm getting this error under CVS Head from 2005-11-03 (pulled it around 8pm Pacific time). I was getting it before under using HEAD from 2005-08-28. I've not been able to track it down to anything specific yet. I have a pretty complicated dialplan and high traffic load. It seems to start intermittently with a few 'channel.c:783 channel_find_locked:' then shortly thereafter I get them anytime a call is attempted, and the system continues to run, but no calls can be processed, and issueing a stop or restart command at the CLI results in a CLI that takes commands but doesn't do anything.
        Hide
        Russell Bryant added a comment -

        If anyone is still seeing a problem in cvs head or 1.2, please open a new bug.

        Show
        Russell Bryant added a comment - If anyone is still seeing a problem in cvs head or 1.2, please open a new bug.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development