We are building a HA application using precise recovery using JMS. FOr that we want to create a distributed JMS Topic (ckustered JMS Topic). As we understand things, when a JMS subscriber subscribes to a distributed Topic it is actually wired to a sopecific server (a specific fisical JMS Topic). When this JMS server fails the connection is dropped and the JMS subscriber needs to reconnect.
1. Is our understanging correct?
2. If yes and we need to reconnect to the surviving JMS Topic, is there a way to "tell" the JMS Inbound adapter to do so? Is it done automatically by the adapter?
Hi This is the description from WebLogic for distributed topic, basically, it's something like cluster: single node failure should not result in out of service.
Defines a set of topics that are distributed on multiple JMS servers, but which are accessible as a single, logical topic to JMS clients.
Distributed topics can help with load balancing and distribution, and have many of the same properties as standalone topics.
My concern is specifically as a JMS consumer (CEP application that consumes messages from the topic). Clustering provides high availability but when it comes to consumers in order for it to work automatically (to move the JMS consumer to the surviving topic) it is stated in the WebLogic documentation:
+"In addition, JMS consumer session objects can also be configured to automatically attempt to reconnect to an available server, but due to their potentially asynchronous nature, you must explicitly enable this capability using the Administration Console or public WebLogic JMS APIs."+
I am looking at: http://docs.oracle.com/cd/E21764_01/web.1111/e13727/recover.htm#autoId0
My question is: does the out-of-the-box JMS inbound adapter supports this automatic reconnect?
Maybe the question needs to be: does the out-of-the-box JMS inbound adapter needs to implement something to support this or is all the "reconnect" part is done from the JMS server side?
Edited by: 884793 on Jan 4, 2012 11:18 PM
Edited by: 884793 on Jan 4, 2012 11:20 PM
To ensure that consumers will reconnect to a surviving server you should administratively set the Reconnect Policy to "All" on the WLS JMS server console as described here:
With this configuration the inbound adapter should failover automatically as described in the docs.
How does the consumer know how to move to the second topic?
In the consumer configuration file (the adapter configuration file) there is an entry for the jndi-provider-url+ which state only 1 IP. So how does the adapter can know the IP of the second server?
But on the JMS adapter config there is only the ip of one of the servers. How does the WLS tell the adapter to go to the IP of the second queue or topic if the WLS instance that the adapter is communicating with is not available because of network failure on the WLS side?
There are a few different things you should be considering when configuring JMS for precise recovery, so I'm afraid this is going to be a long response.
* The precise recovery feature may not work correctly in the case where JMS output messages are lost. Avoiding message loss in the case of a JMS failure involving topics requires the use of persistent messages and durable subscribers. This is true regardless of whether you're using Distributed Topics or a Topic hosted by a single server. So use of durable subscribers is highly recommended when using CEP precise recovery.
* The CEP JMS input adapter won't actually support durable subscriptions until the upcoming 220.127.116.11 (PS5) release. So if you want to use durable subscriptions to avoid problems with precise recovery in the case of JMS server failure you would need to be on this release of CEP (at least for production).
* If you're using the CEP JMS inbound adapter with a distributed topic and a non-durable subscription, you can configure the adapter destination-jndi-name with the logical name of the topic and if the topic member servicing a given consumer fails, the consumer will reconnect to a surviving topic member. This works because you're using a logical destination name (not a physical host name or IP address), so the adapter is able to determine the surviving servers associated with the logical topic and reconnect to one of them. However since you'd be using non-durable subscriptions in this case to achieve failover/reconnect, you can have the problem described above with message loss and precise recovery (non-durable subscribers/non-persistent messaging can lose messages during the actual failover/reconnect).
* Unfortunately, WLS doesn't support durable subscriptions to distributed topics using the logical destination name. When using distributed topics you can only create durable subscriptions on specific topic members, and since these are subscriptions to a specific physical member these subscribers won't failover to another topic member if the server hosting their subscription fails.
So given all of the above you can see that the use of distributed topics with CEP precise recovery may not provide the ideal level of HA (the ability to handle combinations of JMS and CEP failures). You might want to consider using a non-distributed (single server) topic with persistent messaging and durable subscriptions as an alternate approach for precise recovery. In this configuration JMS server failure would require restarting the failed server, but once the JMS server is restarted there should be no message loss and CEP precise recovery should work correctly.
If you're determined to use distributed topics you might want to try posting to the JMS forum to see if anyone there has ideas for other solutions. Just let them know that CEP in this case is essentially acting as a vanilla JMS client (not MDB based) that can't tolerate message loss: WebLogic Server - JMS
Thanks for the very clear and comprehensive answer.
Do you know when 18.104.22.168 will be released?
One more question:
WebLogic supports multiple hosts in the URL. For example t3://hosatA:portA,hostB:portB. Does the JMS adapter support this? If yes, will it try to reconnect/failover to the surviving JMS in case of a failure of the JMS it is connected to? (I mean, will it try to use it not just at application statup but also after the application is running)