Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hi Haytham,

You don't say what programming language/API you are using for your applications.

Suggest you use the connection option MQCNO_CD_FOR_OUTPUT_ONLY on the first connection, and then MQCNO_USE_CD_SELECTION on the second connection.

This has the effect of selecting from the CCDT on the first connection, and then using whatever was chosen on the second connection.

You'll also have to think carefully about what to do when you are told to reconnect, as I would imagine only the first connection would be told to reconnect. You can code an EventListener that will be notified when your connection reconnects, and use that to manually break and reconnect the second connection. The MQSTAT verb with type MQSTAT_TYPE_RECONNECTION will tell you which queue manager you are reconnecting to. See sample amqsghac.c for an example.

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Mon September 29, 2025 03:26 AM
From: Haytham Ellamey
Subject: MQ Uniform cluster affenity and correlation

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

------------------------------
Haytham Ellamey
Integration Architect , Alinma Bank , Riyadh,KSA
------------------------------

Hello Moragan , 

Thank you for your support , We are using Java spring boot applications to connect to uniform cluster , The problem is that response could come to another queue manager in cluster , so if i got notified how can i know which Queue manager has the message ?  

Hi Haytham,

You don't say what programming language/API you are using for your applications.

Suggest you use the connection option MQCNO_CD_FOR_OUTPUT_ONLY on the first connection, and then MQCNO_USE_CD_SELECTION on the second connection.

This has the effect of selecting from the CCDT on the first connection, and then using whatever was chosen on the second connection.

You'll also have to think carefully about what to do when you are told to reconnect, as I would imagine only the first connection would be told to reconnect. You can code an EventListener that will be notified when your connection reconnects, and use that to manually break and reconnect the second connection. The MQSTAT verb with type MQSTAT_TYPE_RECONNECTION will tell you which queue manager you are reconnecting to. See sample amqsghac.c for an example.

Cheers,
Morag

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hi Haytham,

I do apologise for misunderstanding your question. I thought you were asking "how do I make both my application connections go to the same queue manager" and that is what my answer covered.

I see that you are actually asking how to discover which queue manager has the response message.

In normal request/response models, the putting application - the one that sends the request message - fills in the ReplyToQ field in the message before sending it, and usually leaves the ReplyToQMgr field blank to mean "send it back to the queue manager I am connected to". The queue manager fills in a blank ReplyToQMgr field with its own name.

So, whatever queue manager the putting application was connected to, that is your first connection, will be the queue manager that the response will be sent to.

If your second connection is connected elsewhere and has opened the ModelQ to create a temporary queue on another queue manager, then it is that queue manager name that should be filled into the ReplyToQMgr name by the putter of the request so that the response message goes to the queue on the queue manager where the getting connection is connected.

This all assumes that the responding application, that is the application which consumes the request message and creates the response message, uses the ReplyToQ and ReplyToQMgr fields from the MQMD and does not simply send the reply to some other well know queue name. Perhaps you can confirm that your responding application does use the ReplyTo fields?

Also, was there a reason why having both connections going to the same queue manager was not a useful solution to your problem?

Cheers,
Morag

Hello Moragan , 

Thank you for your support , We are using Java spring boot applications to connect to uniform cluster , The problem is that response could come to another queue manager in cluster , so if i got notified how can i know which Queue manager has the message ?  

Hi Haytham,

You don't say what programming language/API you are using for your applications.

Suggest you use the connection option MQCNO_CD_FOR_OUTPUT_ONLY on the first connection, and then MQCNO_USE_CD_SELECTION on the second connection.

This has the effect of selecting from the CCDT on the first connection, and then using whatever was chosen on the second connection.

You'll also have to think carefully about what to do when you are told to reconnect, as I would imagine only the first connection would be told to reconnect. You can code an EventListener that will be notified when your connection reconnects, and use that to manually break and reconnect the second connection. The MQSTAT verb with type MQSTAT_TYPE_RECONNECTION will tell you which queue manager you are reconnecting to. See sample amqsghac.c for an example.

Cheers,
Morag

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hello Morgan , 

Thank you very much for your support and kind interest , i got your point but regarding to "having both connections going to the same queue manager" i can't map the connection types value in our java code , we can't find any sample doing that using java . our code  here to make reconnection  : 

Hi Haytham,

I do apologise for misunderstanding your question. I thought you were asking "how do I make both my application connections go to the same queue manager" and that is what my answer covered.

I see that you are actually asking how to discover which queue manager has the response message.

In normal request/response models, the putting application - the one that sends the request message - fills in the ReplyToQ field in the message before sending it, and usually leaves the ReplyToQMgr field blank to mean "send it back to the queue manager I am connected to". The queue manager fills in a blank ReplyToQMgr field with its own name.

