[Home]

Summary:ASTERISK-12476: Queue timeout doesn't work when periodic-announce is set.
Reporter:Miquel Cabrespina (miquel_cabrespina)Labels:
Date Opened:2008-07-29 03:19:18Date Closed:2008-07-31 10:48:12
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13186.diff
( 1) debug_and_verbose_5.txt.gz
Description:When periodic-announce is setted and the general timeout for the queue is reached, the queue keeps trying to call its members.
When the timeout is reached the queue must finalize and go to the next priority in context but when a periodic-announce is set the queue never finalize. At queue timeout the periodic announce won't play anymore and the option "retry" is also ignored. The call remains in the queue until a member answers.

When the periodic timeout is reached we see this in the console until some member answer:
 == Spawn extension (MYCONTEXT_102, s-CHANUNAVAIL, 3) exited non-zero on 'Local/s@MYCONTEXT_102-95c1,2'

****** ADDITIONAL INFORMATION ******

I post the queue configuration:

[Q65];
musicclass = myownmusicclass
strategy = random
context = MYCONTEXT_Q65
timeout = 12
wrapuptime = 0
periodic-announce-frequency = 10
periodic-announce = pannounce
announce-holdtime = no
joinempty = no
member => Local/s@MYCONTEXT_100/n
member => Local/s@MYCONTEXT_101/n
member => Local/s@MYCONTEXT_102/n
member => Local/s@MYCONTEXT_103/n

And dialplan configuration:

exten => s,n,Queue(Q65|wWt|||30))

A Sample of the contexts that are called:

