I have a cluster with HA-JMS running and using an external context to access object on that cluster from a remote JBoss AS. That works fine with a standalone JBoss server but not with a cluster because I either need to know at all times how is the Master JMS node or I need to use HAJNDI.list() method instead of the regular naming server.
Unfortunately no JNDI bindings are registered with the HAJNDI server and when a client tries to lookup an entry through HAJNDI (port 1100) the only thing the HAJNDI does is to find a server where it can find the entry locally (see lookupLOcally and _lookupLocally on class TreeHead). Therefore HAJNDI will always return an empty list when list() is called.
I wouldn't care that much about HAJNDI if it would not be for HA-JMS. Because I do not know on which node the HA-JMS is running on right now I need to use HAJNDI.
Is there any way to make JBoss bind through HAJNDI rather the regular naming server?
Thanx - Andy
I am using an external context 'org.jboss.naming.ExternalContext' which federates in the JNDI context of a remote JBoss AS. Because I am using HA-JMS on that remote JBoss AS I need to use the HAJNDI rather than a local JBoss Naming Server because I do not know which server does actually host the HA-JMS at that time. Here is my external context defintion:
<mbean code="org.jboss.naming.ExternalContext" name=":service=ExternalContext,jndiName=external/context" > <attribute name="JndiName">external/context</attribute> <attribute name="Properties"> java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces java.naming.provider.url=host1:1100,host2:110 </attribute> <attribute name="InitialContext">javax.naming.InitialContext</attribute> <attribute name="RemoteAccess">true</attribute> </mbean>
In addition JNDIView MBean has an entry at the bottom that should list the entries in the HAJNDI but it is always empty because HAJNDI.list() is returning an empty list.
HA-JMS can't be configured to bind into the replicated HAJNDI tree.
Do you have to use the federated context for the HA-JMS lookups? Could you create an InitialContext configured to use the remote HA-JNDI. You wouldn't get the list() behavior you want from that, but you'd be able to do JMS-related lookups.
I've opened a thread at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102451 to discuss the feasability of having HA-JNDI aggregate list results from the local JNDIs across the cluster.
Of course I could use another InitialContext but in my opinion that is a hack for an EJB on a remote application server. I know that the federated context is not really EJB standard as well but it would let me use remote EJBs within ejb-ref or resource-ref within an EJB.
Isn't it strange that HA-JMS cannot be found into the HAJNDI tree even though it is the only component, at least I know of, that need to be bound there because it has to run inside a HA-Singleton.
Just to get a clear understanding here what is bound to the HAJNDI tree ever? I have a clustered SLSB and that is not bound there and so what is or what do I need to do in order to bind my SLSB into the HAJNDI tree.
To bind something into the HAJNDI tree, you would obtain an initial context specifying an HAJNDI port rather than a JNDI port. Anything that you bound using that context would be placed in the HAJNDI tree and would only be accessible via HAJNDI.
HAJNDI bindings are replicated to all nodes in the cluster. In JBoss 5, HAJNDI bindings are stored in JBossCache, which also handles the replication. In prior server versions, HAJNDI maintains its own store.