> 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 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
> As in all network programming and most other kinds, the only valid way
> is to try to use it.
> If you get NoSuchObjectException, the stub is stale so you should redo
> the lookup. If you get ConnectException or ConnectIOException the server
> is down.
opalpa@gmail.com opalinski from opalpaweb - 23 Sep 2006 16:49 GMT
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
opalpa@gmail.com
http://www.geocities.com/opalpaweb/
> Thanks ESP, Opalinski,
>
[quoted text clipped - 17 lines]
> > the lookup. If you get ConnectException or ConnectIOException the server
> > is down.
EJP - 28 Sep 2006 01:02 GMT
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 - 28 Sep 2006 21:03 GMT
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 - 28 Sep 2006 21:08 GMT
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.