[MYCONTEXT_102]
exten => s,1,NoOp(Entering to MYCONTEXT_102)
exten => s,n,Set(RecordCall=0)
exten => s,n,Set(userOptions=PUID\=${ParentUniqueId}\;PUID_POS\=${JumpingNode}\;PUID_TYPE\=J\;REC\=${RecordCall}\;NO_STATISTICS\=FALSE)
exten => s,n,Set(GLOBAL(FORCE_ATC_DISPOSITION_${INPUT_CHANNEL})=NO ANSWER)
exten => s,n,Set(CDR(accountcode)=${TPVSTR}${idLinea}_MYCONTEXT_102)
exten => s,n,Set(GLOBAL(extension_descuelga_${INPUT_CHANNEL})=102)
exten => s,n,Set(ProposedUserfield=93xxxxxxx)
exten => s,n,Set(CDR(userfield)=${ProposedUserfield}##${userOptions}##)
exten => s,n,Set(TRANSFER_CONTEXT=MYCONTEXT_102)
exten => s,n,Set(HiddeCall=0)
exten => s,n,Dial(Zap/g2/93xxxxxxx,,otgM(force_atc_disposition^${INPUT_CHANNEL}^ANSWERED))
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s-ANSWER,1,NoOp(ANSWER)
exten => s-ANSWER,n,Hangup
exten => s-CHANUNAVAIL,1,NoOp(CHANUNAVAIL)
exten => s-CHANUNAVAIL,n,Set(GLOBAL(FORCE_ATC_DISPOSITION_${INPUT_CHANNEL})=FAILED)
exten => s-CHANUNAVAIL,n,Congestion
exten => s-BUSY,1,NoOp(BUSY)
exten => s-BUSY,n,Set(GLOBAL(FORCE_ATC_DISPOSITION_${INPUT_CHANNEL})=BUSY)
exten => s-BUSY,n,Busy
exten => s-NOANSWER,1,NoOp(NOANSWER)
exten => s-NOANSWER,n,Set(GLOBAL(FORCE_ATC_DISPOSITION__${INPUT_CHANNEL})=NO ANSWER)
exten => s-NOANSWER,n,Hangup
exten => s-CANCEL,1,NoOp(CANCEL, new state abandonada)
exten => s-CANCEL,n,Set(GLOBAL(FORCE_ATC_DISPOSITION__${INPUT_CHANNEL})=NO ANSWER)
exten => s-CANCEL,n,Hangup
exten => s-DONTCALL,1,NoOp(DONTCALL)
exten => s-DONTCALL,n,Set(GLOBAL(FORCE_ATC_DISPOSITION__${INPUT_CHANNEL})=FAILED)
exten => s-DONTCALL,n,Congestion
exten => s-TORTURE,1,NoOp(TORTURE)
exten => s-TORTURE,n,Set(GLOBAL(FORCE_ATC_DISPOSITION__${INPUT_CHANNEL})=FAILED)
exten => s-TORTURE,n,Congestion
exten => s-CONGESTION,1,NoOp(CONGESTION)
exten => s-CONGESTION,n,Set(GLOBAL(FORCE_ATC_DISPOSITION_${INPUT_CHANNEL})=FAILED)
exten => s-CONGESTION,n,Congestion
exten => s-QUEUEMEMBER,1,NoOp(QueueMember)
exten => s-QUEUEMEMBER,n,ExecIf($["${DIALSTATUS}" != "ANSWER"],NoCDR)
exten => s-QUEUEMEMBER,n,ExecIf($["${DIALSTATUS}" = "ANSWER"],Goto,s-FINALIZE,1)
exten => s-FINALIZE,1,Set(proposedAmaflags=default)
exten => s-FINALIZE,n,ExecIf($["${RecordCall}" = "1"],Set,proposedAmaflags=billing)
exten => s-FINALIZE,n,Set(CDR(amaflags)=${proposedAmaflags})
exten => s-FINALIZE,n,Set(userOptions=PUID\=${ParentUniqueId}\;PUID_POS\=${JumpingNode}\;PUID_TYPE\=E\;REC\=${RecordCall}\;HANGUPCAUSE=${HANGUPCAUSE}\;DIALSTATUS=${DIALSTATUS}\;NO_STATISTICS\=FALSE)
exten => s-FINALIZE,n,Set(CDR(userfield)=${ProposedUserfield}##${userOptions}##)
exten => s-FINALIZE,n,ExecIf($["${TPVSTR}" != ""],System,/home/eagertech/update_tpv_sql.php \"${ParentUniqueId}\" \"${EPOCH}\" \"0\" \"${ProposedUserfield}\" &)

exten => h,1,GotoIf($["${queueChild}" = "1"]?s-QUEUEMEMBER,1)
exten => h,n,Goto(s-FINALIZE,1)
Comments:By: Mark Michelson (mmichelson) 2008-07-29 10:01:17

I could not reproduce this problem on my test box. Could you provide a complete console log with debug and verbosity set at least at 5? Thanks.
By: Miquel Cabrespina (miquel_cabrespina) 2008-07-29 10:41:04

Thanks for your attention and your quickly answer.
By: Mark Michelson (mmichelson) 2008-07-29 13:20:11

I took a brief look through your log, and one thing that jumped out at me were lines like the following:

"-- Nobody picked up in 12000 ms"

This is perfectly normal since you have timeout=12 in your queue. Later in the log, though, the time indicated increases, so you end up with lines like the following:

"-- Nobody picked up in 122000 ms"

This is very strange, and I have no idea how that could happen. I at least have something to try to look for now. I also tried mimicking your dialplan more closely, but I still have not been able to reproduce the problem locally.
By: Miquel Cabrespina (miquel_cabrespina) 2008-07-30 05:07:05

This problem only appears when property "periodic-announce" is set.
By: Mark Michelson (mmichelson) 2008-07-30 14:15:18

I have uploaded a patch that allows for app_queue to check for timeout conditions more frequently than before. Hopefully this will cause your issue to stop. Please give it a test and let me know what happens. Thanks
By: Miquel Cabrespina (miquel_cabrespina) 2008-07-31 03:02:28

Thanks for your time, your patch does work in my test box.
By: Digium Subversion (svnbot) 2008-07-31 10:48:09

Repository: asterisk
Revision: 134758

U   branches/1.4/apps/app_queue.c

------------------------------------------------------------------------
r134758 | mmichelson | 2008-07-31 10:48:08 -0500 (Thu, 31 Jul 2008) | 16 lines

Add more timeout checks into app_queue, specifically
targeting areas where an unknown and potentially
long time has just elapsed. Also added a check
to try_calling() to return early if the timeout
has elapsed instead of potentially setting a negative
timeout for the call (thus making it have *no* timeout
at all).


(closes issue ASTERISK-12476)
Reported by: miquel_cabrespina
Patches:
     13186.diff uploaded by putnopvut (license 60)
Tested by: miquel_cabrespina


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=134758