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
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3887747#3887747
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3887747
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