So, whatever queue manager the putting application was connected to, that is your first connection, will be the queue manager that the response will be sent to.

If your second connection is connected elsewhere and has opened the ModelQ to create a temporary queue on another queue manager, then it is that queue manager name that should be filled into the ReplyToQMgr name by the putter of the request so that the response message goes to the queue on the queue manager where the getting connection is connected.

This all assumes that the responding application, that is the application which consumes the request message and creates the response message, uses the ReplyToQ and ReplyToQMgr fields from the MQMD and does not simply send the reply to some other well know queue name. Perhaps you can confirm that your responding application does use the ReplyTo fields?

Also, was there a reason why having both connections going to the same queue manager was not a useful solution to your problem?

Cheers,
Morag

Hello Moragan , 

Thank you for your support , We are using Java spring boot applications to connect to uniform cluster , The problem is that response could come to another queue manager in cluster , so if i got notified how can i know which Queue manager has the message ?  

Hi Haytham,

You don't say what programming language/API you are using for your applications.

Suggest you use the connection option MQCNO_CD_FOR_OUTPUT_ONLY on the first connection, and then MQCNO_USE_CD_SELECTION on the second connection.

This has the effect of selecting from the CCDT on the first connection, and then using whatever was chosen on the second connection.

You'll also have to think carefully about what to do when you are told to reconnect, as I would imagine only the first connection would be told to reconnect. You can code an EventListener that will be notified when your connection reconnects, and use that to manually break and reconnect the second connection. The MQSTAT verb with type MQSTAT_TYPE_RECONNECTION will tell you which queue manager you are reconnecting to. See sample amqsghac.c for an example.

Cheers,
Morag

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hi Haytham,

Thinking further about your "get both connections to go to the same queue manager" it occurs to me that there is a simpler way. You are using a Uniform Cluster, so your CCDT contains a group record, and exactly one queue manager named record for each queue manager in the group. So if you simply inquire the name of the queue manager that the first connection was made to and make the second connection to that name specifically instead of to the group name, won't that ensure they are both connected to the same one. No need to use the MQCNO options because you don't have multiple choices for each queue manager.

Still have to solve the reconnect problem. Again perhaps the simplistic view is suitable - just have an event listener and when it gets called, remember that you have been reconnected and then just inquire the name of the queue manager, and disconnect and reconnect the second connection to match it again. No need to call MQSTAT which probably isn't available in the stabilized Java classes.

Cheers,
Morag

Hello Morgan , 

Thank you very much for your support and kind interest , i got your point but regarding to "having both connections going to the same queue manager" i can't map the connection types value in our java code , we can't find any sample doing that using java . our code  here to make reconnection  : 

Hi Haytham,

I do apologise for misunderstanding your question. I thought you were asking "how do I make both my application connections go to the same queue manager" and that is what my answer covered.

I see that you are actually asking how to discover which queue manager has the response message.

In normal request/response models, the putting application - the one that sends the request message - fills in the ReplyToQ field in the message before sending it, and usually leaves the ReplyToQMgr field blank to mean "send it back to the queue manager I am connected to". The queue manager fills in a blank ReplyToQMgr field with its own name.

So, whatever queue manager the putting application was connected to, that is your first connection, will be the queue manager that the response will be sent to.

If your second connection is connected elsewhere and has opened the ModelQ to create a temporary queue on another queue manager, then it is that queue manager name that should be filled into the ReplyToQMgr name by the putter of the request so that the response message goes to the queue on the queue manager where the getting connection is connected.

This all assumes that the responding application, that is the application which consumes the request message and creates the response message, uses the ReplyToQ and ReplyToQMgr fields from the MQMD and does not simply send the reply to some other well know queue name. Perhaps you can confirm that your responding application does use the ReplyTo fields?

Also, was there a reason why having both connections going to the same queue manager was not a useful solution to your problem?

Cheers,
Morag

Hello Moragan , 

Thank you for your support , We are using Java spring boot applications to connect to uniform cluster , The problem is that response could come to another queue manager in cluster , so if i got notified how can i know which Queue manager has the message ?  

Hi Haytham,

You don't say what programming language/API you are using for your applications.

Suggest you use the connection option MQCNO_CD_FOR_OUTPUT_ONLY on the first connection, and then MQCNO_USE_CD_SELECTION on the second connection.

This has the effect of selecting from the CCDT on the first connection, and then using whatever was chosen on the second connection.

