CODEWITHSUNDEEP
ibm-mq
Arik Shaikevitz
Arik Shaikevitz

Reputation: 49

How to do an explicit ACK when receiving Websphere MQ messages?

I have an application listening to messages on an IBM Websphere MQ queue. Once a message is consumed, the application performs some processing logic. If the processing completed OK, I would like the application to acknowledge the message and have it removed from the queue. If an error occurred while processing, I would like the message to remain in the queue. How is this implemented? (I'm using the .NET API) Thanks.

Upvotes: 2

Views: 5080

Answers (3)

Pingpong
Pingpong

Reputation: 8009

1 Read the message using MQC.MQGMO_SYNCPOINT,

2 process it

3 call MQQueueManager.Commit()

If Commit() is not called explicitly, or implicitly (eg exception is thrown), all messages that have been de-queued will be re-enqueued.

Upvotes: -1

Stavr00
Stavr00

Reputation: 3314

You may want to look at the MQ Reporting Options.

Expiry, Confirmation of Arrival and Confirmation of Delivery can be requested and sent via a response queue back to the sending application by the receiving Queue Manager.

Positive and Negative Acknowledgements can also be generated by the receiving application provided they use the related reporting attributes found in the Message Descriptor.

Exception can be requested and sent via a response queue back to the sending application by any Queue Manager in the transmission chain or generated by the receiving application.

Upvotes: -1

T.Rob
T.Rob

Reputation: 31832

MQ supports a single-phase commit protocol. You specify syncpoint when you get the message, then issue COMMIT or ROLLBACK as required. The default action if the connection is lost is ROLLBACK and if the program deliberately ends without resolving the transaction a COMMIT is assumed. (This is platform dependent so the customary advice is to explicitly call COMMIT and not rely on the class destructors to do it for you.)

This works whether the message is persistent or not. However if the message has an expiry specified and expires after being rolled back there's a chance it won't be seen again.

Of course, if the program issues a ROLLBACK the message will normally be seen again since it goes back to the same spot int he queue and for a FIFO queue that's the top. If the problem with the message is not transient then this causes a poison message loop of read/rollback/repeat. To avoid that the app can check the backout count and if it exceeds some threshold requeue the message to an exception queue.

When using JMS or XMS this is done for you by the class libraries. If the input queue's BOQNAME and BOQTHRESH attributes are set the requeue is to the queue names in BOQNAME. Otherwise a requeue to the Dead Queue is attempted. IF that fails (as it should if the system is properly secured) the listener will stop receiving messages.

The usual advice is to always specify a backout queue and either let the classes use it or code the app to use it.

Please see Usage Notes for MQGET in the MQAPI Reference and the MQGetMessageOptions.NET page in the .Net class reference.

Upvotes: 3

Related Questions