river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: [jira] [Created] (RIVER-395) Ill-behaved DiscoveryListener can terminate discovery notifier threads
Date Sun, 03 Apr 2011 18:08:32 GMT
I think that exactly the argument for not catching Throwable.  In this case
I'd catch Exception and log the message, thus allowing Error and other
non-recoverable stuff to explode appropriately.

If something really bad has happened let the code/user/whatever know.  Don't
confuse the issue by swallowing (or attempting to swallow) the problem.

Just my opinion.

Tom

On 3 Apr 2011 16:05, "Dan Creswell" <dan.creswell@gmail.com> wrote:
> On 3 April 2011 15:36, Patricia Shanahan <pats@acm.org> wrote:
>
>> Correct about the class name.
>>
>> We need to remember that Throwable includes conditions that are not
>> specific to the code that throws it, but rather indicate a general
problem.
>>
>>
> Sure but if you've got one of those cases, chances are many other things
> will break also because it's a general problem.
>
> Patricia
>>
>>
>>
>> On 4/3/2011 1:14 AM, Dan Creswell wrote:
>>
>>> Did you mean LookupLocatorDiscovery.Notifier?
>>>
>>> In regards to ignoring Throwable, it depends on the context. In this
case,
>>> we'd have a ServiceRegistrar that cannot respond to the request made
>>> (getLocator) which is therefore either down or pretty broken. The most
I'd
>>> do in such a situation is dump the registrar (but you might discover it
>>> again later) and issue a log message.
>>>
>>> Silence in this case seems like a reasonable option, guess I might want
a
>>> log message to help me (or a user) debug is all.
>>>
>>> That just leaves whether one believes in catching Throwable. I'd say
it's
>>> legitimate as there's a variety of problems that could result from
dealing
>>> in a faulty ServiceRegistrar that shouldn't ultimately disrupt the
>>> discovery
>>> process.
>>>
>>> Cheers,
>>>
>>> Dan.
>>>
>>> On 3 April 2011 04:35, Patricia Shanahan<pats@acm.org> wrote:
>>>
>>> In reviewing the code prior to applying the patch, I noticed the
>>>> following in the LookupDiscoveryListener.Notifier.run() method:
>>>>
>>>> try {
>>>> loc = regs[i].getLocator();
>>>> } catch (Throwable ex) { /* ignore */ }
>>>>
>>>> What do people think about ignoring Throwable?
>>>>
>>>> Chris, Thanks for the patch. Do you happen to have a unit or QA test
for
>>>> this problem?
>>>>
>>>> Patricia
>>>>
>>>>
>>>>
>>>>
>>>> On 3/30/2011 3:05 PM, Chris Dolan (JIRA) wrote:
>>>>
>>>> Ill-behaved DiscoveryListener can terminate discovery notifier threads
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Key: RIVER-395
>>>>> URL: https://issues.apache.org/jira/browse/RIVER-395
>>>>> Project: River
>>>>> Issue Type: Bug
>>>>> Components: net_jini_discovery
>>>>> Affects Versions: jtsk_2.1
>>>>> Reporter: Chris Dolan
>>>>>
>>>>>
>>>>> (bug detected in Jini 2.1, still present in 2.1.2+ trunk)
>>>>>
>>>>> If a net.jini.discovery.DiscoveryListener implementation throws an
>>>>> unchecked exception, then the LookupLocatorDiscovery$Notifier thread
>>>>> and/or
>>>>> the LookupDiscovery$Notifier thread will exit prematurely. In
practice,
>>>>> this
>>>>> can prevent the JoinManager$DiscMgrListener or
>>>>> ServiceDiscoveryManager$DiscMgrListener callbacks from being invoked,
>>>>> resulting in incomplete state for a registrar.
>>>>>
>>>>> A soon-to-be attached patch surrounds each listener invocation with a
>>>>> try/catch block.
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message