[Home]

Summary:ASTERISK-14516: stateinterface in queues.conf makes the member show "Invalid"
Reporter:Benny Amorsen (amorsen)Labels:
Date Opened:2009-07-23 09:32:22Date Closed:2009-07-24 14:45:33
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In queues.conf I have:

[1]
member => Local/1@DialAccount,,,Local/1@DialAccount
[2]
member => Local/2@DialAccount,,,Local/1234567890123456789012345678901234567890@DialAccount

Right after starting asterisk:
vpbx05*CLI> queue show 1
1            has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime), W:0, C:0, A:0, SL:0.0% within 0s
  Members:
     Local/1@DialAccount (Not in use) has taken no calls yet
  No Callers

vpbx05*CLI> queue show 2
2            has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime), W:0, C:0, A:0, SL:0.0% within 0s
  Members:
     Local/2@DialAccount (Invalid) has taken no calls yet
  No Callers

Notice that Local/2@DialAccount is Invalid, whereas Local/1@DialAccount is Not in use.

I also get this in /var/log/asterisk/messages:
[Jul 23 16:28:56] DEBUG[4263] chan_local.c: Checking if extension 1234567890123456789012345678901234567890@DialAccoun exists (devicestate)

Comments:By: Tomás Laureano Peralta Tormey (laureano) 2009-07-23 10:16:17

Could you please paste the output of the following CLI command:
dialplan show 1234567890123456789012345678901234567890@DialAccount

I tested this in 1.4.25.1 and if there is a dialplan like:
[DialAccount]
exten => 1234567890123456789012345678901234567890,1,Dial(SIP/7099)

"queue show 1" reports the member "Local/2@DialAccount" as "Not in use", but if I comment out the exten line; then I get "Invalid".
By: Benny Amorsen (amorsen) 2009-07-23 11:05:23

It's true that the lack of a proper extension line will (quite correctly) cause the state to be "Invalid". However, that is not the case here:

vpbx05*CLI> dialplan show 1234567890123456789012345678901234567890@DialAccount
[ Context 'DialAccount' created by 'pbx_config' ]
 '_X!' =>          1. ExecIf($["${DB(LocalNumber${EXTEN}/Account)}" = ""]?Hangup(UNALLOCATED)) [pbx_config]
                   2. GoSub(RecordCall,s,1)                      [pbx_config]
                   3. Dial(${DB(LocalNumber${EXTEN}/Account)})   [pbx_config]
By: Tomás Laureano Peralta Tormey (laureano) 2009-07-23 17:34:26

The problem is the length of the member definition. By default, there is a limit of 80 characters for any line in the configuration file queues.conf to be parsed.
That's why "[Jul 23 16:28:56] DEBUG[4263] chan_local.c: Checking if extension 1234567890123456789012345678901234567890@DialAccoun exists (devicestate)" shows a context without the final 't' of DialAccount.
You could get 2 extra characters by removing the spaces in your member definition (member=>Local/2@DialAccount,,,Local/1234567890123456789012345678901234567890@DialAccount).
You could also rename the context to something more shorter to get some extra chars.

Or you could modify the line 5452 in app_queue.c to get a longer configurartion line to be parsed.


By: Mark Michelson (mmichelson) 2009-07-24 14:12:49

I plan to commit a fix so that config lines in queues.conf are not truncated like you are seeing.

I'd also like to take a moment to say that your use of state interface is, well, quite a bit unorthodox. Now for all I know you just came up with a contrived example for the bug report, but the problem that was supposed to be solved by the use of state interface is that since Local channels are not "real" channels, their device state reporting is not usually what one would expect. Adding a Local channel as the state interface for a queue member seems like an odd idea.

Also using the same interface for both the calling interface and the state interface does not actually accomplish anything, so your first line can be safely reduced to just:

member=>Local/1@DialAccount

and it would accomplish the same thing.
By: Digium Subversion (svnbot) 2009-07-24 14:24:35

Repository: asterisk
Revision: 208622

U   branches/1.4/apps/app_queue.c

------------------------------------------------------------------------
r208622 | mmichelson | 2009-07-24 14:24:34 -0500 (Fri, 24 Jul 2009) | 16 lines

Don't impose an arbitrary limit on member lines in queues.conf

I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"

Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.

(closes issue ASTERISK-14516)
Reported by: amorsen


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

http://svn.digium.com/view/asterisk?view=rev&revision=208622
By: Digium Subversion (svnbot) 2009-07-24 14:26:32

