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/08/17 20:34:30 UTC
[jira] Created: (RIVER-258) JoinManager - race when terminate is
called after attribute mutator methods (ex. setAttributes)
JoinManager - race when terminate is called after attribute mutator methods (ex. setAttributes)
-----------------------------------------------------------------------------------------------
Key: RIVER-258
URL: https://issues.apache.org/jira/browse/RIVER-258
Project: River
Issue Type: Bug
Components: net_jini_lookup
Affects Versions: jtsk_2.0
Reporter: Jim Hurley
Priority: Minor
Bugtraq ID [4953710|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4953710]
Calling the setAttributes and terminate methods in quick succession on a
JoinManager can result in UnknownLeaseExceptions thrown by lookup services. The
high-level sequence of events appears to be:
Thread 1 Thread 2
-------- --------
JM.setAttributes
add SetAttributesTask to task list
queue ProxyRegTask in taskMgr
run ProxyRegTask
run SetAttributesTask
JM.terminate
terminate pending tasks
cancel service leases
call srvcReg.setAttributes
Although this does not cause any serious problems (since we're terminating the
service registration, we don't care about the failure of delayed setAttributes
calls), an exception trace is printed since the exception is logged at
Level.INFO.
Comments
----------------------
The original synopsis of this bug when it was filed in November of 2003 was,
"JoinMgr.setAttributes followed by terminate results in UnknownLeaseException".
As indicated in the description, an UnknownLeaseException was observed
when invoking terminate immediately after setAttributes when running the
following version of JoinManager:
JoinManager.java@@/main/mpw_reggie_capacity/1
That version of JoinManager is pre-Porter (ie. pre-2.1), and a number of
bugs have been addressed since that version that may have affected this
bug.
That said, upon investigating this bug, a race was indeed observed
between setAttributes and terminate, but it did not manifest itself in
only an UnknownLeaseException. Additionally, it was not just a race between
setAttributes and terminate; that is, the race occurs between any of the
attribute mutator methods (addAttributes, setAttributes, modifyAttributes)
and terminate (this is why the synopsis was changed to be more inclusive).
With the injection of time delays in the appropriate places in JoinManager,
one can cause the occurrence of not only UnknownLeaseException, but also
the following exception combination:
java.rmi.UnmarshalException: exception unmarshalling response;
nested exception is: java.io.IOException: request I/O interrupted
....... together with .........
WARNING: Task.run exception
java.lang.IllegalStateException: trying to add task to stopped WakeupManager
at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:433)
at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:418)
at com.sun.jini.thread.RetryTask.run(RetryTask.java:146)
at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
An UnknownLeaseException occurs when the timing is such that the service lease
is cancelled between the time the SetAttributesTask begins running and the
remote call to srvcRegistration.setAttributes() is made. To cause the sort of
timing that would result in an UnknownLeaseException (without the fix to
this bug), one can do the following:
1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
to srvcRegistration.setAttributes(attSet);
2. Place a 3 second delay in JoinManager.terminate, just prior to the call to
terminateTaskMgr
3. Use the instrumented JoinManager to register a service with a lookup service
and then call setAttributes() (or addAttributes() or modifyAttributes())
immediately followed by terminate().
The delay before terminateTaskMgr() allows time for the SetAttributesTask to be
queued before the task manager is terminated. And the difference in the values
of the delays (the delay before setAttributes must be larger than the delay
before terminateTaskMgr) allows the leases to be cancelled before the remote
call (srvcRegistration.setAttributes) is made; which then results in an
UnknownLeaseException from the lookup service.
See test:
/vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateULE.java
With respect to the other race scenario, an IllegalStateException occurs when
the timing is such that the termination of the TaskManager causes the
interruption of the thread that contains the call to
srvcRegistration.setAttributes(). This causes an UnmarshalException
in the ProxyReg.tryOnce() method, which causes a call to the method
ProxyReg.stopTrying(). The method stopTrying() then attempts to queue a
retry of the SetAttributesTask with the WakeupManager, which causes an
IllegalStateException because the termination of the TaskManager has caused
the WakeupManager to be terminated as well. To cause the sort of
timing that would result in an IllegalStateException (without the fix to
this bug), one can do the following:
1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
to srvcRegistration.setAttributes(attSet);
2. Use the instrumented JoinManager to register a service with a lookup service
and then call setAttributes() (or addAttributes() or modifyAttributes()),
delay 5 seconds (probably best to delay the same amount of time as in
the JoinManager), then call terminate().
See test:
/vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateISE.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-258) JoinManager - race when terminate is
called after attribute mutator methods (ex. setAttributes)
Posted by "Brian Murphy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Murphy updated RIVER-258:
-------------------------------
Fix Version/s: AR2
Assignee: Brian Murphy
> JoinManager - race when terminate is called after attribute mutator methods (ex. setAttributes)
> -----------------------------------------------------------------------------------------------
>
> Key: RIVER-258
> URL: https://issues.apache.org/jira/browse/RIVER-258
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
> Affects Versions: jtsk_2.0
> Reporter: Jim Hurley
> Assignee: Brian Murphy
> Priority: Minor
> Fix For: AR2
>
>
> Bugtraq ID [4953710|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4953710]
> Calling the setAttributes and terminate methods in quick succession on a
> JoinManager can result in UnknownLeaseExceptions thrown by lookup services. The
> high-level sequence of events appears to be:
> Thread 1 Thread 2
> -------- --------
> JM.setAttributes
> add SetAttributesTask to task list
> queue ProxyRegTask in taskMgr
> run ProxyRegTask
> run SetAttributesTask
> JM.terminate
> terminate pending tasks
> cancel service leases
> call srvcReg.setAttributes
> Although this does not cause any serious problems (since we're terminating the
> service registration, we don't care about the failure of delayed setAttributes
> calls), an exception trace is printed since the exception is logged at
> Level.INFO.
> Comments
> ----------------------
> The original synopsis of this bug when it was filed in November of 2003 was,
> "JoinMgr.setAttributes followed by terminate results in UnknownLeaseException".
> As indicated in the description, an UnknownLeaseException was observed
> when invoking terminate immediately after setAttributes when running the
> following version of JoinManager:
> JoinManager.java@@/main/mpw_reggie_capacity/1
> That version of JoinManager is pre-Porter (ie. pre-2.1), and a number of
> bugs have been addressed since that version that may have affected this
> bug.
> That said, upon investigating this bug, a race was indeed observed
> between setAttributes and terminate, but it did not manifest itself in
> only an UnknownLeaseException. Additionally, it was not just a race between
> setAttributes and terminate; that is, the race occurs between any of the
> attribute mutator methods (addAttributes, setAttributes, modifyAttributes)
> and terminate (this is why the synopsis was changed to be more inclusive).
> With the injection of time delays in the appropriate places in JoinManager,
> one can cause the occurrence of not only UnknownLeaseException, but also
> the following exception combination:
> java.rmi.UnmarshalException: exception unmarshalling response;
> nested exception is: java.io.IOException: request I/O interrupted
> ....... together with .........
> WARNING: Task.run exception
> java.lang.IllegalStateException: trying to add task to stopped WakeupManager
> at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:433)
> at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:418)
> at com.sun.jini.thread.RetryTask.run(RetryTask.java:146)
> at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
> An UnknownLeaseException occurs when the timing is such that the service lease
> is cancelled between the time the SetAttributesTask begins running and the
> remote call to srvcRegistration.setAttributes() is made. To cause the sort of
> timing that would result in an UnknownLeaseException (without the fix to
> this bug), one can do the following:
> 1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
> to srvcRegistration.setAttributes(attSet);
> 2. Place a 3 second delay in JoinManager.terminate, just prior to the call to
> terminateTaskMgr
> 3. Use the instrumented JoinManager to register a service with a lookup service
> and then call setAttributes() (or addAttributes() or modifyAttributes())
> immediately followed by terminate().
> The delay before terminateTaskMgr() allows time for the SetAttributesTask to be
> queued before the task manager is terminated. And the difference in the values
> of the delays (the delay before setAttributes must be larger than the delay
> before terminateTaskMgr) allows the leases to be cancelled before the remote
> call (srvcRegistration.setAttributes) is made; which then results in an
> UnknownLeaseException from the lookup service.
> See test:
> /vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateULE.java
> With respect to the other race scenario, an IllegalStateException occurs when
> the timing is such that the termination of the TaskManager causes the
> interruption of the thread that contains the call to
> srvcRegistration.setAttributes(). This causes an UnmarshalException
> in the ProxyReg.tryOnce() method, which causes a call to the method
> ProxyReg.stopTrying(). The method stopTrying() then attempts to queue a
> retry of the SetAttributesTask with the WakeupManager, which causes an
> IllegalStateException because the termination of the TaskManager has caused
> the WakeupManager to be terminated as well. To cause the sort of
> timing that would result in an IllegalStateException (without the fix to
> this bug), one can do the following:
> 1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
> to srvcRegistration.setAttributes(attSet);
> 2. Use the instrumented JoinManager to register a service with a lookup service
> and then call setAttributes() (or addAttributes() or modifyAttributes()),
> delay 5 seconds (probably best to delay the same amount of time as in
> the JoinManager), then call terminate().
> See test:
> /vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateISE.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-258) JoinManager - race when terminate is
called after attribute mutator methods (ex. setAttributes)
Posted by "Jim Hurley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520623 ]
Jim Hurley commented on RIVER-258:
----------------------------------
Suggested Fix
---------------------------
At the beginning of the method ProxyRegTask.stopTrying(), insert the
following lines of code:
synchronized(JoinManager.this) {
if(bTerminated) return true;
}//end sync
This will prevent the IllegalStateException.
Note that the UnknownLeaseException can still occur, but will not be
logged by the ProxyReg.fail() method, which is called by stopTrying()
because the UnknownLeaseException is not INDEFINITE. If the JoinManager
has been terminated (which it has in this case), ProxyReg.fail() simply
returns and does not log the exception.
Note that one point of confusion that still remains (as of 3-9-2006) is
why the UnknownLeaseException that caused this bug to be filed was ever
encountered. It appears that the pre-Porter version of ProxyReg.fail()
that was used when this bug was originally encountered, also returned
without logging the exception when the JoinManager had already been
terminated. Thus, any UnknownLeaseException that occurred as a result of
terminating the JoinManager should never have been displayed.
> JoinManager - race when terminate is called after attribute mutator methods (ex. setAttributes)
> -----------------------------------------------------------------------------------------------
>
> Key: RIVER-258
> URL: https://issues.apache.org/jira/browse/RIVER-258
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
> Affects Versions: jtsk_2.0
> Reporter: Jim Hurley
> Priority: Minor
>
> Bugtraq ID [4953710|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4953710]
> Calling the setAttributes and terminate methods in quick succession on a
> JoinManager can result in UnknownLeaseExceptions thrown by lookup services. The
> high-level sequence of events appears to be:
> Thread 1 Thread 2
> -------- --------
> JM.setAttributes
> add SetAttributesTask to task list
> queue ProxyRegTask in taskMgr
> run ProxyRegTask
> run SetAttributesTask
> JM.terminate
> terminate pending tasks
> cancel service leases
> call srvcReg.setAttributes
> Although this does not cause any serious problems (since we're terminating the
> service registration, we don't care about the failure of delayed setAttributes
> calls), an exception trace is printed since the exception is logged at
> Level.INFO.
> Comments
> ----------------------
> The original synopsis of this bug when it was filed in November of 2003 was,
> "JoinMgr.setAttributes followed by terminate results in UnknownLeaseException".
> As indicated in the description, an UnknownLeaseException was observed
> when invoking terminate immediately after setAttributes when running the
> following version of JoinManager:
> JoinManager.java@@/main/mpw_reggie_capacity/1
> That version of JoinManager is pre-Porter (ie. pre-2.1), and a number of
> bugs have been addressed since that version that may have affected this
> bug.
> That said, upon investigating this bug, a race was indeed observed
> between setAttributes and terminate, but it did not manifest itself in
> only an UnknownLeaseException. Additionally, it was not just a race between
> setAttributes and terminate; that is, the race occurs between any of the
> attribute mutator methods (addAttributes, setAttributes, modifyAttributes)
> and terminate (this is why the synopsis was changed to be more inclusive).
> With the injection of time delays in the appropriate places in JoinManager,
> one can cause the occurrence of not only UnknownLeaseException, but also
> the following exception combination:
> java.rmi.UnmarshalException: exception unmarshalling response;
> nested exception is: java.io.IOException: request I/O interrupted
> ....... together with .........
> WARNING: Task.run exception
> java.lang.IllegalStateException: trying to add task to stopped WakeupManager
> at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:433)
> at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:418)
> at com.sun.jini.thread.RetryTask.run(RetryTask.java:146)
> at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
> An UnknownLeaseException occurs when the timing is such that the service lease
> is cancelled between the time the SetAttributesTask begins running and the
> remote call to srvcRegistration.setAttributes() is made. To cause the sort of
> timing that would result in an UnknownLeaseException (without the fix to
> this bug), one can do the following:
> 1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
> to srvcRegistration.setAttributes(attSet);
> 2. Place a 3 second delay in JoinManager.terminate, just prior to the call to
> terminateTaskMgr
> 3. Use the instrumented JoinManager to register a service with a lookup service
> and then call setAttributes() (or addAttributes() or modifyAttributes())
> immediately followed by terminate().
> The delay before terminateTaskMgr() allows time for the SetAttributesTask to be
> queued before the task manager is terminated. And the difference in the values
> of the delays (the delay before setAttributes must be larger than the delay
> before terminateTaskMgr) allows the leases to be cancelled before the remote
> call (srvcRegistration.setAttributes) is made; which then results in an
> UnknownLeaseException from the lookup service.
> See test:
> /vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateULE.java
> With respect to the other race scenario, an IllegalStateException occurs when
> the timing is such that the termination of the TaskManager causes the
> interruption of the thread that contains the call to
> srvcRegistration.setAttributes(). This causes an UnmarshalException
> in the ProxyReg.tryOnce() method, which causes a call to the method
> ProxyReg.stopTrying(). The method stopTrying() then attempts to queue a
> retry of the SetAttributesTask with the WakeupManager, which causes an
> IllegalStateException because the termination of the TaskManager has caused
> the WakeupManager to be terminated as well. To cause the sort of
> timing that would result in an IllegalStateException (without the fix to
> this bug), one can do the following:
> 1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
> to srvcRegistration.setAttributes(attSet);
> 2. Use the instrumented JoinManager to register a service with a lookup service
> and then call setAttributes() (or addAttributes() or modifyAttributes()),
> delay 5 seconds (probably best to delay the same amount of time as in
> the JoinManager), then call terminate().
> See test:
> /vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateISE.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-258) JoinManager - race when terminate is
called after attribute mutator methods (ex. setAttributes)
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated RIVER-258:
--------------------------------
Fix Version/s: (was: AR2)
> JoinManager - race when terminate is called after attribute mutator methods (ex. setAttributes)
> -----------------------------------------------------------------------------------------------
>
> Key: RIVER-258
> URL: https://issues.apache.org/jira/browse/RIVER-258
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
> Affects Versions: jtsk_2.0
> Reporter: Jim Hurley
> Assignee: Brian Murphy
> Priority: Minor
>
> Bugtraq ID [4953710|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4953710]
> Calling the setAttributes and terminate methods in quick succession on a
> JoinManager can result in UnknownLeaseExceptions thrown by lookup services. The
> high-level sequence of events appears to be:
> Thread 1 Thread 2
> -------- --------
> JM.setAttributes
> add SetAttributesTask to task list
> queue ProxyRegTask in taskMgr
> run ProxyRegTask
> run SetAttributesTask
> JM.terminate
> terminate pending tasks
> cancel service leases
> call srvcReg.setAttributes
> Although this does not cause any serious problems (since we're terminating the
> service registration, we don't care about the failure of delayed setAttributes
> calls), an exception trace is printed since the exception is logged at
> Level.INFO.
> Comments
> ----------------------
> The original synopsis of this bug when it was filed in November of 2003 was,
> "JoinMgr.setAttributes followed by terminate results in UnknownLeaseException".
> As indicated in the description, an UnknownLeaseException was observed
> when invoking terminate immediately after setAttributes when running the
> following version of JoinManager:
> JoinManager.java@@/main/mpw_reggie_capacity/1
> That version of JoinManager is pre-Porter (ie. pre-2.1), and a number of
> bugs have been addressed since that version that may have affected this
> bug.
> That said, upon investigating this bug, a race was indeed observed
> between setAttributes and terminate, but it did not manifest itself in
> only an UnknownLeaseException. Additionally, it was not just a race between
> setAttributes and terminate; that is, the race occurs between any of the
> attribute mutator methods (addAttributes, setAttributes, modifyAttributes)
> and terminate (this is why the synopsis was changed to be more inclusive).
> With the injection of time delays in the appropriate places in JoinManager,
> one can cause the occurrence of not only UnknownLeaseException, but also
> the following exception combination:
> java.rmi.UnmarshalException: exception unmarshalling response;
> nested exception is: java.io.IOException: request I/O interrupted
> ....... together with .........
> WARNING: Task.run exception
> java.lang.IllegalStateException: trying to add task to stopped WakeupManager
> at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:433)
> at com.sun.jini.thread.WakeupManager.schedule(WakeupManager.java:418)
> at com.sun.jini.thread.RetryTask.run(RetryTask.java:146)
> at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
> An UnknownLeaseException occurs when the timing is such that the service lease
> is cancelled between the time the SetAttributesTask begins running and the
> remote call to srvcRegistration.setAttributes() is made. To cause the sort of
> timing that would result in an UnknownLeaseException (without the fix to
> this bug), one can do the following:
> 1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
> to srvcRegistration.setAttributes(attSet);
> 2. Place a 3 second delay in JoinManager.terminate, just prior to the call to
> terminateTaskMgr
> 3. Use the instrumented JoinManager to register a service with a lookup service
> and then call setAttributes() (or addAttributes() or modifyAttributes())
> immediately followed by terminate().
> The delay before terminateTaskMgr() allows time for the SetAttributesTask to be
> queued before the task manager is terminated. And the difference in the values
> of the delays (the delay before setAttributes must be larger than the delay
> before terminateTaskMgr) allows the leases to be cancelled before the remote
> call (srvcRegistration.setAttributes) is made; which then results in an
> UnknownLeaseException from the lookup service.
> See test:
> /vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateULE.java
> With respect to the other race scenario, an IllegalStateException occurs when
> the timing is such that the termination of the TaskManager causes the
> interruption of the thread that contains the call to
> srvcRegistration.setAttributes(). This causes an UnmarshalException
> in the ProxyReg.tryOnce() method, which causes a call to the method
> ProxyReg.stopTrying(). The method stopTrying() then attempts to queue a
> retry of the SetAttributesTask with the WakeupManager, which causes an
> IllegalStateException because the termination of the TaskManager has caused
> the WakeupManager to be terminated as well. To cause the sort of
> timing that would result in an IllegalStateException (without the fix to
> this bug), one can do the following:
> 1. Place a 5 second delay in JoinManager.setAttributes, just prior to the call
> to srvcRegistration.setAttributes(attSet);
> 2. Use the instrumented JoinManager to register a service with a lookup service
> and then call setAttributes() (or addAttributes() or modifyAttributes()),
> delay 5 seconds (probably best to delay the same amount of time as in
> the JoinManager), then call terminate().
> See test:
> /vob/qa/src/com/sun/jini/test/impl/joinmanager/RaceAttrsVsTerminateISE.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.