In the document "clustering guide", section "5.2.2. For clients running outside the application server",
it reads:"When initialising, the JNP client code will try to get in touch with each server node from the list,one after the other, stopping as soon as one server has been reached. It will then download theHA-JNDI stub from this node. The downloaded smart proxy contains the list of currently running nodes and the logic to load balance naming requests and to fail-over to another node if necessary. Furthermore, each time a
JNDI invocation is made to the server, the list of targets in the proxy interceptor is updated (only
if the list has changed since the last call)."
But what I find is the ha-jndi proxy is NOT smart enough.
What I do to test the smart proxy is:
1. deploy a clustered ejb on a cluster of two nodes.
2. look up the clustered ejb
3. sleep current thread 3 mins
4. shutdown the server where the ha-jndi proxy is downloaded from
5. again, lookup the clustered ejb using the same Initicontext.
6. I get exception "javax.naming.CommunicationException [Root exception is java.rmi.RemoteException: Service unavailable.; nested exception is:
java.rmi.ConnectException: Connection refused to host: 10.28.71.51; nested exception is:
java.net.ConnectException: Connection refused: connect]"
As my understanding from the document, the ha-jndi proxy should be smart enough to connect to the other server, but it doesn't.
Would the sleep of the thread be the problematic?
The thread is suspended and the server has no chance to update the ha-jndi proxy about cluster's changes?
any comments would be appreciated