river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Vinod Johnson (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (RIVER-220) LookupLocatorDiscovery catch Throwable blocks should also catch Throwable
Date Thu, 29 Nov 2007 14:33:43 GMT

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

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


Shouldn't have 'resolved', just set the Fix version to AR2.

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


Mime
View raw message