[asterisk-bugs] [Asterisk 0015113]: autofill problem when coming back from paused on realtime

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15113 
====================================================================== 
Reported By:                elbriga
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15113
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.19 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-05-14 13:29 CDT
Last Modified:              2009-05-15 17:47 CDT
====================================================================== 
Summary:                    autofill problem when coming back from paused on
realtime
Description: 
I'm testing this on 1.4.19, but I dont see anything related on the latest
changelog (maybe something on 1.4.25-rc1, but right now I dont have SVN
access to get it).

I have my queues setup on realtime and i directly access the 'paused'
column on the queue members table to change their status. When I enable
'autofill' (directly on the table, not in the conf file) it will do the
autofill behavior OK, until this scenario...

- A queue member is paused
- A call enters the queue, and here it will be looping in the
"wait_out_turn" function, that calls "is_our_turn"
- The queue member gets unpaused (directly via SQL on the respective
paused column)
- The call is still on the "wait_out_turn" loop, and inside it there are
no direct call to refresh the realtime data, so it will "never" know that
the member get unpaused (but if I, for eg, do a "queue show" CLI command it
will ring that agent right away, because the queue struct got refreshed)

I was thinking about doing a "update_realtime_members" at some frequency
inside the "wait_out_turn" loop, but then it would get executes for every
call on the queue, so I think the best way flag the need of a refresh
inside the "wait_out_turn" loop and actually refresh some place else
(where?)
====================================================================== 

---------------------------------------------------------------------- 
 (0104873) mmichelson (administrator) - 2009-05-15 17:47
 https://issues.asterisk.org/view.php?id=15113#c104873 
---------------------------------------------------------------------- 
The problem here is that unlike other fields in the queue_members table,
the 'paused' field represents state for a queue member, rather than a
configuration option.

The 'paused' field really wasn't intended to be directly modified as you
are doing. Rather, when a manager action, dialplan application, or CLI
command is used to pause a queue member, we write the value to the database
so that when we need to recreate the member later, we can maintain his
paused status from before.

Unfortunately, this is not documented anywhere, and it's too late to
change history. Plus, in the situation you're discussing, the biggest
problem is that it sounds like the data is never being refreshed from the
database. While the "paused" field obviously has the detriment of making it
so that it is not possible to unpause a member, there are other potential
issues too. Consider if a member were added to the database during this
period. He would not be able to take a call until something had triggered a
read of the database.

I have an idea about this, and it will require a bit of work to get
written correctly. Currently, app_queue works by periodically loading
realtime data, or it will load realtime data when an operation requires it,
such as typing certain CLI queue commands. My idea is to have app_queue
spawn a thread which is essentially the "realtime queue thread." Its sole
job will be to sleep and wake up periodically (say every 30 seconds or so.
I could make this configurable) to reload realtime queue member data. This
thread could be "prodded" by other threads to wake up early and reload
realtime queue member data if necessary (e.g. issuing the "queue show" CLI
command).

Right now the idea is nothing more than an idea fumbling around in my
head. I'll have to weigh the pros and cons of such an idea. One big con I
have thought of already is that an idle system will be making periodic
database lookups essentially for no reason. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-15 17:47 mmichelson     Note Added: 0104873                          
======================================================================