Re: [jira] Commented: (RIVER-324) Under certain circumstances, the ServiceDiscoveryManager internal LookupCache implementation can incorrectly process attribute change events before the lookup snapshot is processed.

[Peter Firmstone]

Good work Brian.

Thanks,

Peter.

Brian Murphy (JIRA) wrote:

[ https://issues.apache.org/jira/browse/RIVER-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774823#action_12774823 ]

Brian Murphy commented on RIVER-324:
------------------------------------

Changeset 833922: contains the proposed fix reflected
in the attached patch file, and described in this issue's
description.

Verification: ran all ServiceDiscoveryManager tests and observed no errors or problems.

btm-08-Nov-2009

Under certain circumstances, the ServiceDiscoveryManager internal LookupCache 
implementation can incorrectly  process attribute change events before the 
lookup  snapshot is processed.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                Key: RIVER-324
                URL: https://issues.apache.org/jira/browse/RIVER-324
            Project: River
         Issue Type: Bug
         Components: net_jini_lookup
   Affects Versions: AR1
           Reporter: Brian Murphy
           Assignee: Brian Murphy
           Priority: Minor
            Fix For: AR2

        Attachments: river-324.patch


When an attribute change event is received from the
lookup service between the time the cache registers
the event listener and the initial LookupTask takes

the snapshot of the associated service state, the change event can get processed first, which can result in incorrect attribute state.

This bug has been observed in a currently deployed
system, generally at startup when the services of
the system are changing their attributes from an

initial, 'unknown' state, to a discovered state that is shared among those services. What has been

observed is a sequence like the following:
1. event registration is sent to the lookup service
2. snapshot is requested (LookupTask is queued)
3. the lookup service sends back in the requested
   snapshot, the initial state the service registered
   for itself

4. the service sends an attribute modification request to the lookup service, which sends an

   attribute change event to the cache

5. before the cache's LookupTask processes the snapshot from the lookup service, the event

   arrives and the event processing thread of the
   cache processes the event containing the latest
   state of the service's attributes.
6. the cache then processes the snapshot, replacing
   the latest, most up-to-date attribute state with
   the original, initial state reflected in the
   snapshot.
7. the cache now has an incorrect view of the
   service's state.
Bob Scheifler has implemented a simple fix; which

is (quoting Bob), "to have the LookupTask execute the tasks it creates directly, rather than queueing

them." That is, force any pending snapshot processing
tasks to be executed before the event processing
tasks.
Note that with the proposed fix, if more than
one lookup service is running, it is possible for
an attribute to "regress" as the lookup services
do not receive a given attribute change at exactly

the same time, but the inconsistency will eventually correct itself as the cache receives each attribute change event, and so should not be a permanent condition.