[jira] Commented: (RIVER-258) JoinManager - race when terminate is called after attribute mutator methods (ex. setAttributes)

["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.