[asterisk-bugs] [JIRA] Commented: (ASTERISK-16115) [patch] problem with ringinuse=no, queue members receive sometimes two calls
Italo Rossi (JIRA)
noreply at issues.asterisk.org
Tue Jul 24 11:18:21 CDT 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195148#comment-195148 ]
Italo Rossi commented on ASTERISK-16115:
----------------------------------------
Hello all,
I've been running into this problem with asterisk versions 1.8.7.1, 1.8.10.1, and probably
the most recent version also has this issue.
Follow these steps in order to reproduce:
Create a queue testqueue with one dynamic member. I've used X-lite softphone.
Create this context:
{code}
[testcall]
exten => 10,1,Answer()
exten => 10,n,Wait(12)
exten => 10,n,Hangup()
{code}
Call file test:
{code}
cat <<EOF > /tmp/test
Channel: Local/10 at testcall
Application: Queue
Data: testqueue
EOF
{code}
Creating 101 concurrent calls and place the calls to outgoing directory:
{code}
# cd /var/spool/asterisk/
cp /tmp/test .; for i in `seq 1 100`; do cp test test$i; done; touch -d "`date --date='+2 second' +%T`" test*; mv test* outgoing/
{code}
This command will schedule 101 concurrent calls to the context [testcall] on the next 2 seconds,
these calls will join testqueue at the same time (almost) and this behavior *may* reproduce the problem.
This is my test results:
Without my patch: 3 rounds of 101 concurrent calls, I'm able to reproduce the problem for 6 times (freq 20%)
With my patch applied: 3 rounds of 101 concurrent calls, I can't reproduce it, so I guess that the problem is fixed.
The explanation:
In app_queue.c the code that checks the state of the queue member resides before the function ast_call, which makes the
request to the interface. *HERE IS THE PROBLEM*: At this time is possible that two or more running threads may enter that function (ast_call)
at the same time (a race condition), which will cause this behavior:
{noformat}
thread A: thread B
request member state = free request member state = free
place the call place the call
{noformat}
My suggestion is to add a lock on the queue member just before the ast_call in order to avoid place the call without the guarantee that
this member is definitively free and just one thread makes the call to the interface, respecting the ringinuse parameter, obviously.
I've attached the patch to further readings, suggestions are welcome.
PS: I've already signed the license, and it's waiting approval.
> [patch] problem with ringinuse=no, queue members receive sometimes two calls
> ----------------------------------------------------------------------------
>
> Key: ASTERISK-16115
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-16115
> Project: Asterisk
> Issue Type: Bug
> Components: Applications/app_queue
> Reporter: nik600
> Assignee: Bradley Watkins
> Attachments: app_queue.c-1.6.2.10.patch, app_queue.c-svn-r368404.patch, app_queue.c-svn-r370418.patch, debug_.txt
>
>
> Dear all
> on a debian amd64 i've installed (from source) asterisk 1.4.31
> On the system we have in average 50 concurrent calls in queue and 40
> sip members.
> I'm experiencing an apparently random problem:
> sometimes some users receive 2 calls from asterisk, apparently
> ignoring the ringinuse=no settings.
> It appears on users that are members of many queues
> As you can see from the log, the user goes in a status Ring+Inuse.
> Any idea?
> Why the call is still dispatched to the user if it is not in the "Not
> in use" status?
> i've added some customized log in the ring_entry function and this is the result:
> [May 18 14:13:04] DEBUG[24945] app_queue.c: KUMBELOG: queue=queue_1 count=1,membercount=13,ringinuse=0,device=SIP/PL1009,status=1
> [May 18 14:13:04] DEBUG[24945] app_queue.c: Found matching member SIP/PL1009 in queue 'queue_2'
> [May 18 14:13:04] VERBOSE[24945] logger.c: -- Called SIP/PL1009
> [May 18 14:13:05] VERBOSE[24945] logger.c: -- SIP/PL1009-00001807 is ringing
> [May 18 14:13:06] DEBUG[25098] app_queue.c: KUMBELOG: queue=queue_2 count=2,membercount=15,ringinuse=0,device=SIP/PL1009,status=1
> [May 18 14:13:06] DEBUG[25098] app_queue.c: Found matching member SIP/PL1009 in queue 'queue_1'
> [May 18 14:13:06] DEBUG[25098] app_queue.c: Found matching member SIP/PL1009 in queue 'queue_3'
> [May 18 14:13:06] VERBOSE[25098] logger.c: -- Called SIP/PL1009
> [May 18 14:13:07] VERBOSE[25098] logger.c: -- SIP/PL1009-00001808 is ringing
> [May 18 14:13:07] DEBUG[25312] app_queue.c: KUMBELOG: queue=queue_3 count=1,membercount=18,ringinuse=0,device=SIP/PL1009,status=6
> [May 18 14:13:08] DEBUG[25382] app_queue.c: KUMBELOG: queue=queue_4 count=1,membercount=18,ringinuse=0,device=SIP/PL1009,status=6
> [May 18 14:13:08] DEBUG[25224] app_queue.c: KUMBELOG: queue=queue_2 count=2,membercount=15,ringinuse=0,device=SIP/PL1009,status=6
> [May 18 14:13:12] VERBOSE[25098] logger.c: -- SIP/PL1009-00001808 answered SIP/192.168.55.32-000017e6
> [May 18 14:13:13] VERBOSE[25098] logger.c: -- Native bridging SIP/192.168.55.32-000017e6 and SIP/PL1009-00001808
> [May 18 14:13:14] DEBUG[25224] app_queue.c: KUMBELOG: queue=queue_2 count=1,membercount=15,ringinuse=0,device=SIP/PL1009,status=7
> It seems that the system does not change the status of the user after calling it, and then re-schedule a new call.
> After that the status is updated and goes in a ring+inuse status (7)
> Do you have any idea about what can cause that?
> This is an example of my config
> [PL1009]
> context=mycontext
> callerid=PhoneLine1009 <1009>
> secret=pwd1009
> type=peer
> host=dynamic
> call-limit=3
> disallow=all
> allow=ulaw
> queues:
> [queue_1]
> weight=10
> wrapuptime=0
> strategy=leastrecent
> joinempty=no
> retry=0
> autopause=yes
> setinterfacevar=yes
> eventwhencalled=yes
> eventmemberstatus=yes
> ringinuse=no
> member => SIP/PL1009
> [queue_2]
> weight=10
> wrapuptime=0
> strategy=leastrecent
> joinempty=no
> retry=0
> autopause=yes
> setinterfacevar=yes
> eventwhencalled=yes
> eventmemberstatus=yes
> ringinuse=no
> member => SIP/PL1009
> [queue_3]
> weight=10
> wrapuptime=0
> strategy=leastrecent
> joinempty=no
> retry=0
> autopause=yes
> setinterfacevar=yes
> eventwhencalled=yes
> eventmemberstatus=yes
> ringinuse=no
> member => SIP/PL1009
> ****** ADDITIONAL INFORMATION ******
> I've tried:
> 1.4.31
> 1.4.30
> run the system using ESXi on DL380
> run the system using ESXi on HP Blade
> run the system directly on hardware without virtualization
> used slackware 13.0 instead of debian AMD 64
> changed the kernel hertz to 1000 instead of 250
> added dahdi to optimize timing
> On client-side, i've tested
> Sjphone on windows
> CISCO 7940 phone
> in all these test-case i had the problem, and it occurs with a frequency of 100 times each 4000 calls.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list