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

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: River_2.1.1
• Fix Version/s: River_2.1.2
• Component/s: net_jini_lookup
• Assignee: Unassigned
• Reporter: Brian Murphy
• Created: 08/Nov/09 20:42
• Updated: 22/Feb/10 12:28
• Resolved: 22/Feb/10 12:28

Description

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.