Summary:	ASTERISK-07090: [patch] Double Ringing of Members
Reporter:	dillec (dillec)	Labels:
Date Opened:	2006-06-04 10:57:32	Date Closed:	2006-09-03 12:16:19
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_queue_DoubleCall-correct.patch ( 1) app_queue.c-0007278-Double-Ringing.patch
Description:	app_queue currently calls members several more times if they are behind members which are not available. This behavior is happening in Roundrobing and RRMemory mode. I've patched that with an "qe->parent->rrpos++;" in case that the member is not available. ****** ADDITIONAL INFORMATION ****** i.e.: Member1 => unavailable Member2 => unavailable Member3 => available Member4 => available Callflow: dial Member3 dial Member3 dial Member3 dial Member4 start over..
Comments:	By: dillec (dillec) 2006-06-04 11:50:41 sorry, the patch is broken for 1.2.8 - I've uploaded a new one which is working. Please delete the "app_queue_DoubleCall.patch [^] (430 bytes) 06-04-06 10:57" file while I'm not priviliged enough to do that. By: Alex Richardson (alexrch) 2006-06-20 09:08:51 I'm having the same problems with agents being called multiple times - and I was wondering: did anyone already test this patch? I don't want to go thru any Asterisk crashes in my call centre :) By: Serge Vecher (serge-v) 2006-06-20 10:05:41 Ok, this patch is simple enough that it applies to 1.2.9.1 -- but in the future please always post patches / bug reports for the latest stable. Thanks By: BJ Weschke (bweschke) 2006-06-21 22:11:00 We're opening up a can of worms here. :/ The patch provided I don't think is thread safe in the sense that the mutex at &qe->parent->lock is still unlocked when you go and make changes to the &qe->parent structure. There is inherently unsafe. However, it's not clear to me, and we will need to do some further testing before any commits can be considered whether just wrapping your single line with a lock and unlock of the mutex won't, in and of itself, cause any deadlocks to occur based on where in the code you're trying to lock that mutex. By: Serge Vecher (serge-v) 2006-06-28 11:54:06 diLLec: please update the patch that addresses bweschke's concerns. Thanks By: dillec (dillec) 2006-07-05 15:35:04 ok. I've done a bit testing on it and got back to simply wrap the line in a lock/unlock procedure. Further more "update_dial_status" also locks one line above. Something to make clear what the patch does: Member 1 is available Member 2 is NOT available Member 3 is available Member 4 is available current behavior: [rrpos: 0] ring Member 1 (timeout after 5 seconds) [rrpos: 1] ring Member 2 --> not available --> jump to next prio -> ring Member 3 (timeout after 5 seconds) [rrpos: 2] ring Member 3 (timeout after 5 seconds) [rrpos: 3] ring Member 4 (timeout after 5 seconds) ..start over.. after the patch: [rrpos: 0] ring Member 1 (timeout after 5 seconds) [rrpos: 1] ring Member 2 --> not available --> jump to next prio (increment rrpos) -> ring Member 3 (timeout after 5 seconds) [rrpos: 3] ring Member 4 (timeout after 5 seconds) ..start over.. since rrpos does not change if we jump to the next prio if a prior user is unavailable the next user is rang twice or more times for the ones who are not reachable. By: Alex Richardson (alexrch) 2006-07-13 06:20:43 What's the status of the latest patch? Has anyone already tested or reviewed it? By: Serge Vecher (serge-v) 2006-07-13 08:46:20 alexrch: you are welcome to test it ;) By: dillec (dillec) 2006-07-13 12:44:36 i'm working with it on a good frequented help desk system. No problems for now. By: Alex Richardson (alexrch) 2006-07-14 10:51:02 vechers: I have been testing this patch (the one posted on 06-04-06 - without mutext locking) on a test machine for few weeks now, and it seems to work just fine. I will now look at the one with the mutex and let you know - I am thinking of migrating it to the production machine (hopefully without any crashes :) ). By: Frank Waller (explidous) 2006-07-25 17:18:14 I tested this patch (with Mutex) for nearly 2 weeks now, I am not sure if it is a perfect fix, but it surely improved things. Stability or extra deadlocks were no problem at all. By: Alex Richardson (alexrch) 2006-08-10 02:37:28 I also didn't notice any stability or other problems with this patch (with mutex). It fixes the problem, so I propose to include it in branch. By: BJ Weschke (bweschke) 2006-09-03 12:16:18 Committed to 1.2 and /trunk. Thanks!