Skip to content

Broken Weblogic JMS “clustering”

I’ve ranted before that Weblogic 11g clustering/distribution technology of its messaging is fundamentally broken. Despite what Oracle claims, JMS in Weblogic is not clustered. Load balanced is a better description. It’s architectural – if any other technology (e.g. SOA Suite, EDN, etc) uses Weblogic JMS as its underlying messaging implementation, it will be broken too.

The problem is simple. In Weblogic, if you cluster a logical topic (or a queue) across two machines, underlying this you’ve actually got two uniquely named and non-cooperating physical topics, one on each member of the cluster. A topic message that is sent to the logical topic is delivered (copied) to both physical topics. Now, if your logical topic listener is also clustered, you’ve got, in effect, two physical topic listeners on two different, and non-cooperating, physical topics. The topic message is then always delivered twice – even if both listeners have identical durable subscription ids (i.e. indicating that they belong to the same logical component, which should only get the topic message once). This terrible architectural blunder occurs because there is physically underlying your logical configuration, totally separate, non-cooperating, uniquely-named topics on each of the cluster members, with what amounts to a JNDI name service hack in the middle to spray the load about your cluster. In other words, it is load balanced, not clustered. JMS Queues are the same – however its just that the implicit side-effects of the queue semantics – which ever only delivers to a single consumer even if there are many configured – means it isn’t impacted as much. Because of that semantic, a queue message is only delivered to one of the two physical queues (i.e. again, it’s load-balanced) so only one of your two clustered queue listeners gets the message. And there’s a terrible time-out based hack to redeliver the message to another member of your queue cluster just in case there isn’t any listener instances on the cluster that the message ends up on.

N.B. Coherence does not, apparently, have this massive architectural fail. If you need to do clustered fail-safe broadcast messaging in an Oracle Weblogic environment, do yourself a favour and use Coherence.


  1. pratik patel wrote:

    Have you tried other JMS providers to see if they behave the same? From my experience, if you hook up multiple listeners to a topic, regardless of durable sub ID, they will all get messages on the topic.

    Saturday, March 5, 2011 at 01:33 | Permalink
  2. Scot Mcphee wrote:


    A single logical listener that is clustered should not be regarded as multiple listeners.

    Even in Weblogic, if you bind an (unclustered) MDB to a topic, you’ll get multiple instances of the MDB started. Yet oddly enough only one of these instances will get the topic message. Weblogic understands in that context these are all one logical listening unit. Clusters are the same, only the listeners are distributed over multiple JVMs. The problem is the ancient JMS implementation in Weblogic and the “hack” they put together to make them cluster, which is a load-balancing hack.

    Saturday, March 5, 2011 at 08:36 | Permalink