We are new to MQ persistence & assurance of delivery
(we've been using MQ, but assurance of delivery wasn't an issue before).
Now, we need persistence, assurance of delivery, and transactions - starting from the client machine.
I.e: when the client invokes 'MQ PUT', and there's a temporary network failure, we'd like the message to be:
1) Stored on the client machine's hard-drive
2) And retransmitted when the network recovers.
3) If possible, we'd also like to view pending messages (waiting to be retransmitted)
Our question: is this supported by MQ client installation ?
Or does it require us to install an MQ Queue manager on the client machine?
Pinned topic MQ: persistence on the client side?
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2009-07-20T03:50:29Z at 2009-07-20T03:50:29Z by SystemAdmin
Re: MQ: persistence on the client side?2009-07-08T22:15:00ZThis is the accepted answer. This is the accepted answer.MQ Client does not support local storage or retry / retransmission of messages, so you'll need to go for MQ Server to get that capability.
Re: MQ: persistence on the client side?2009-07-17T18:20:53ZThis is the accepted answer. This is the accepted answer.This is a loaded question, since you raise the topics (1) persistence, (2) transactions, and (3) delivery assurance all in 1 breath.
Of course, persistence and transaction processing (Units of Work (UOW)) are methods to accomplishing assured delivery.
The previous poster is correct, you will probably have great difficuly accomplishing all of your goals as a simple client.
You can install Extendeded Transactional Client support - please see
http://www-01.ibm.com/software/integration/wmq/transclient.html for complete details. Since the license charges are the same as for a qmgr, some installation opt to install the server instead and get all the benefits of a full-scale server - as well as the headahces, such as maintaining the server, the rolling transaction log files, etc.
Assurance of delivery is what WMQ is all about, but there things you can do to help it do its job better. Look at delivery-notification, as an example of something you can build into your application; don't forget positive AND negative reports; you want to know about the message's final disposition, no questions asked!
Good luck, let us know what you decide.
Re: MQ: persistence on the client side?2009-07-20T03:50:29ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
True, and you need to have trust in this. MQ does not lose messages!
>but there things you can do to help it do its job better. Look at
>delivery-notification, as an example of something you can build into your
>application; don't forget positive AND negative reports; you want to
>know about the message's final disposition, no questions asked!
I beg to disagree. Notification (aka MQ Reports) does not help MQ to deliver
messages. It does not change quality of service. If anything, it hinders MQ
by creating a larger volume of messages that it has to process.
MQ Report messages (confirmation of delivery, confirmation of arrival, expiration, negative acknowledgement, positive acknowledgement) travel the same paths as your application messages and so can only be as reliable as the original message. MQ Report messages may give a sending application a warm and fuzzy feeling that MQ has done something, but they should not be relied upon, and they go against the paradigm of asynchronous message programming.
Feel free to discuss further. Glenn.