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 pats@acm.org designates
 209.86.89.70 as permitted sender)
Message-ID: <4D9885EC.7040108@acm.org>
Date: Sun, 03 Apr 2011 07:36:28 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: [jira] [Created] (RIVER-395) Ill-behaved DiscoveryListener can
 terminate discovery notifier threads
References: 
 <2002442925.22384.1301522705714.JavaMail.tomcat@hel.zones.apache.org>
	<4D97EAE7.2060908@acm.org>
 <BANLkTimEL-6CpTU=p8h1GXmj6OW9+gt-tQ@mail.gmail.com>
In-Reply-To: <BANLkTimEL-6CpTU=p8h1GXmj6OW9+gt-tQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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