Queues Clustering Question
Hi,
we are evaluatingSun System Message Queue for our j2ee application and after browsing the documentation we still have one single doubt which is actually slowing down our purchase.
The question is pretty simple,having more j2ee application servers running on different machines accessed via hardware load balancer,
is it possible to have different brokers (one per machine) with a shared store on a network drive, or better to have a "balanced" couple of queues (That's to say, have more queues with separated stores sycronized with each others'), and actually see them as a single queue (via hardware load balancer).
Thanks for your precious help
Michele Zaina
[721 byte] By [
MZaina] at [2007-11-25 21:54:53]
# 1
A couple of initial clarifications -
While it is the default with the Sun Application Server configuration, its optional whether or not you run a cluster of brokers with a cluster of app servers (you can run one or many)
A single broker will be faster but wont provide failover (specifically service availability) if something goes wrong.
If you want a single broker for all AS instances, you need to set the service up as "REMOTE"
In MQ, unless you set it up differently, all queues are "global". This means that you set up a single "queue" and consumers can produce or consume from any broker in the cluster. This means you dont need to set up the system to see the queue as the same on all brokers. Messages are stored on the broker they are produced to. e.g.
You have a cluster of two brokers (broker1 and broker2), a producer is on broker1 and a conumer is on broker2. The producer sends a message to broker1, it is stored and forward to broker2 where it is delivered to the consumer.
-
As far as the shared store MQ does not support a true "shared store" at this time (e.g. on database or persistence store used by all clients)
If you assign the brokers different instance names, you can use an NFS drive and place all file based stores under the same directory e.g. (paths vary on platform)
<location>/var/imq/instances/imqbroker1 - first broker filestore
<location>/var/imq/instances/imqbroker2 - second broker filestore
# 2
Thanks Linda for the exhaustive response.
There's still one thing I've not understand, if is not possible to have a true shared store, that means that message uniqueness can not be guarantee by the Queue System, and will be up to the producers to avoid collisions. Am I wrong ?
Best regards,
Michele
# 3
I'm not sure exactly what information you are looking for ...
Is the question what happens with failure of a broker or simply about how do we make sure a message is unique in a cluster (if so, let me know and I'll answer that one)
If the question is "how is a message guarenteed to be unique in normal operation"
MQ assigns each message a unique ID and we guarentee that the ID's are different in the cluster (actually it should be unique anywhere in a network). We dont use something like a sequence number (which would be the same on different brokers)
If the question is "the Message is copied over to another broker to deliver to a client how do we make sure that both brokers dont store the same message" ?
- we never store the message on more than one broker (the remote broker
simply delivers the message it doesnt store our route it)
# 4
Thanks again Linda for your answers, and please forgive me for my poor english.
You've hit the point, actually my question is
how do we make sure a message is unique in a cluster, is this possible, avoiding heavy changes on the producers (delegating the task to the message queue system) ?
Thanks again for all your precious help
Michele
