[jira] Reopened: (RIVER-220) LookupLocatorDiscovery catch Throwable blocks should also catch Throwable

["Thomas Vinod Johnson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RIVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Vinod Johnson reopened RIVER-220:
----------------------------------------

      Assignee: Thomas Vinod Johnson

> LookupLocatorDiscovery catch Throwable blocks should also catch Throwable
> -------------------------------------------------------------------------
>
>                 Key: RIVER-220
>                 URL: https://issues.apache.org/jira/browse/RIVER-220
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_discovery
>    Affects Versions: jtsk_2.1
>            Reporter: Bob Scheifler
>            Assignee: Thomas Vinod Johnson
>            Priority: Minor
>             Fix For: AR2
>
>
> Bugtraq ID [6306579|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6306579]
> LD and LLD each have one place where they catch Throwable and log the exception. To guard against possible failures in logging, the logging should itself be done in a try block with a catch and do-nothing of Throwable.
> Evaluation
> It does not appear that this is really required in the case of LookupDiscovery. The specific case is in the UnicastDiscoveryTask, where discovery fails. However even if logging fails, the finally block takes care of doing the appropriate cleanup (TaskManager will attempt to log the logging exception itself, which seems undesireable, but should otherwise cause no other adverse effects).
> In the case of LookupLocatorDiscovery, the failure in the LocatorReg.tryGetProxy logging, would ultimately cause the DiscoveryTask for that registrar to terminate - leaving the registrar in an 'undiscovered' state, but having no future task scheduled to attempt to discover it. This is an inconsistent state of affairs and will lead to future discard, addLocators, setLocators for this specific registrar to essentially be ignored. Seems worthwile to protect LookupLocatorDiscovery in this case.

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