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

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