Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hello Morag,

Client 1 is in aws -  MQ client deployed in kuberneties, that connects to queue manager using serverconn channel1.(upstream JMS MQ client1 sends message and JMS MQ client 2 receives it)

Client 2 is in on prem - JMS MQ client, that connects to MQ queue manager using serverconn channel2.

Client2 host was down this is when MQ Client 1 was seeing an error JMSCMQ0001: IBM MQ Call Failed with compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

Queue manager V9.4 is in a separate Virtual Machine, RHEL OS. All three components are independent on network.

Both MQ clients connects using server conn channel(two different channel)

Same port number.

Thanks

KP

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

When Client 1 experienced the error: compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

what was the status of the queue manager?, or the network between client 1 and the queue manager?

Is it just a coincidence that restarting the machine that client 2 was running on had any impact on the connectivity for Client 1 to the queue manager? What is the relationship there?

Cheers,
Morag

Hello Morag,

Client 1 is in aws -  MQ client deployed in kuberneties, that connects to queue manager using serverconn channel1.(upstream JMS MQ client1 sends message and JMS MQ client 2 receives it)

Client 2 is in on prem - JMS MQ client, that connects to MQ queue manager using serverconn channel2.

Client2 host was down this is when MQ Client 1 was seeing an error JMSCMQ0001: IBM MQ Call Failed with compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

Queue manager V9.4 is in a separate Virtual Machine, RHEL OS. All three components are independent on network.

Both MQ clients connects using server conn channel(two different channel)

Same port number.

Thanks

KP

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Queue manager was running fine at the time.

Network between client1 and queue manager was good.

the message that will be sent by client 1 will be read by client 2..

I am thinking to decouple the connectivity keeping a queue manager at source end?

which means on aws having a queue manager puts the message to their own queue.

please suggest.

thanks 
KP

When Client 1 experienced the error: compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

what was the status of the queue manager?, or the network between client 1 and the queue manager?

Is it just a coincidence that restarting the machine that client 2 was running on had any impact on the connectivity for Client 1 to the queue manager? What is the relationship there?

Cheers,
Morag

Hello Morag,

Client 1 is in aws -  MQ client deployed in kuberneties, that connects to queue manager using serverconn channel1.(upstream JMS MQ client1 sends message and JMS MQ client 2 receives it)

Client 2 is in on prem - JMS MQ client, that connects to MQ queue manager using serverconn channel2.

Client2 host was down this is when MQ Client 1 was seeing an error JMSCMQ0001: IBM MQ Call Failed with compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

Queue manager V9.4 is in a separate Virtual Machine, RHEL OS. All three components are independent on network.

Both MQ clients connects using server conn channel(two different channel)

Same port number.

Thanks

KP

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Client1 and Client2 are already decoupled. There is a queue manager in between. If you think there is some coupling between Client1 and Client2 then that knowledge would be useful in diagnosing your issue. I can see nothing from what you have described that would result in one application not being able to connect to the queue manager because the other application wasn't running.

I fear that adding another queue manager won't change the issue you are suffering.

I suspect at this point you should be raising a case with IBM to have this diagnosed further. If there was nothing wrong with the network connectivity and the queue manager was running, then I see no reason for client 1 to even be disconnected, and thus why would it be reconnecting and why would it fail to reconnect. Perhaps there is an error in the JMS layer that reports MQRC_RECONNECT_TIMED_OUT when it meant to report that waiting for the message has timed out. That would be an error in IBM code though and you would have to talk to IBM for that or indeed any other internal problem. I think perhaps it is time to do that.

Cheers,
Morag

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

Original Message:
Sent: Fri May 30, 2025 06:26 AM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Queue manager was running fine at the time.

Network between client1 and queue manager was good.

the message that will be sent by client 1 will be read by client 2..

I am thinking to decouple the connectivity keeping a queue manager at source end?

which means on aws having a queue manager puts the message to their own queue.

please suggest.

thanks 
KP

------------------------------
K Priyanka

Original Message:
Sent: Fri May 30, 2025 01:53 AM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

When Client 1 experienced the error: compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

