Here's my setup: I have a client that looks up and uses a bean that is deployed on a server. This server is part of a cluster, however the particular bean is only located on that one server.
Now the problem: if I move the bean in the cluster from one server to another the next invocation of one of the beans methods will result in a "Service unavailable." exception. And the only way to get it to work again is to lookup the bean again.
I've read the clustering documentation and, as far as I understand, this is actually expected behavior. Initially the client's RMI stub only has one address of where the bean is located and it can only receive new locations if it actually invokes the beans methods. Because those new addresses are piggybacked to the RMI replies. So if the bean is moved in between invocations there is no way the stub can now the new location.
So this brings me to my first question: Is this correct or is something else causing the exception?
If so, I can see 2 solutions:
* catch the "Service unavailable." exception and do a new lookup
* somehow invoke a method on the bean when it is deployed on both servers. I'm guessing maybe by adding a dummy method.
However, those solutions both involve changes to the client program, something which I'd rather not do, because the client developer should not need to know about this. I'm currently considering adding extra functionallity to the JRMPInvokerProxyHA but I would like to see first if there are easier solutions.
So my second question: Any one know other/better/easier solutions?