river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: [jira] [Created] (RIVER-395) Ill-behaved DiscoveryListener can terminate discovery notifier threads
Date Sun, 03 Apr 2011 19:07:48 GMT
Trouble is the Error could have come from a remote JVM, do you want that
blowing up the local one?

On 3 April 2011 19:08, Tom Hobbs <tvhobbs@googlemail.com> wrote:

> 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