[asterisk-bugs] [Asterisk 0011896]: Optimized update_realtime_member_field function

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11896 
====================================================================== 
Reported By:                atis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11896
Category:                   Applications/app_queue
Reproducibility:            N/A
Severity:                   tweak
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 101580 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-31-2008 17:21 CST
Last Modified:              02-01-2008 10:12 CST
====================================================================== 
Summary:                    Optimized update_realtime_member_field function
Description: 
Currently update_realtime_member_field does first load to find out current
uniqueid of member by interface and queue name, and only then updates
corresponding member record by uniqueid.

This can be optimized by storing uniqueid in member structure, making
update_realtime_member_field much more simpler and eliminating extra access
to realtime engine.

It won't break current systems (without uniqueid), as they are not
updating anyway.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 02-01-08 10:12  
---------------------------------------------------------------------- 
I've been looking over this patch, and it definitely is a good
optimization. I tried thinking of times when this could cause a problem. I
was thinking of circumstances like the following:

1. Load member information from realtime
2. Member is deleted from the backend.
3. Before we read info from realtime again, we attempt to update a field
based on what we have in memory.

In the above scenario, the update will fail, but that's no problem, since
the operation will still succeed for what we have in memory and that member
will be marked for deletion after the next read from realtime anyway. What
is more problematic is the following scenario:

1. Load member information from realtime
2. Member is deleted from realtime and then re-added (therefore having a
new uniqueid).
3. Before we read info from realtime again, we attempt to update a field
based on what we have in memory.

In this scenario, the update will again fail since no member with the
uniqueid we have in memory will exist. In this case, I could foresee
issues. For instance, someone could attempt to pause a member and even
though it would pause the member in memory, the paused status would not be
reflected in realtime due to the failed update. Then, the next time member
information is read from realtime, the paused status of the member could be
changed to an undesired value.

Of course, if a member was removed and then re-added to the database,
should the user have any expectation of state to carry from the previously
defined member to the new one? It's an arguable point and I'd like to hear
your opinions on the matter. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-01-08 10:12  putnopvut      Note Added: 0081575                          
======================================================================