HA-JNDI and JNDI for cluster access

[timjer]

Hi,
can anybody tell me what is difference between case1(1099) and case2(1100)?
it seem both notation work for cluster-access by client.

thanks in advance

case1:
Properties props = new Properties();
...
props.put("java.naming.provider.url", "server1:1099,server2:1099,server3:1099");
context = new InitialContext(props);

case2:
Properties props = new Properties();
...
props.put("java.naming.provider.url", "server1:1100,server2:1100,server3:1100");
context = new InitialContext(props);

[brian.stansberry]

To continue your use case beyond what you wrote to include actual use of the context:

Object foo = context.lookup("Foo");

.... then server context has connected to fails or is shut down

Object bar = context.lookup("Bar");

1) With case2, the lookup of "Bar" will succeed; with case1 it will not. The case2 client side naming proxy includes clustering behavior that supports transparent failover.

2) In the above example, with case2 the lookups will be load balanced to the available servers; in case 1 they will all go to server1.

3) If "Foo" were only bound in JNDI on server2, the lookup of Foo will fail in case1; with case2 the server-side HA-JNDI service on whatever server the client connects to will transparently find Foo and return it.

[jerrygauth]

JNDI (i.e., port 1099) will only perform the lookup on the local server's JNDI bindings

HA-JNDI (i.e., port 1100) will search the following until the requested object is located.
1) the cluster's HA-JNDI bindings
2) the local server's JNDI bindings
3) all other cluster servers' JNDI bindings

Note that if you create an initial context using HA-JNDI and then bind something via that context, the binding is to HA-JNDI and is replicated across the cluster. HA-JNDI bindings are not visible to JNDI contexts (i.e., port 1099).

[timjer]

To continue your use case beyond what you wrote to include actual use of the context:

Object foo = context.lookup("Foo");

.... then server context has connected to fails or is shut down

Object bar = context.lookup("Bar");

1) With case2, the lookup of "Bar" will succeed; with case1 it will not. The case2 client side naming proxy includes clustering behavior that supports transparent failover.

2) In the above example, with case2 the lookups will be load balanced to the available servers; in case 1 they will all go to server1.

Hmm? you mean in case1 only server1 aktiv? server2 and server3 will be ignored?
there is not difference betwenn
props.put("java.naming.provider.url", "server1:1099,server2:1099,server3:1099");
and
props.put("java.naming.provider.url", "server1:1099,");
or sorry i don`t understand :-)



3) If "Foo" were only bound in JNDI on server2, the lookup of Foo will fail in case1; with case2 the server-side HA-JNDI service on whatever server the client connects to will transparently find Foo and return it.

[brian.stansberry]

There's a two stage process:

1) The code cycles through the list of URLs you provide, attempting to contact a server and download a naming proxy. At this point, providing mutliple URLs helps in case1, since if server1 is not available it can try server2, etc.

2) Once you contact a server, there's a big difference between regular JNDI and HA-JNDI. Now you have a proxy; it's the proxy that communicates with the server to do the lookup. Let's say that server1 was running. Step #1 iterates through the list in order, so server1 will provide the proxy.

a) With regular JNDI, the naming proxy you download will only know how to talk to the server it came from (server1). If server1 subsequently fails, the proxy can't recover; the exception propagates to your code. You can catch the exception, and do "context = new InitialContext(props)" again to recover, but you have to manage it.

b) With HA-JNDI, the naming proxy you download will have clustering logic and cluster topology info inside of it. It will know that server2 and server3 are all running. When you do a lookup it will load balance requests across them. If a call fails, it can transparently fail over to a different server.