what was the status of the queue manager?, or the network between client 1 and the queue manager?

Is it just a coincidence that restarting the machine that client 2 was running on had any impact on the connectivity for Client 1 to the queue manager? What is the relationship there?

Cheers,
Morag

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

Original Message:
Sent: Thu May 29, 2025 10:19 PM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

Client 1 is in aws -  MQ client deployed in kuberneties, that connects to queue manager using serverconn channel1.(upstream JMS MQ client1 sends message and JMS MQ client 2 receives it)

Client 2 is in on prem - JMS MQ client, that connects to MQ queue manager using serverconn channel2.

Client2 host was down this is when MQ Client 1 was seeing an error JMSCMQ0001: IBM MQ Call Failed with compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

Queue manager V9.4 is in a separate Virtual Machine, RHEL OS. All three components are independent on network.

Both MQ clients connects using server conn channel(two different channel)

Same port number.

Thanks

KP

------------------------------
K Priyanka

Original Message:
Sent: Thu May 29, 2025 06:14 PM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

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

Original Message:
Sent: Thu May 29, 2025 01:28 PM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

------------------------------
K Priyanka

Original Message:
Sent: Thu May 29, 2025 07:49 AM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

------------------------------
K Priyanka

Original Message:
Sent: Thu May 29, 2025 07:18 AM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

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

Original Message:
Sent: Thu May 29, 2025 06:43 AM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

------------------------------
K Priyanka

Original Message:
Sent: Wed May 28, 2025 11:15 PM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

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

Original Message:
Sent: Wed May 28, 2025 11:10 PM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

------------------------------
K Priyanka
------------------------------

Queue manager was running fine at the time.

Network between client1 and queue manager was good.

the message that will be sent by client 1 will be read by client 2..

I am thinking to decouple the connectivity keeping a queue manager at source end?

which means on aws having a queue manager puts the message to their own queue.

please suggest.

thanks 
KP

When Client 1 experienced the error: compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

what was the status of the queue manager?, or the network between client 1 and the queue manager?

Is it just a coincidence that restarting the machine that client 2 was running on had any impact on the connectivity for Client 1 to the queue manager? What is the relationship there?

Cheers,
Morag

Hello Morag,

Client 1 is in aws -  MQ client deployed in kuberneties, that connects to queue manager using serverconn channel1.(upstream JMS MQ client1 sends message and JMS MQ client 2 receives it)

Client 2 is in on prem - JMS MQ client, that connects to MQ queue manager using serverconn channel2.

Client2 host was down this is when MQ Client 1 was seeing an error JMSCMQ0001: IBM MQ Call Failed with compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

Queue manager V9.4 is in a separate Virtual Machine, RHEL OS. All three components are independent on network.

Both MQ clients connects using server conn channel(two different channel)

Same port number.

Thanks

KP

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

Hi - when client one puts the message to the queue, does the message arrive in the queue? Can you open the message with the console, or is only the count on the queue depth going up? Also, does client 1 issue a "close" queue?

------------------------------
Francois van der Merwe
Hybrid Cloud / Integration Specialist Tech Sales
IBM
Johannesburg
+27825569467

Original Message:
Sent: Fri May 30, 2025 06:26 AM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Queue manager was running fine at the time.

Network between client1 and queue manager was good.

the message that will be sent by client 1 will be read by client 2..

I am thinking to decouple the connectivity keeping a queue manager at source end?

which means on aws having a queue manager puts the message to their own queue.

please suggest.

thanks 
KP

------------------------------
K Priyanka

Original Message:
Sent: Fri May 30, 2025 01:53 AM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

When Client 1 experienced the error: compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

what was the status of the queue manager?, or the network between client 1 and the queue manager?

Is it just a coincidence that restarting the machine that client 2 was running on had any impact on the connectivity for Client 1 to the queue manager? What is the relationship there?

Cheers,
Morag

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

Original Message:
Sent: Thu May 29, 2025 10:19 PM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

Client 1 is in aws -  MQ client deployed in kuberneties, that connects to queue manager using serverconn channel1.(upstream JMS MQ client1 sends message and JMS MQ client 2 receives it)

