-
45. Re: Naming over Remoting 3
Use of HA-JNDI allows the client to know how to contact all the servers using whatever transport was used to reach HA-JNDI.
It doesn't know which of those servers have a particular bean deployed. Deployments aren't necessarily homogenous and almost certainly aren't during startup/shutdown periods. So, the bean topology needs to come with the bean proxy. The load balancing policy as well, as that's bean specific.
That said, sure, the information that comes with the bean proxy doesn't have to be transport-specific; it can just be a key that drives a lookup.
The load balancing/failover would have to deal with the case where the bean is deployed on nodes where the desired transport is unavailable. Say the HA-JNDI lookup was done via HTTP, and node1 and node2 are available via HTTP. But the bean is deployed on node1, node2, node3. Either the LBP needs logic to not pick node3 or the attempt to reach node3 needs to promptly fail with a transparent failover to node1/2.
The downside to all this is the behavior of the bean is now a function of how JNDI was accessed. If you look up a clustered bean via regular JNDI, the client only knows how to contact one server, so it's not really an HA bean any more. If we're going to say the JNDI usage controls the bean behavior, the opposite case should be true as well; any bean that's looked up via HA-JNDI should have failover/loadbalancing. That can be done easily enough except for the SFSB state replication part.
Another downside is bean proxies are serializable objects that can be passed between client VMs. You can't assume the client invoking on the proxy is running in a VM that's done a JNDI lookup. I have a vague unpleasant memory of squashing bugs in this area during my early days at JBoss.
-
46. Re: Naming over Remoting 3
I've noticed an aspect of the JBoss Naming semantics that struck me as odd, although it doesn't seem to violate the JNDI semantics. In particular, the implementation of InitialContext.createSubcontext() seems somewhat unintuitive. The output of
InitialContext context = new InitialContext(env);
// Create subcontext.
Context sub = context.createSubcontext("sub");
sub.bind("s1", "abc");
context.bind("sub/s2", "xyz");
System.out.print("remote bindings [root]: ");
NamingEnumeration<Binding> enumeration = context.listBindings("");
while (enumeration.hasMoreElements()) {
Binding binding = enumeration.nextElement();
System.out.println(binding.getName() + "->" + binding.getObject());
}
System.out.print("remote bindings [sub]: ");
enumeration = context.listBindings("sub");
while (enumeration.hasMoreElements()) {
Binding binding = enumeration.nextElement();
System.out.println(binding.getName() + "->" + binding.getObject());
}
System.out.print("local bindings: ");
enumeration = sub.listBindings("");
while (enumeration.hasMoreElements()) {
Binding binding = enumeration.nextElement();
System.out.println(binding.getName() + "->" + binding.getObject());
}
is
remote bindings [root]: sub->org.jnp.interfaces.NamingContext@5a676437
remote bindings [sub]: s2->xyz
local bindings: s1->abc
The point is that, even though the call context.createSubcontext("sub") creates a subcontext on the server, the call sub.bind("s1", "abc") inserts a binding locally but not on the server. The reason is that, while the call to new InitialContext(env) returns a client proxy to the remote NameServer, the call to context.createSubcontext("sub") returns a serialized copy of the new subcontext NameServer created on the server. So the call to sub.bind("s1", "abc") affects only the local copy of the NameServer.
I'm curious if anyone knows why this is so. I assume it's intentional ... just verifying.