I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

yes, set a load balancer on the MQ Listener port, so the REST service calls the correct queue manager.

Also the new change in 9.3; you do nto have to setup SDR/RCVR channels any more It will work over CCDT.

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Hi Neil,

Thanks for your response:

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance

for the above to work in AWS environment, would have to be an ALB(Application Load Balancer) or NLB (Network Load Balancer)?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

This new feature for MQ REST API is available in version 9.3.3, I assume it is MQ CD.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Any idea when it will be available in MQ LTS?

I see the latest version for LTS in 9.3.0.6.

Would the above feature be available in this version?

If not, when will 9.3.3 be available for LTS?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Neil,

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group

What did you mean with host group?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?

Host Group...

The name used in some LB implementations for the list of host/port combinations providing the service sitting behind the load balancer. For MIQM load balancing it would be the two hosts providing the MIQM cluster.

Regards

Neil,

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group

What did you mean with host group?

Hi Emile,

The MIQM is behaving the way it is expected to. Only the active instance can be used. MQ for client connections can handle this without a load balancer as the channel table or conname can contain a list of addresses which can host the active queue manager. The REST API service only connects to the local queue manager (although this may change in future) as it uses local bindings, not client bindins.

However, this is trickier with an HTTP service providing the REST API.

The simplest things to do in most cases is implement a load balancer in front of the MIQM cluster with the 2 hosts load balanced behind it in the host group. The health check for the HTTP can look for the MQ port to be open (instead of the HTTP port) so that it directs all traffic to the active instance.

If you don't have a commercial load balancer handy, you can implement something on linux using haproxy or anything with similar functionality for tcp sockets or http requests.

It looks like MQ 9.3 supports remote connections from the REST API, so it would just be a matter of setting it up correctly and you can take advantage of MQ client ability to find the active queue manager instance.

https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mura-setting-up-remote-queue-manager-use-messaging-rest-api

Regards,

I have a multi instance setup running on Linux.

I would to set up the MQ REST API to be able to do remote calls to the 2nd / Secondary QMGR.

I know you can set it up for Remote QMGRS, but there seems to be a problem with multi instance QMGRS.

here is the error: 

MQWB0004E: An internal error occurred while communicating with the queue manager. The root MQ reason code was 2543 : MQRC_STANDBY_Q_MGR.

Currently I am on 9.2.0.4, will upgrading to 9.3.3.0 or higher solve my problem?