How to configure remote client to attempt to connect to all JMS servers, to find the live one

[dshifrin]

I have clustered multiple wildfly servers.  Specifically, we have 4 JMS servers with one serving as live and the rest as backups (1 as backup and the other 2 as passive). We have a standalone application that runs on a different server and connects the clustered environment to put messages on a queue. This works great when no failover has occurred.  Once failover occurs, the remote application can longer connect to the cluster, specifically it throws a nameNotFoundException for the JNDI name of the queue it should place messages on. What is the proper way to set this up?

the connection code looks like this

env = new Hashtable<String, String>();

env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);

env.put(Context.PROVIDER_URL, configuration.getServerUrl());

env.put(Context.SECURITY_PRINCIPAL, configuration.getSecurityPrincipal());

env.put(Context.SECURITY_CREDENTIALS, configuration.getSecurityCredentials());

ctx = new InitialContext(env);           

queue = (Queue)ctx.lookup(JNDINames.DFP_QUEUE_REMOTE);

conFactory =

ctx.lookup(JNDINames.DFP_FACTORY_REMOTE);

connection = conFactory.createQueueConnection(configuration.getSecurityPrincipal(), configuration.getSecurityCredentials());

producerSession = connection.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);

producer = producerSession.createSender(queue);

connection, producerSession, producer);

connection.start();

the properties file being read by the configuration object above looks like this

     server.url=http-remoting://<server1 hostname>:<port>,http-remoting://<server2 hostname>:<port>,http-remoting://<server3 hostname>:<port>, http-remoting://<server4 hostname>:<port>

     security.principal=username

     security.credentials=pword

When server1 is the live server everything works as desired.  As soon as one of the other servers is live, we see a nameNotFoundException (which to me indicates its looking on a server that is not live and thus doesn't have any queues defined on it).  Internal (running within the cluster) MDBs failover to the new live server as desired. We are using Wildfly 9.0.1 and HornetQ 2.4.7.  Thanks in advance for any suggestions provided.

[jbertram]

This indicates to me that either the JNDI lookup happened before the backup was fully active and had deployed all the proper destinations or that the the backup doesn't have all the proper destinations defined.

[mnovak]

Hi David,

Justin is right, there are most likely missing CFs/Queues/Topics in configuration of messaging subsystem on "backup" servers. Note also that backup will deploy those objects to JNDI only if it activates so if you add them to configuration of backup serves then only if you kill live server then CFs/Queues/Topics will deploy to JNDI of WF server with backup.

I have on important note to this, WF9 supports only one backup per live. Having 2 more backups in HA with replicated journal will not work (it can work with shared store). Also deploying MDB on WF 9 with backup server is really not good as if live starts again and backup shutdown then MDB looses connection to this backup and gets a bunch of errors.

I would suggest you to configure HornetQ in collocated topology. This means that each WF9 server contains live and then backup for another live in cluster. It would look like WF1(live1,backup2) <-> WF2(live2,backup1), WF3(live3,backup4) <->WF4(live4,backup3). Now all WF9 servers are active (MDB on can process messages from local live server) and when any of WF servers crashes then there is backup on another WF server which will activate.

Is it ok for your use case?

Thanks,

Mirek

[dshifrin]

Thank you both for your replies!!

We fixed the issue by wrapping the above code in a loop which would loop through every server listed in the server.url property in the properties file. We try each server, one by one, and if any exception is thrown then we go to the next server in the list. If all servers are tried without success then we fail, otherwise we end up connected to something and that something has the queues.