Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ktt7bRcZz1ySdFFL8vJt8uDpyBSvPxn3sAjwHuQoHq4tyCHCFiKZPy0Z8ip9Uzrm24
         M6jH3YAujV6vddR1GNwdzht+uaTaPaMWrJ7Er4wlDLbaDn4Hels9Vw0cmrVfRUIg0iPV
         zTnHiD8eOqv2zbkb7y7egdd8cgb/HKqr/uECA=
MIME-Version: 1.0
In-Reply-To: <BANLkTikku1cJ=6G3D3hxx4N9kQYWqsRoww@mail.gmail.com>
References: 
 <2002442925.22384.1301522705714.JavaMail.tomcat@hel.zones.apache.org>
	<4D97EAE7.2060908@acm.org>
	<BANLkTimEL-6CpTU=p8h1GXmj6OW9+gt-tQ@mail.gmail.com>
	<4D9885EC.7040108@acm.org>
	<BANLkTinmORfzig+k1O6E8iXxp76JfAdMDA@mail.gmail.com>
	<BANLkTikku1cJ=6G3D3hxx4N9kQYWqsRoww@mail.gmail.com>
Date: Sun, 3 Apr 2011 20:07:48 +0100
Message-ID: <BANLkTikRaeJLH9OGvALtKwuoonHg-RkTKQ@mail.gmail.com>
Subject: Re: [jira] [Created] (RIVER-395) Ill-behaved DiscoveryListener can
 terminate discovery notifier threads
From: Dan Creswell <dan.creswell@gmail.com>
To: dev@river.apache.org
Content-Type: multipart/alternative; boundary=0016369c89f7dcbe2b04a0085baf

--0016369c89f7dcbe2b04a0085baf
Content-Type: text/plain; charset=ISO-8859-1

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

--0016369c89f7dcbe2b04a0085baf--