[asterisk-bugs] [Asterisk 0012884]: Queue is treated as empty if it isn't, but no agents meet the QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY criteria
noreply at bugs.digium.com
noreply at bugs.digium.com
Fri Jul 11 02:29:26 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12884
======================================================================
Reported By: bcnit
Assigned To: putnopvut
======================================================================
Project: Asterisk
Issue ID: 12884
Category: Applications/app_queue
Reproducibility: always
Severity: minor
Priority: normal
Status: ready for testing
Asterisk Version: 1.6.0-beta9
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 06-18-2008 12:19 CDT
Last Modified: 07-11-2008 02:29 CDT
======================================================================
Summary: Queue is treated as empty if it isn't, but no agents
meet the QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY criteria
Description:
In a situation where a call is placed into a queue as follows:
exten => s,n,Set(QUEUE_MAX_PENALTY=1)
exten => s,n,Set(QUEUE_MIN_PENALTY=1)
exten =>
s,n,Queue(${ORGCODE}_${ORGQUEUE},ih,,${ORGCODE}/announce-incoming)
)
The queue is deemed to be empty if there are no agents with a penalty of 1
as a member of the queue.
We use queuerules.conf to raise the QUEUE_MAX_PENALTY value to overflow
calls to other departments and in our case (and I can imagine, other
people's too), it is perfectly legitimate to have members with a penalty of
2 logged in and no members with penalty 1.
As a result of this, the function QUEUE_MEMBER() returns incorrect data
(i.e. QUEUE_MEMBER(free) may return the "number of logged-in members for
the specified queue available to take a call" as 10, but in reality and
because of the penalty issue, it is zero.
I have been able to work around this by checking QUEUE_MEMBER(count) after
I receive a JOINEMPTY bounce out, incrementing QUEUE_MAX_PRIORITY and
trying again, but this is far from ideal!
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0012880 Queue() uses cached information to dete...
======================================================================
----------------------------------------------------------------------
bcnit - 07-11-08 02:29
----------------------------------------------------------------------
Major problem. It's started core dumping.
It was working absolutely fine until the middle of the day yesterday when
it started crashing Asterisk:
e.g.
-------------------8<------------------
-- SIP/agent774-01bcf781 is ringing
-- SIP/agent323-09c2adf1 is ringing
-- SIP/agent774-01bcf781 is ringing
-- SIP/agent323-09c2adf1 is ringing
-- SIP/agent774-01bcf781 is ringing
-- SIP/agent323-09c2adf1 is ringing
-- SIP/agent774-01bcf781 is ringing
-- SIP/agent323-09c2adf1 is ringing
-- Nobody picked up in 10000 ms
-- Nobody picked up in 10000 ms
-- Nobody picked up in 10000 ms
pbx13*CLI>
Disconnected from Asterisk server
-------------------8<------------------
and
-------------------8<------------------
-- SIP/agent380-09cb3899 is ringing
-- SIP/agent714-09c5de09 is ringing
-- SIP/agent380-09cb3899 is ringing
-- SIP/agent714-09c5de09 is ringing
-- SIP/agent380-09cb3899 is ringing
-- SIP/agent714-09c5de09 is ringing
-- SIP/agent380-09cb3899 is ringing
-- SIP/agent714-09c5de09 is ringing
-- Nobody picked up in 10000 ms
-- Nobody picked up in 10000 ms
-- Nobody picked up in 10000 ms
pbx13*CLI>
Disconnected from Asterisk server
-------------------8<------------------
This is a production box and I hadn't removed optimisation when I compiled
it, so although I have the dumps, I imagine they'd be useless.
I reverted to the original app_queue.c and it's been OK overnight and this
morning so far.
Issue History
Date Modified Username Field Change
======================================================================
07-11-08 02:29 bcnit Note Added: 0090071
======================================================================
More information about the asterisk-bugs
mailing list