This is a discussion on May several severs use the same JMS Queue? - Weblogic ; Layman's questions We currently have the following set up: + several Weblogic 8 servers (acting as JMS clients and servers) + several of these JMS clients can address any of two JMS server for a service. + we use a ...
We currently have the following set up:
+ several Weblogic 8 servers (acting as JMS clients and servers)
+ several of these JMS clients can address any of two JMS server for a
+ we use a load balancer in between in an attempt to load balance the
requests but this has not proven very efficient as the requests can be
of very different natures (some are very long, others very short).
I was therefore wondering if we could not share a single JMS Queue and
have or two (Weblogic) JMS server come up and pick up the messages as
they are ready on this single queue (this would naturally and
adaptatively load balance).
As I understand, clients have to address a given single server to have
their JMS messages taken care of (they can't write immediately to a
physical Queue, they have to send a message to a JMS server who will
persist it if need be but actually keeps messages in memory).
Could one of my two Weblogic JMS servers act as the single primary
server (receiving the requests), persist the messages on a RAID disk and
then have its MDB or the other server's MDB pick up the messages as
these MDB become free? If not could both JMS servers aplplication simply
scan (read rather than onMessage) this common JMS queue?
If this is not possible, why?
If this is possible, what would happen if the primary JMS server died?
Is there a mechanism in Weblogic to automatically have the second
Weblogic JMS server take over (it will handle the JMS requests and
persists the message on the same persistent RAID store) ? If not, why not?
(I have been told that clustering does not actually share the same
persistent store and JMS memory queue, each member of the cluster has a
different JMS queue in effect)
Sorry for the many questions, I hope it is understandable.