You'll also have to think carefully about what to do when you are told to reconnect, as I would imagine only the first connection would be told to reconnect. You can code an EventListener that will be notified when your connection reconnects, and use that to manually break and reconnect the second connection. The MQSTAT verb with type MQSTAT_TYPE_RECONNECTION will tell you which queue manager you are reconnecting to. See sample amqsghac.c for an example.

Cheers,
Morag

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hy Haytham,

In JMS you need to create your consumer off the same session  /  JMSContext you created your producer from. This would ensure that you are using the same connection. And make sure that your server application uses the JMSReplyto message destination to send your reply to. (usually you also check if the correlid is blank (or low value (hex 00(24)) and if it is set the messageid to the correlid. It it is not the field is a pass through.

As a work around you can use the current set up, if you consider the reply to be an event and treat it as such. Example: just write the (reply) event to a DB with the relevant information to be able to correlate it to the request. Then have the requester look at the DB for the reply. You can then consume the reply from any queue manager as you just write it to the db.

Hope this helps

Hi Haytham,

Thinking further about your "get both connections to go to the same queue manager" it occurs to me that there is a simpler way. You are using a Uniform Cluster, so your CCDT contains a group record, and exactly one queue manager named record for each queue manager in the group. So if you simply inquire the name of the queue manager that the first connection was made to and make the second connection to that name specifically instead of to the group name, won't that ensure they are both connected to the same one. No need to use the MQCNO options because you don't have multiple choices for each queue manager.

Still have to solve the reconnect problem. Again perhaps the simplistic view is suitable - just have an event listener and when it gets called, remember that you have been reconnected and then just inquire the name of the queue manager, and disconnect and reconnect the second connection to match it again. No need to call MQSTAT which probably isn't available in the stabilized Java classes.

Cheers,
Morag

Hello Morgan , 

Thank you very much for your support and kind interest , i got your point but regarding to "having both connections going to the same queue manager" i can't map the connection types value in our java code , we can't find any sample doing that using java . our code  here to make reconnection  : 

Hi Haytham,

I do apologise for misunderstanding your question. I thought you were asking "how do I make both my application connections go to the same queue manager" and that is what my answer covered.

I see that you are actually asking how to discover which queue manager has the response message.

In normal request/response models, the putting application - the one that sends the request message - fills in the ReplyToQ field in the message before sending it, and usually leaves the ReplyToQMgr field blank to mean "send it back to the queue manager I am connected to". The queue manager fills in a blank ReplyToQMgr field with its own name.

So, whatever queue manager the putting application was connected to, that is your first connection, will be the queue manager that the response will be sent to.

If your second connection is connected elsewhere and has opened the ModelQ to create a temporary queue on another queue manager, then it is that queue manager name that should be filled into the ReplyToQMgr name by the putter of the request so that the response message goes to the queue on the queue manager where the getting connection is connected.

This all assumes that the responding application, that is the application which consumes the request message and creates the response message, uses the ReplyToQ and ReplyToQMgr fields from the MQMD and does not simply send the reply to some other well know queue name. Perhaps you can confirm that your responding application does use the ReplyTo fields?

Also, was there a reason why having both connections going to the same queue manager was not a useful solution to your problem?

Cheers,
Morag

Hello Moragan , 

Thank you for your support , We are using Java spring boot applications to connect to uniform cluster , The problem is that response could come to another queue manager in cluster , so if i got notified how can i know which Queue manager has the message ?  

Hi Haytham,

You don't say what programming language/API you are using for your applications.

Suggest you use the connection option MQCNO_CD_FOR_OUTPUT_ONLY on the first connection, and then MQCNO_USE_CD_SELECTION on the second connection.

This has the effect of selecting from the CCDT on the first connection, and then using whatever was chosen on the second connection.

You'll also have to think carefully about what to do when you are told to reconnect, as I would imagine only the first connection would be told to reconnect. You can code an EventListener that will be notified when your connection reconnects, and use that to manually break and reconnect the second connection. The MQSTAT verb with type MQSTAT_TYPE_RECONNECTION will tell you which queue manager you are reconnecting to. See sample amqsghac.c for an example.

Cheers,
Morag

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hi Haytham

If I understand your situation correctly I think you've run up against quite a common issue - because Spring (deliberately) abstracts away the MQ/JMS concepts to such an extent, it can be very difficult to properly configure applications to take advantage of more advanced features like Uniform Clusters.

As Francois already mentioned, MQ reconnect/balancing will ensure that all 'connections' (with a small c) made under the same JMSConnection object, are always routed to the same queue manager. Uniform Clusters also provides the ability to wait for a reply message before rebalancing an application instance.  Unfortunately, when a piece of application code is being invoked by the Spring runtime, you don't always have fine grained control over which connection it is using (I believe this is actually possible, but I'm not a Spring Boot expert and I think it would be 'atypical' and involve writing more complex code which goes in at a lower level managing the ConnectionFactory objects etc. than most Spring apps would choose to).

One possible approach - which was actually added to the product precisely to assist other customers running up against this problem - is to enable 'JVM Mode' balancing.  In this mode, all connections coming from the same JVM are always bound to the same queue manager, but are still free to move (as a unit) to another queue manager.  If there are sufficient unique JVMs running to spread your application workload, this allows you to take advantage of Uniform Cluster client balancing without having to worry about which particular connection within a JVM your application is running on.  All the same usual rules apply in terms of when an application will be rebalanced (so you can for example still take advantage of the request/reply toleration features).

I think (assuming working within the SpringBoot Framework is a given) the only alternatives are to
a) disable balancing for this application,
b) tune/configure Spring Boot such that all work happens under a single connection or
c) investigate getting further into the 'internals' to tweak connection factory behaviour etc. in Spring and execute application code on the required connection

