RMI - connection refused listener

[VisionSet]

Has anyone got any nice approach for detecting this, other than catching
every ConnectException for every method call.
Here's a thought, why haven't Exceptions been enabled with listeners?

I do have an client side adapter, that all remote methods run through, I
could add listeners to that and intercept ConnectExceptions before notifying
listeners.
Is that my best bet?

 

[Paul Lutus]

Has anyone got any nice approach for detecting this, other than catching
every ConnectException for every method call.

No, that is the best way to handle this. Nothing happens until the actual
problem arises.

Here's a thought, why haven't Exceptions been enabled with listeners?

They have, but you have to type them into your program. They're called
"try ... catch" clauses.

I do have an client side adapter, that all remote methods run through, I
could add listeners to that and intercept ConnectExceptions before
notifying listeners.
Is that my best bet?

Is that you best bet to solve what unstated problem? Why is the exception
that is generated not suitable for your purpose?

 

[VisionSet]

Is that you best bet to solve what unstated problem? Why is the exception
that is generated not suitable for your purpose?

Back in your box Lutus!

 

[Paul Lutus]

Back in your box Lutus!

Post something useful or stop posting. This is a technical newsgroup, not a
playground for overgrown adolescents.

 

[VisionSet]

Post something useful or stop posting. This is a technical newsgroup, not a
playground for overgrown adolescents.

My adapter for an RMI remote object has 5 remote methods.
These may be called for many places 20 at present probably 100 eventually.

Do I really want to explicitly catch and deal with ConnectException
identically every time?
I wondered if there already existed a notification mechanism or if there was
a better way than rolling my own listener.

You can come out of your box if you play nicely, probably a forlorn hope.

 

[Paul Lutus]

My adapter for an RMI remote object has 5 remote methods.
These may be called for many places 20 at present probably 100 eventually.

This is why you can specify "throws" about any exception in the definition
of a method, so the exception is passed up the hierarchical tree, to (if
you prefer) a single handler for all such exceptions. This is way more
efficient than using a listener.

Do I really want to explicitly catch and deal with ConnectException
identically every time?

Yes, you really want to do that. Build it into your class, make the handling
of this exception an integral part of your overall program structure.

Also, what did you plan to do instead? Why not ask yourself what will happen
if you do not handle each case of this exception.

I wondered if there already existed a notification mechanism or if there
was a better way than rolling my own listener.

You do not want to use a listener, this is the wrong approach. This is an
example ideally suited for the try ... catch clause. In fact, if you
insisted on using a listener, it would have to be integrated into a try ...
catch clause in order to be effective.

 

[VisionSet]

....

You do not want to use a listener, this is the wrong approach. This is an
example ideally suited for the try ... catch clause. In fact, if you
insisted on using a listener, it would have to be integrated into a try ....
catch clause in order to be effective.

Thanks Paul.
Typical foggy thinking on my part.
Sorry for the insults.

 

[Sudsy]

VisionSet wrote:

Do I really want to explicitly catch and deal with ConnectException
identically every time?

<snip>

Probably not, which is why I create a "wrapper" in these cases. It
should retry up to a specified limit before throwing an exception
if the connection cannot be established. I use the same approach
when circumstances dictate that I use JDBC connections (stateless
session EJBs rather than entity EJBs) and might (will!) run into
situations where the network connection is lost.
Someone unplugs the server (or trips over the power cord) or some
other unforeseen even occurs...
You always have to program "defensively", making allowances for
those scenarios which should "never occur". The wrapper approach
has always worked well for me and protects against intermittent
communication loss.
YMMV