[asterisk-dev] [Code Review] Fix caching of device state changes for multiple servers

[reviewboard at asterisk.org]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1012/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

This patch addresses a regression where device states across multiple servers were not being processing completely correctly.  The code works to determine the overall state by looking at the last known state of a device on each server.  However, there was a regression due to some invasive rewrites of how the cache works that led to the cache only storing the last device state change for a device, regardless of which server it was on.

The code is set up to cache device state change events by ensuring that each event in the cache has a unique device name + entity ID (server ID).  The code that was responsible for comparing raw information elements (which EID is) always returned a match due to a memcmp() with a length of 0.

There isn't much code to fix the actual bug.  This patch also introduces a new CLI command that was very useful for debugging this problem.  The command allows you to dump the contents of the event cache.


This addresses bug 18280.
    https://issues.asterisk.org/view.php?id=18280


Diffs
-----

  /branches/1.8/include/asterisk/event.h 295124 
  /branches/1.8/main/event.c 295124 

Diff: https://reviewboard.asterisk.org/r/1012/diff


Testing
-------

I did testing using custom device states and manually changing their states on two different servers.  I verified that the cache contents and resulting device states were now what I expected.

Klaus reported that this patch fixed his problem, as well (on issue #18280).  In his case, he was testing a scenario where a SIP device was changing states on 2 different servers.


Thanks,

Russell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101116/a7ad5e71/attachment.htm