Client 2 is in on prem - JMS MQ client, that connects to MQ queue manager using serverconn channel2.

Client2 host was down this is when MQ Client 1 was seeing an error JMSCMQ0001: IBM MQ Call Failed with compcode '2'(MQCC_FAILED) reason '2556'('MQRC_RECONNECT_TIMED_OUT)

Queue manager V9.4 is in a separate Virtual Machine, RHEL OS. All three components are independent on network.

Both MQ clients connects using server conn channel(two different channel)

Same port number.

Thanks

KP

------------------------------
K Priyanka

Original Message:
Sent: Thu May 29, 2025 06:14 PM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

Hi KP,

You said, "restart of client2 and bringing up made the error go away". So what EXACTLY do you do to "restart client2". We need to figure out why that is resolving an inability to connect to the queue manager for client1.

Can you also say more about the queue manager. Where does it reside? You tell me that they both connect using a SVRCONN channel. Do both use the same connection name? Same port number? Same channel name?

Cheers,
Morag 

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

Original Message:
Sent: Thu May 29, 2025 01:28 PM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

Client 2 is in aws deployed in Kubernetes they dont include any queue manager.  they connect to queue manager using servconn channel.

Thanks

KP

------------------------------
K Priyanka

Original Message:
Sent: Thu May 29, 2025 07:49 AM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

The message that is sent by Client1 is read by Client2.

At first that was the requirement application team gave me(message send from one client that need to be received by another client).

In Single Queue Manager, I created a common queue to which application sends message and another application that need to read that message.(Client1 is hosted in cloud AWS and Client2 is on-prem)

I can come back to with more information on the nature of application(client1 and client2).

Thank you so much for you help.

KP

------------------------------
K Priyanka

Original Message:
Sent: Thu May 29, 2025 07:18 AM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

Hi KP,

I cannot think of any reason why having one application running would have any impact on the ability of another application to connect to the queue manager.

This suggests to me that I am not understanding exactly what YOU mean when you say "client1" and "client2".

When you restart client2, how exactly do you restart it. What EXACTLY is client2? Is there any possibility that client2 is a container that also includes the queue manager say?

Don't be distracted by the second scenario for now. Without understanding what your problem is, there is no way I could answer whether that would be better or not.

Cheers,
Morag

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

Original Message:
Sent: Thu May 29, 2025 06:43 AM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello Morag,

Thank you,

I have single queue manager that is used by both the client1 and client2, here the problem is when client 2 was not running for some reason, I was seeing a error returned to client 1

MQ_Service_Error Reason JMSCMQ0001:IBM MQ failed with compcode 2(MQCC_FAILED) reason '2556'(MQRC_RECONNECT_TIMED_OUT)

restart of client2 and bringing up made the error go away.

How to overcome this? As you suggested the second scenario better to go with two queue manager?

With Regards

KPriyanka

------------------------------
K Priyanka

Original Message:
Sent: Wed May 28, 2025 11:15 PM
From: Morag Hughson
Subject: A client put message to a queue and another client reads the same from same queue.

Having one application put a message to a queue and another application get the message from the queue is a perfectly suitable way of using MQ.

This might be with a single queue manager that both applications connect to, as I think you are suggesting.

This might also be used with two queue managers, at which point you would have a flow something like this:-

client application 1 -> put to queue -> message resolves to XmitQ -> Sender channel picks up message and moves to QMgr2 -> Receiver channel on QMgr2 receives message and puts to target queue -> client application 2 gets message

One of the lovely things about MQ is that the applications don't need to change when the first scenario turns into the second scenario. The changes can be made just with configuration updates.

Cheers,
Morag

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

Original Message:
Sent: Wed May 28, 2025 11:10 PM
From: K Priyanka
Subject: A client put message to a queue and another client reads the same from same queue.

Hello All,

Is it a good design if a queue is common among two clients, one client puts the message and another client gets it.

queue manager and queue is common among two queue manager.

client1->put to queue and get from queue -> client2

Thanks

KPriyank

------------------------------
K Priyanka
------------------------------