Support for cross-cluster HAJNDI list operations

[brian.stansberry]

HAJNDI implements the list and listBindings operations by listing what's in the replicated tree. It doesn't support creating aggregate lists of what's bound across the cluster.

Is there a particular reason why that just couldn't/shouldn't be supported, at least as a configurable option? I'm sure they'd be some semantics we'd have to document clearly (e.g. what we return in the typical case where things are bound under the same name across the cluster).

User wanting to federate HA-JNDI (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102322) si what's driving this question.

[starksm64]

Its just because list for HAJNDI generally only has normal jndi behavior for the replicated tree. However, since we really never bind stuff into this tree, list* is not a useful method. It could be implemented to match the lookup semantics and essentially return the first context.list result from the local jndi bindings in the cluster for the context.

If one really wants to see all of the bindings in a cluster, then I think we would have to return a NamingEnumeration with a NameClassPair that was a ClusteredNameClassPair to include the node in the pair. Otherwise we could go outside of the jndi api to provide this aggregate view.

[schaefera]

From my point of view the HAJNDI tree does not make much sense except for components that are only available on a subset of nodes within the cluster. In my case that would be HA-JMS because it can only run as a HA-Singleton.

This means that the HAJNDI tree cannot use the shortcut of just using the local JNDI tree because it may or may not be the Master node.

What I do not understand is the fact that by default nothing is bound to the HAJNDI. This means that when I need to lookup a HA-JMS object inside the cluster I will lookup the object every time (at least that is the case for 4.0.4 and 4.05) even though that is an expensive remote lookup over the entire cluster (in the worst case) and that on every lookup because the found object is not cached inside the TreeHead, isn't it.

-Andy

[schaefera]

In my http://www.madplanet.com/weblog/blog/schaefa/Madplanetcom/2007/02/22/Does-JBoss-HAJNDI-need-a-revamp-and-if-how.html recent blog entry I discussed the topic in more details but here is my design for a HAJNDI revamp:

In my view the HAJNDI tree should be populated whenever an entry is made to a JNDI server on a node in a cluster. The HAJNDI tree would cache the JNDI NameClassPair and the nodes on which it can be found but not the content of the entry. If a HAJNDI deregister the entries from this node are removed. During a lookup it would search the nodes until if can retrieve the desired objects from one node. If a node is unavailable it could be put to the back of the list. The HAJNDI list() method would return an enumeration of the cached NameClassPair without any duplication by the nodes.

In the lifetime of a regular application the deployment is happening rarely but the lookup and list methods are called many times. So the overhead of publishing a JNDI binding/unbinding over the entire cluster is much smaller than the time spent on the lookups and listings.

The last point here would be what happens when a node is temporarily separated from the cluster. Then a deployment could be done on this node or another node on the rest of the cluster. The only fix I see is that HAJNDI needs a way to replicate its structure with other HAJNDI servers when they are out of sync. RIght now I do not know how this can be done or what event would trigger that but it should be possible.

-Andy

[starksm64]

I certainly don't agree that a jndi bind should populate a replicated jndi tree in general. For the case of non-heterogenous bindings causing lookup performance problems, we could support specific context replication by marking the context as a clustered-singleton.

In reality, HAJNDI is not a true jndi implementation. Any push for a full clustered JNDI implementation needs a redesign of the HAJNDI layer to be based on jboss cache along with aspects to support efficient replication of what JNDI bindings should be replicated.

[jerrygauth]

As Scott noted, HAJNDI 's list() and listBindings() operations are based upon the corresponding JNDI operations. Consequently they only return entries relative to the HAJNDI tree. It is possible to bind to the HAJNDI tree although this probably isn't done by any JBoss modules right now. Entries bound to the HAJNDI tree are replicated throughout the cluster and consequently readily available on all nodes via HAJNDI.

There's probably no reason why HAJNDI can't offer new operations that return all bindings in a cluster. As Brian noted, it would be necessary to determine how to handle situations where objects are bound under the same key on multiple local nodes. Alternatively, the operation might return all bindings for all nodes in the cluster, identifying the node associated with each key/value binding.

For reference - HAJNDI in JBoss 5 is based on JBossCache but JBossCache is only used for entries bound in HAJNDI. Local bindings are outside the scope of HAJNDI and currently aren't stored in JBossCache.

[schaefera]

If you don't want to fix it why can't then at least the entries from the HA-Singleton be entered into the HAJNDI because that are the most likely candidates not to be found on a local JNDI.list() call?

-Andy

[brian.stansberry]

If the primary goal is to have performant lookups, then yes, binding the HA-JMS entries in HA-JNDI is what would be needed. (They'd need to be in regular JNDI as well, as local services may be expecting to find them there.)

This would have to be done in JBossMQ, or more likely in an HA integration mbean that's deployed along with JBossMQ in the all config. If done in JBossMQ itself, that would require the MQ code to know how to create an HA-JNDI context. If done in an external integration mbean, the mbean would need to know about the various InvocationLayers that are deployed (doable although maybe not in a nice clean way) and the various destinations that are deployed (not sure about doing that.)

[starksm64]

It needs to be demonstrated that would be the best solution. List could also be implemented as Brian said.