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.

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

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

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.

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.

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

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