This content has been marked as final. Show 8 replies
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.
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 18.104.22.168 (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 22.214.171.124 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)