[asterisk-bugs] [JIRA] (ASTERISK-26013) Multiple queued calls sent to agent

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=230559#comment-230559 ] 

Asterisk Team commented on ASTERISK-26013:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> Multiple queued calls sent to agent
> -----------------------------------
>
>                 Key: ASTERISK-26013
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26013
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 11.22.0
>         Environment: CentOS 6.4
>            Reporter: Richard Miller
>
> This is the scenario.  An agent is logged into multiple queues.  The queues are all set up with autofill on, ringinuse off, and a ring strategy of leastrecent.  The queues and members are in realtime ODBC storage.
> The CEL occasionally shows two calls firing off to a single agent within 100 microseconds.  Typically, the calls come from different queues, but occasionally both calls come from the same queue.
> The problem is that the architecture depends on device state information to know when an agent is in use, but with fast multicore processors, another thread can detect the same agent as the next to notify before the device state changes.  There is a window between wait_our_turn() and try_calling() where this can happen.  I think the way to resolve it, depending on the ring strategy, is for wait_our_turn() to attach a member to a queue entry while both chains are locked.
> The loophole size can be reduced but not completely closed if get_member_status() tests the member->call_pending state.
> I am looking for some feedback or comments before working on a patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)