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 Mon, 04 Apr 2011 08:44:08 GMT
Can't do anything about the Throwable as it's part of InvocationHandler and
that's the JDK spec.

Could agree that our Dispatcher's only ever throw some specific subclasses.
We'd have to do some diligence on that as BasicInvocationDispatcher and
friends are designed to follow RMI spec, not entirely sure all other
transports can do enough in that respect to be compliant.

There is one other problem with this however which is that badly written
service code could chuck out stuff that is not compliant and bring down the
entire house - that's kind of denial of service territory....

...personally I'd rather leave the catch throwable, log at some suitable
level and leave it at that, at least until we gather some data as to how
often this problem bites us etc.

On 4 April 2011 09:07, Tom Hobbs <tvhobbs@googlemail.com> wrote:

> Thanks for the info, Dan.  Of course the next most obvious question is, can
> we make this better?
> Can the throwable catch be replaced with an Exception and a ServerError
> catch.  Of course this means making the docs explicit in that all remote
> stacks must behave as BasicInvocationDispatcher does and also changing the
> signature of InvocationHandler.invoke.
> Is it as easy as that, does anyone know?  To my gut, being able to
> distinguish between a remote and a local critical problem would be a good
> thing.
> I'm just curious to see if rather than judging over things like this with
> log statements whether or not we can improve the behaviour.
> Cheers,
> Tom
> On 3 Apr 2011 21:19, "Dan Creswell" <dan.creswell@gmail.com> wrote:
> An Error gets wrapped into a ServerError which is a subclass of remote
> exception so long as you're using a BasicInvocationDispatcher (see the
> description for dispatch).
> For other remote stacks you mightn't get such behaviour and as far as I can
> see from a quick skim of the docs, it's not explicitly required to behave
> as
> BasicInvocationDispatcher does. Note also that InvocationHandler.invoke
> throws Throwable which allows the proxy of a remote service implementation
> to return anything it likes for any reason e.g. Error.
> Dan.
> On 3 April 2011 20:33, Tom Hobbs <tvhobbs@googlemail.com> wrote:
> > I'm not saying you're wrong, I'...

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