Hope this helps,
Anthony

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.

Hi Haytham,

Explain your "have to" create 2 connections... Usually this work is done under one and the same session / JMSContext (although under 2 different transactions if transacted). This should give you the same queue manager.

Can you please tell us how you are creating / defining the JMSReplyTo Destination? Is that destination clustered?

Apart from that you'll have to follow either the event pattern or the JVM load balancing as described by Anthony.

Hope it helps

Hi Haytham

If I understand your situation correctly I think you've run up against quite a common issue - because Spring (deliberately) abstracts away the MQ/JMS concepts to such an extent, it can be very difficult to properly configure applications to take advantage of more advanced features like Uniform Clusters.

As Francois already mentioned, MQ reconnect/balancing will ensure that all 'connections' (with a small c) made under the same JMSConnection object, are always routed to the same queue manager. Uniform Clusters also provides the ability to wait for a reply message before rebalancing an application instance.  Unfortunately, when a piece of application code is being invoked by the Spring runtime, you don't always have fine grained control over which connection it is using (I believe this is actually possible, but I'm not a Spring Boot expert and I think it would be 'atypical' and involve writing more complex code which goes in at a lower level managing the ConnectionFactory objects etc. than most Spring apps would choose to).

One possible approach - which was actually added to the product precisely to assist other customers running up against this problem - is to enable 'JVM Mode' balancing.  In this mode, all connections coming from the same JVM are always bound to the same queue manager, but are still free to move (as a unit) to another queue manager.  If there are sufficient unique JVMs running to spread your application workload, this allows you to take advantage of Uniform Cluster client balancing without having to worry about which particular connection within a JVM your application is running on.  All the same usual rules apply in terms of when an application will be rebalanced (so you can for example still take advantage of the request/reply toleration features).

I think (assuming working within the SpringBoot Framework is a given) the only alternatives are to
a) disable balancing for this application,
b) tune/configure Spring Boot such that all work happens under a single connection or
c) investigate getting further into the 'internals' to tweak connection factory behaviour etc. in Spring and execute application code on the required connection

Hope this helps,
Anthony

Hello everyone,

We are facing a client connection routing challenge with our IBM MQ uniform cluster and are looking for advice on the best practice for handling this.

Our Environment:

• IBM MQ Uniform Cluster (multiple queue managers).

• Clients are applications running as pods on OpenShift.

• Communication is asynchronous request/reply. A client sends a request to a specific queue and then listens for the response on a separate, dedicated reply queue.

The Problem:
Because our clients need to make two separate connections (one to send, one to receive), we are hitting a routing issue within the uniform cluster.

1. On the first connection to send the request, the client pod might be directed to Queue Manager 1 (QM1).

2. On the second connection to listen for the response, the client pod might be directed to Queue Manager 2 (QM2).

Since the response message is on the reply queue that is local to QM1, the client connected to QM2 will never receive it.

What We've Tried:
We have experimented with the MQ client channel's AFFINITY setting:

• AFFINITY(NONE): This leads to the problem described above. Connections are load-balanced across the cluster, breaking the session.

• AFFINITY(PREFERRED): This solves the message locality issue, but it effectively disables load balancing. All client pods seem to stick to a single queue manager, creating a hot spot and defeating the purpose of our cluster for client connections.

Our Question:
Is there a recommended way to handle this pattern in a uniform cluster?

We need a solution where a client's logical session (the request and its corresponding response) is tied to a single queue manager, without forcing all clients to connect to the same one. We want to maintain the scalability and high availability of the cluster.

We are considering if a different queue design or a specific client configuration could resolve this. Any insights or shared experiences would be greatly appreciated.

Thank you.