Topic
  • 3 replies
  • Latest Post - ‏2009-07-20T03:50:29Z by SystemAdmin
SystemAdmin
SystemAdmin
8523 Posts

Pinned topic MQ: persistence on the client side?

‏2009-07-08T07:17:01Z |
Hi,

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?

Thanks.
Updated on 2009-07-20T03:50:29Z at 2009-07-20T03:50:29Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    8523 Posts

    Re: MQ: persistence on the client side?

    ‏2009-07-08T22:15:00Z  
    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.
  • SystemAdmin
    SystemAdmin
    8523 Posts

    Re: MQ: persistence on the client side?

    ‏2009-07-17T18:20:53Z  
    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.
    Dave
  • SystemAdmin
    SystemAdmin
    8523 Posts

    Re: MQ: persistence on the client side?

    ‏2009-07-20T03:50:29Z  
    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.
    Dave
    >Assurance of delivery is what WMQ is all about

    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.