1 Reply Latest reply on Jan 27, 2012 12:07 AM by DaveRorke

    Can one JMS outbound adapter send events to more then 1 queue/topic?


      We are tryin to build an HA solution for one of our customers. One of the components that we need to make HA is the queue. We are thinking to do that by using distributed queue.

      In the configuration file for the adapter we need put the URL of only 1 queue. If the network fails how the adapter will fail to the second queue?

      So my questions are:

      Is there a configuration for the JMS outbound adapter so it can send messages to 2 different queue?
      Is there a configuration for the JMS inboundadapter so it can get messages to 2 different queue?
      Is there best practice for this situation?

        • 1. Re: Can one JMS outbound adapter send events to more then 1 queue/topic?
          I responded on another thread regarding the issues of distributed topics and CEP HA:

          Re: JMS distrubuted topic and jms inbound adapter

          but this seems to be a slightly different question so I'll try to address this one here.

          To configure either the JMS inbound or outbound adapter to use a distributed queue, you simply use the logical name of the distributed queue when configuring the destination-name or destination-jndi-name.

          When a server hosting one member of a distributed queue fails, there is some attempt by the JMS outbound adapter (as a producer) to reconnect to a surviving server hosting another member of the queue. I believe there are some edge cases and limitations to this reconnect support (you may want to try the JMS forum for details on this). Similarly the inbound adapter will be pinned to a specific queue member when it establishes its connection but will attempt to reconnect if that member goes down (again there may be cases where the reconnect doesn't work).

          More importantly from an HA standpoint, when a queue member fails any non-persistent messages that were directed to that queue instance are lost and any persistent messages are stuck on the failed server's queue until either the failed server is restarted or the JMS server containing the failed queue is migrated to another WLS server instance.

          Given the above you may want to consider whether a non-distributed queue with persistent messages will provide an equivalent level of HA in your case without the complexity of a distributed queue.
          1 person found this helpful