Many consumers on a queue, with different selctor, 2 in an HA configuration
Hi all,
I have a question about one queue and some (3) consumers. I have one queue and three consumers (clients) connected to the same queue. Let' s call the consumer: A, B, C. All of these with selectors, connecting a SunOneMQ 3.5 SP2, 4 brokers cluster. Let's define the nature of the A, B, C client consumers:
Client A and B have the same selector and should work in a high availability configuration, so that if A fails, B will take its place, and viceversa: if A is running, B will not.
On the same queue of A and B I have another consumer, we will call it "C", that has a selector that is different from A and B (we said A and B have the same selector). So only A and B have to be in failover-safe configuration. I have not configured any backup consumers, all are active. What will happen is this case in your opinion ? Will I be able to see working the A and B failover configuration and independently the C one simultaneosuly ? I mean A or B and C all of them running fine ?
Thanks for your assistance.
Stefano.
[1069 byte] By [
stfalcon] at [2007-11-14]
> I have not configured
> any backup consumers, all are active.
Assuming you are using the enterprise edition...
The scenario you are describing has A and B running in parallel, not in a fail over manner. So A and B will be consuming messages in parallel, and so is C. Now depending on the consumption speed, and the production speed, you may need to tweek the imqConnectionFlowLimit and the imqConsumerFlowLimit. If the limit is to high, you may see A or B consumer most of the messages. And if the limit is too low, you will be chatting more than you need to on the network. The right balance is dependent on your environment.
HTH
TE
Right,
Mainly my problem is if a selector can lock and so lock the other queue consumers like C. MQ is the enterprise edition, A B C are all running and in parallel. So that, in a network failover scenario for A or B, does C continue to receive ? I mean if a consumer crashes on the network, and maybe it is not correctly unregistered from the brokers, am I sure that other consumer (with may be) a different selector (the C), continues to get its own messages ? Hmmm according to this advice from you, should I ensure a low flow limit to be sure that no lock situation can occur or just endure for a short time ?
Thanks for you post.
Stefano.
A selector should not lock messages onto a queue. Is that what you are seeing? A selector should filter the messages from the destination, so that only a subset with the corresponding messages with the proper qualifiers would be visible to the consumer.
> in a network failover scenario for A or B, does C continue to receive ?
C should not be impacted by A or B
> I mean if a consumer crashes on the network, and maybe it is not correctly unregistered from the brokers, am I sure that other consumer (with may be) a different selector (the C), continues to get its own messages ?
The broker sends a ping to the clients to see who's still alive. So worst case scenario, is that if the consumer that crashed has still messages reserved in its buffer (according to the flow controls) when the broker detects the crash, it will free the messages to be consumed by other consumers.
>should I ensure a low flow limit to be sure that no lock situation can occur or just endure for a short time ?
A flow limit that is too high would cause the messages to be consumer unevenly by the consumers, not lock the messages.
Just a small detail here....
The selector on a connection is set at the connection initialisation time. The selector's value is then transferred to the broker. The broker can then use the selectors to send messages to the consumers, according to their selectors that they have set. So in the flow limit "batch" a consumer will never have a message that he can't process because of its selector. So, if a flow limit is too high, the message processing will simply be slower, but making full usage of all the consumers connected to the brokers to load balance the message processing.
HTH
TE