Repository: asterisk
Revision: 208630

_U  trunk/

------------------------------------------------------------------------
r208630 | mmichelson | 2009-07-24 14:26:32 -0500 (Fri, 24 Jul 2009) | 21 lines

Blocked revisions 208622 via svnmerge

........
 r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
 
 Don't impose an arbitrary limit on member lines in queues.conf
 
 I know what some of you are thinking: "UGH! Mark, why are you using
 ast_strdup and ast_free for the string when you can just use ast_strdupa
 and let the memory free itself?! Have the bats been chewing on your brain
 again?"
 
 Based on past experiences, I don't like using ast_strdupa inside a loop.
 It's a good way to potentially exhaust stack space. Also, since this only
 happens when reloading queues, I don't think that heap allocations and
 frees are going to be a huge problem.
 
 (closes issue ASTERISK-14516)
 Reported by: amorsen
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=208630
By: Digium Subversion (svnbot) 2009-07-24 14:34:01

Repository: asterisk
Revision: 208655

U   branches/1.6.0/apps/app_queue.c

------------------------------------------------------------------------
r208655 | mmichelson | 2009-07-24 14:34:01 -0500 (Fri, 24 Jul 2009) | 21 lines

Blocked revisions 208622 via svnmerge

........
 r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
 
 Don't impose an arbitrary limit on member lines in queues.conf
 
 I know what some of you are thinking: "UGH! Mark, why are you using
 ast_strdup and ast_free for the string when you can just use ast_strdupa
 and let the memory free itself?! Have the bats been chewing on your brain
 again?"
 
 Based on past experiences, I don't like using ast_strdupa inside a loop.
 It's a good way to potentially exhaust stack space. Also, since this only
 happens when reloading queues, I don't think that heap allocations and
 frees are going to be a huge problem.
 
 (closes issue ASTERISK-14516)
 Reported by: amorsen
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=208655
By: Digium Subversion (svnbot) 2009-07-24 14:41:03

Repository: asterisk
Revision: 208661

U   branches/1.6.1/apps/app_queue.c

------------------------------------------------------------------------
r208661 | mmichelson | 2009-07-24 14:41:03 -0500 (Fri, 24 Jul 2009) | 21 lines

Blocked revisions 208622 via svnmerge

........
 r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
 
 Don't impose an arbitrary limit on member lines in queues.conf
 
 I know what some of you are thinking: "UGH! Mark, why are you using
 ast_strdup and ast_free for the string when you can just use ast_strdupa
 and let the memory free itself?! Have the bats been chewing on your brain
 again?"
 
 Based on past experiences, I don't like using ast_strdupa inside a loop.
 It's a good way to potentially exhaust stack space. Also, since this only
 happens when reloading queues, I don't think that heap allocations and
 frees are going to be a huge problem.
 
 (closes issue ASTERISK-14516)
 Reported by: amorsen
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=208661
By: Digium Subversion (svnbot) 2009-07-24 14:41:33

Repository: asterisk
Revision: 208662

_U  branches/1.6.2/

------------------------------------------------------------------------
r208662 | mmichelson | 2009-07-24 14:41:33 -0500 (Fri, 24 Jul 2009) | 27 lines

Blocked revisions 208630 via svnmerge

................
 r208630 | mmichelson | 2009-07-24 14:26:26 -0500 (Fri, 24 Jul 2009) | 21 lines
 
 Blocked revisions 208622 via svnmerge
 
 ........
   r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
   
   Don't impose an arbitrary limit on member lines in queues.conf
   
   I know what some of you are thinking: "UGH! Mark, why are you using
   ast_strdup and ast_free for the string when you can just use ast_strdupa
   and let the memory free itself?! Have the bats been chewing on your brain
   again?"
   
   Based on past experiences, I don't like using ast_strdupa inside a loop.
   It's a good way to potentially exhaust stack space. Also, since this only
   happens when reloading queues, I don't think that heap allocations and
   frees are going to be a huge problem.
   
   (closes issue ASTERISK-14516)
   Reported by: amorsen
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=208662
By: Mark Michelson (mmichelson) 2009-07-24 14:45:33

The svn commit logs here are a bit confusing with what was "blocked" vs. what was "merged."

The appropriate fix was applicable to 1.4, 1.6.0, and 1.6.1, so those branches have been fixed. However, trunk and 1.6.2 did not require the fix, so they have been left alone.