You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Jim Hurley (JIRA)" <ji...@apache.org> on 2007/07/24 22:00:39 UTC
[jira] Created: (RIVER-37) FiddlerImpl possible race condition
between active & passive discards from LDM
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.
[jira] Updated: (RIVER-37) FiddlerImpl possible race condition
between active & passive discards from LDM
Posted by "Jim Hurley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Hurley updated RIVER-37:
----------------------------
Bugtraq ID: 4442766 (was: [4442766|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4442766])
Description:
BugTraq ID [4442766|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4442766]
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.
was:
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.
> 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
>
> BugTraq ID [4442766|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4442766]
> 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.