Merged revisions 185031 via svnmerge from
authorMark Michelson <mmichelson@digium.com>
Mon, 30 Mar 2009 16:26:48 +0000 (16:26 +0000)
committerMark Michelson <mmichelson@digium.com>
Mon, 30 Mar 2009 16:26:48 +0000 (16:26 +0000)
commitc4e3bfb74c3610b2eb71ddcf0cf8720b6350f795
treeed2bf8d63418576158b0beb38625e2def160f3f5
parent0abfe4e9428aff4553908378fe5771d85af04a28
Merged revisions 185031 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r185031 | mmichelson | 2009-03-30 11:17:35 -0500 (Mon, 30 Mar 2009) | 39 lines

  Fix queue weight behavior so that calls in low-weight queues are not inappropriately blocked.

  (This is copied and pasted from the review request I made for this patch)

  Asterisk has some odd behavior when queue weights are used. The current logic used when
  potentially calling a queue member is:

  If the member we are going to call is part of another queue and _that other queue has any
  callers in it_ and has a higher weight than the queue we are calling from, then don't try
  to contact that member. The issue here is what I have marked with underscores. If the
  higher-weighted queue has any callers in it at all, then the queue member will be unreachable
  from the lower-weighted queue. This has the potential to be really really bad if using a
  queue strategy, such as leastrecent or fewestcalls, with the potential to call the same
  member repeatedly.

  The fix proposed by garychen on issue 13220 is very simple and, as far as I can see, works
  well for this situation. With this set of changes, the logic used becomes:

  If the member we are going to call is part of another queue, the other queue has a higher
  weight than the queue we are calling from, and the higher weight queue has at least as many
  callers as available members, then do not try to contact the queue member. If the higher
  weighted queue has fewer callers than available members, then there is no reason to deny
  the call to this member since the other queue can afford to spare a member.

  Since the fix involved writing a generic function for determining the number of available
  members in the queue, I also modified the is_our_turn function to make use of the new
  num_available_members function to determine if it is our turn to try calling a member. There
  is one small behavior change. Before writing this patch, if you had autofill disabled, then
  if you were the head caller in a queue, you would automatically be told that it was your
  turn to try calling a member. This did not take into account whether there were actually any
  queue members available to take the call. Now we actually make sure there is at least one
  member available to take the call if autofill is disabled.

  (closes issue #13220)
  Reported by: garychen

  Review: http://reviewboard.digium.com/r/202/
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
apps/app_queue.c