river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Hurley (JIRA)" <j...@apache.org>
Subject [jira] Created: (RIVER-37) FiddlerImpl possible race condition between active & passive discards from LDM
Date Tue, 24 Jul 2007 20:00:39 GMT
FiddlerImpl possible race condition between active & passive discards from LDM
------------------------------------------------------------------------------

                 Key: RIVER-37
                 URL: https://issues.apache.org/jira/browse/RIVER-37
             Project: River
          Issue Type: Bug
          Components: com_sun_jini_fiddler
    Affects Versions: jtsk_1.2
            Reporter: Jim Hurley
            Priority: Minor


Need to investigate how FiddlerImpl determines if a discard event from
   the local LookupDiscoveryManager (LDM) is an active or a passive discard.
   Also need to investigate whether the LDM sends a discard event after
   any call to discard() (even if the lookup that is being discarded was
   already discarded -- and thus, is not in the LDM's cache), or if it only
   sends a discard event as a result of the lookup being removed from the
   LDM's cache.

   Example:

   Suppose a registration on fiddler calls the fiddler's public discard()
   method because that registration has somehow determined that a particular
   lookup is down. This should result on a call to the discard() method on
   fiddler's local LDM, which should eventually result in the LDM sending
   an "active" discard event to fiddler's listener which should then result
   in fiddler sending a (remote) discard event to the registration's listener;
   indicating the lookup has been actively discarded.

   But suppose that before the call to the LDM's discard() method completes,
   the LDM determines on its own that the lookup is down, and then sends a
   "passive" discard event to fiddler's listener. That is, suppose the LDM
   sends a passive discard event to fiddler listener between the time fiddler
   called the LDM's discard() method, and the time the LDM would have sent
   the expected discard event that should be sent as a result of fiddler's
   call to the LDM's discard() method.

   If the LDM is implemented so that it sends a discard event (either active
   or passive) only as a result of a lookup being removed from the LDM's
   managed set of lookups, rather than in response to a call to its discard()
   method, then fiddler's listener should receive only one discard event --
   the passive discard event that occurs because the LDM determined that the
   lookup was down before it could send the active discard event expected by
   the registration.

   This can cause a problem for fiddler because, regardless of order, if 
   fiddler doesn't receive both the passive and the active discard events 
   for the lookup then, with its current implementation, it will not send the
   appropriate events to the appropriate registration listeners. This is 
   because there is at least 1 registration waiting for an active discard event,
   and it is flagged as such (see the 'discardFlag' variable). When the first
   event occurs, whether it is a passive or active discard, fiddler will
   interpret it as an active discard because the registration is marked as
   expecting an active discard. Because there is at least 1 registration
   marked as expecting an active discard, fiddler sends the discard event to
   only those registrations that are marked as expecting the active discard;
   even though a passive discard event should be passed on to all of the
   interested registrations.

   This would probably be okay if the LDM then sent the active discard because
   fiddler would interpret the active discard as a passive discard and
   pass the discard event to the appropriate registrations. But if the LDM
   does not send the active discard because the lookup was removed when the
   passive discard occurred, not all of the registrations that should receive
   the passive discard will receive the passive discard. 

-----------

   Initial investigation should involve the following:
     -- look at where the 'discardFlag' is set.
     -- look at how the DiscardEventTask handles the discardFlag and
        active/passive discards in general
     -- look at the use of the method externalDiscardRequest()
     -- verify that the LDM does indeed send only 1 discard event
        (maybe write a simple test for the LDM to test if, after
        a lookup has been discarded [either actively or passively]
        future calls to discard() on the LDM will or will not result
        in another discard event -- it probably will not result in more
        discard events, but nevertheless it should be verified since I 
        believe this behavior is specified in the Discovery Utilities spec
        ["if the proxy parameter to discard() is null or is not in the
        managed set of lookups, discard() will take no action ..."])


------------------

   The fix could be difficult. The fix may involve a re-design in which two
   LDM's -- one for strictly passive discards, one for all other discards --
   is employed, rather than using a single LDM as is currently done.

   Rather than re-designing for two LDM's, another thing to consider is
   adding another "bit" to the DiscoveryEvent that indicates whether a
   discard event is active or passive. This will involve a spec change, so
   this solution should probably be considered only for the davis (2.0)  release.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message