RMI question

[Ian deSouza]

Is there anyway to test the state of a Remote (on the client) to see if
its still valid.

This is so I can issue another lookup if its not valid.

If the server went down and came back up after the client initially did
the lookup, the stub will throw a exception. But if I can do another
lookup before issuing the remote call, it will work.

Thanks for any assistance.

- Ian

 

[opalpa]

Is there anyway to test the state of a Remote (on the client) to see if
its still valid.

This is so I can issue another lookup if its not valid.

If the server went down and came back up after the client initially did
the lookup, the stub will throw a exception. But if I can do another
lookup before issuing the remote call, it will work.

Thanks for any assistance.

- Ian

What about doing lookup if an exception is thrown and then retrying?


What about always looking up before issuing remote calls?


Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[EJP]

Is there anyway to test the state of a Remote (on the client) to see if
its still valid.

As in all network programming and most other kinds, the only valid way
is to try to use it.

This is so I can issue another lookup if its not valid.

If the server went down and came back up after the client initially did
the lookup, the stub will throw a exception. But if I can do another
lookup before issuing the remote call, it will work.

If you get NoSuchObjectException, the stub is stale so you should redo
the lookup. If you get ConnectException or ConnectIOException the server
is down.

 

[Ian deSouza]

Thanks ESP, Opalinski,

I think I'll probably be using the lookup (maybe event the
LocateRegistry, in case it restarts) everytime. If the frequency of
calls is not too high, I think this will work.

I think when the server goes down, then up (stale remote), I was
getting a connection exception however.

From the programming side, it seems doing a lookup before each call

would be cleaner, than try catch with retrying the remote call for each
one of the calls..

Thanks for your suggestions, Ian

 

[opalpa]

A further thought. Using the scheme where a lookup precedes every
remote call can the server down between the lookup and the remote call?


I agree that at first it feels like enveloping every remote call in
try/catch is to make the source be littered with redundant code.

How many remote calls are there? Are the same remote calls repeated in
the source? Perhaps creating a facade on the client side is the thing
to do? The try/catch blocks would be inside the facade, perhaps even
with a count of retries.

Maybe even further: some try/catch generalization can happen inside of
the class providing the facade? I believe it can:


static private Object remoteCall(String remoteObjectToLookup, Method m,

Object args[], int nMaxTries) {

if (nMaxTries <= 0)
throw new IllegalStateException("failed making remote call " + m +

" to " + remoteObjectToLookup);

Object result = null;
boolean succeed = false;
try {
Object o = Naming.lookup(remoteObjectToLookup);
result = m.invoke(o, args);
succeeded = true;
} catch ( .... ) {
....
}

if (succeed)
return result;
else
remoteCall(remoteObjectToLookup,m,args,nMaxTries-1);

}

Such a generalized method would allow each public facade method to
avoid having it's own try/catch blocks.

Cheers,
Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[EJP]

I disagree with the suggestion to do the lookup before every method. As
has been pointed out, there is still a timing window between the lookup
and the call during which the stub can become invalid. So you have to
cope with that condition anyway, so you may as well save yourself the
extra lookups and reuse the same recovery code.

As I hinted before, in general, and particularly in networking, you just
can't 'look ahead' to see whether an operation will work and then assume
that it will. You just have to try it and cope with any failures.

 

[Ian deSouza]

Thanks for your suggestion. It seems valid. I do have a facade (wrapper
around my remote) that I'm calling into and I could do this.

Right now (to reduce code), I just retrieve the remote and make the
call directly.

I am a little surprised that this check can't be in the Remote. It
seems to me from my earlier socket programming, that a socket read will
occur when the connected socket goes down. And therefore the Remote
(stub) should be able to tell if its connected socket is still there.

Well, anyway.. thanks for the suggestion (I'm thinking on generating
all those wrapper methods to do that kind of pattern you suggested).
- Ian

 

[Ian deSouza]

Now I see what you are doing. Ignore my previously mail. You mean to
invoke the remoteCall from the calling object directly for all methods
invoking the Remote. Very good idea!

I'm going to try this. Thanks.