You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Bob Scheifler (JIRA)" <ji...@apache.org> on 2007/08/10 21:17:42 UTC
[jira] Created: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
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
Priority: Minor
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.
[jira] Resolved: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
Posted by "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 resolved RIVER-220.
----------------------------------------
Resolution: Fixed
> 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.
[jira] Closed: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-220.
---------------------------------
> 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.
[jira] Reopened: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
Posted by "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.
[jira] Work started: (RIVER-220) LookupLocatorDiscovery catch
Throwable blocks should also catch Throwable
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on RIVER-220 started by 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.
[jira] Resolved: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
Posted by "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 resolved RIVER-220.
----------------------------------------
Resolution: Fixed
> 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.
[jira] Resolved: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
Posted by "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 resolved RIVER-220.
----------------------------------------
Resolution: Fixed
Fix Version/s: 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
> 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.
[jira] Commented: (RIVER-220) LookupLocatorDiscovery catch
Throwable blocks should also catch Throwable
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575511#action_12575511 ]
Thomas Vinod Johnson commented on RIVER-220:
--------------------------------------------
The patch for this has been submitted as part of the patch for RIVER-226
> 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.
[jira] Reopened: (RIVER-220) LookupLocatorDiscovery catch Throwable
blocks should also catch Throwable
Posted by "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:
----------------------------------------
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.