The ups and downs of MQ Reconnect – the classic MQ scenarios

This is one topic in a series of blog posts.

• The ups and downs of MQ Reconnect – the basics
• The ups and downs of MQ Reconnect – what do I need to do to get it to work?
• The ups and downs of MQ Reconnect – the classic MQ scenarios
• The ups and downs of MQ Reconnect – how can I tell if automatic reconnect has happened?
• The ups and downs of MQ Reconnect – little problems
• The ups and downs of MQ Reconnect – frustrating problems.

Scenario 1 server application with non persistent messages

Consider a server application using a client connection using non persistent messages. It does

• MQGET out of syncpoint
• MQPUT out of syncpoint.

If the queue manager is shut down and the application can transparently connect to an available queue manager. The worst situation is that you get from QMA, and put from QMC.

This is not a problem.

Scenario 2 server application with persistent messages

The application does

• MQGET in syncpoint
• MQPUT in syncpoint
• MQCOMMIT

When the queue manager was ended, the application did

• MQGET in syncpoint
  • endmqm -r QMA, and the application connects to QMC
• MQPUT in syncpoint
• MQCOMMIT
  • gave MQRC_BACKED_OUT, and the original message is still available on QMA.

Going round the loop again. This time all of the requests are on QMC.

This is OK.

Scenario 3 – Client application with non persistent messages

The application does

• MQPUT to server queue with non persistent, out of syncpoint
• MQGET with wait, out of syncpoint.

If we had

• MQPUT to server non persistent, out of syncpoint
  • endmqm -r QMA. This switches to QMC
• MQGET With wait, out of syncpoint.

This is done from queue manager QMC. As the reply-to-queue was REPLY at QMA, then the get will time out.

This is OK.

1. It is non persistent, so you are expecting that it may be lost
2. You have set expiry so it will expiry after a short period
3. Your default behaviour may be to reissue the request, or just to tell the end user “sorry… “

Scenario 4 – Client application with persistent messages

This scenario is similar to the previous scenario – but this time you do not want to lose the message.

• The application does
• MQPUT of persistent message, within syncpoint specifying the reply to queue
• MQCOMMIT
• MQGET with wait.
• If message is retrieved
  • MQCOMMIT

This single business transaction has two units of work (MQPUT, COMMIT) and (MQGET, COMMIT).

If we had

• MQPUT of persistent message, within syncpoint specifying the reply to queue
• MQCOMMIT
• MQGET with wait.
  • endmqm -r QMA. This switches to QMC
• MQGET returns with 2033. No message found.

This is similar to the existing situation when the back end server was slow, and you did not get your reply in time. You should already have a process for when the reply arrives after your application has gone away. Typically you have a process which processes these orphaned messages (eg over 10 minutes old) and you have some logic to fix the problem – such as update a database indicating “special case”.

Tell your end users “possible problem – please check”, or retry the original request and hope it works. The back end application needs to be prepared to handle possible duplicate requests.

In this case you do want the message (because it was persistent).

You have a couple of ways of handling this.

1. Report this as an exception, use your internal processes cleans up the orphaned messages. Tell the end users “sorry..”
2. Do not use automatic reconnect – but reconnect to the original queue manager, and wait for a period for the reply. If you cannot connect within x second – pick another queue manager to connect to. Use your existing orphaned message process for clean up. Reconnecting to the original queue manager, may take a few seconds longer, but may reduce the number of orphaned messages to process.

This scenario requires more planning and additional code to implement.