Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.220.171 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=kChhu5SCCSfvFaaCMSVtRG1CO/4Kv/tQQDGP4BXLRqUt9dMvDaN4fNWFOUtNvm0zCW
         wbPEbhFAXBvwcnA1BKsyohQM5UdE/yBBXxC7n0fEDXFClnftCLFc31ghLzqZ3qZKzLIp
         4VLMvt6+M0x90x3TRGieLrAx3LZ/+w1OZRshY=
MIME-Version: 1.0
In-Reply-To: <4D9885EC.7040108@acm.org>
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>
Date: Sun, 3 Apr 2011 16:04:35 +0100
Message-ID: <BANLkTinmORfzig+k1O6E8iXxp76JfAdMDA@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=0016e689714019c6a904a004f65b

--0016e689714019c6a904a004f65b
Content-Type: text/plain; charset=ISO-8859-1

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

--0016e689714019c6a904a004f65b--