4 Replies Latest reply on Feb 28, 2006 4:30 AM by Petr Matejka

    Co-located HA JNDI and EJB Clients

    Shreenivas Kand Newbie

      I have been having some trouble with the HA JNDI configuration. I did get it to work, but I am hoping to find a better way to do what I need. I believe I am missing something pretty basic and simple, but I have failed miserably to find any documented hints in this regard. Hence, this post.

      My 'architecture' has a SLSB that writes a message to an HA JMS Queue which results in triggering an MDB. This MDB calls another SLSB which again does the same - write a message to an HA JMS Queue and so on.

      All this works as expected on a standalone system. The trouble begins with HA configuration. The initial setup is pretty straightforward once I use the 'all' server config as my starting point. So, I have two machines nodes with the 'all' config and the JMS queues are deployed in the ha-singleton. On startup, one of them is indeed the master.

      Now, I understand that to ensure that I am using HA JNDI to get to the queues I have to create the InitialContext with the HA JNDI port 1100. I, of course, do not want to hard code this 1100 in my app. Actually, I do not want to worry about it at dev time at all. So, I use the server/all/conf/jndi.properties file and set the provider url to use :1100. But, as soon as I do this, the AS does not startup as cleanly as it did without this change. My guess is that the AS does need the default 1099 (non HA JNDI) for bootstrapping and me chaning the provider url basically masks the access to the regular JNDI.

      This appears like a chicken-n-egg -- to ensure that the AS startsup cleanly I cannot change conf/jndi.properties to include the HA JNDI provider url. But, without the HA JNDI provider url, I cannot get my queue via the HA JNDI.

      So, as a solution (this is hokey) I change the jndi.properteis file AFTER the AS as started up and BEFORE I deploy my application in the farm directory of one node. This works just fine. But, this really makes the hot deployment pretty messy since there is this config in jndi.properties that I have to ensure that I undo and do before I restart any AS instance. Though, this is trivially done using a script to start/stop it seems a hard sell for the ops guys to use my scripts over JBoss Inc's.

      I already feel dumb asking this question - any ideas what I might be missing? Is there an easier way to deploy an application (EAR in my case) specific jndi.properties that is not part of the EAR file. The ops guys argue that it is pretty inconvenient to unpack the EAR file then add a new config file and pack it again for every deployment.

      Thanks and apologies for this long post.
      -shree