Ensuring that messages are not lost

Messages that flow through your broker domain represent business data that you want to safeguard. Configure the messages, your environment, or both, to ensure that you do not lose messages.

Messages that are generated both by your applications and by runtime components for inter-component communication are important to the operation of your brokers. Messages used internally between components always use the WebSphere® MQ protocol. Application messages can use all supported transport protocols.

For application and internal messages traveling across WebSphere MQ, two techniques protect against message loss:

For more information about how to use these options, refer to the System Administration Guide section of the WebSphere MQ Version 6 information center online, or the Version 5.3 book on the WebSphere MQ library Web page.

Internal messages

WebSphere Event Broker components use WebSphere MQ messages to communicate events and data between broker processes and subsystems, and the Configuration Manager and User Name Server. The components ensure that the WebSphere MQ features are exploited to protect against message loss. You do not need to take any additional steps to configure WebSphere MQ or WebSphere Event Broker to protect against loss of internal messages.

Application messages

If delivery of application messages is critical, you must design application programs and the message flows that they use to ensure that messages are not lost. The techniques used depend on the protocol used by the applications.

WebSphere MQ Enterprise Transport and WebSphere MQ Mobile Transport
If you are using the built-in input nodes that accept messages across the WebSphere MQ or WebSphere MQ Everyplace® protocols, you can use the following guidelines and recommendations:
  • Using persistent messages

    WebSphere MQ messaging products provide message persistence, which defines the longevity of the message in the system and guarantees message integrity. Nonpersistent messages are lost in the event of system or queue manager failure. Persistent messages are always recovered if a failure occurs.

    You can control message persistence in the following ways:
    • Program your applications that put messages to a queue using the MQI or AMI to indicate that the messages are persistent.
    • Define the input queue with message persistence as the default setting.
    • Configure the output node to handle persistent messages.
    • Program your subscriber applications to request message persistence.

    When an input node reads a message is read from an input queue, the default action is to use the persistence defined in the WebSphere MQ message header (MQMD), that has been set either by the application creating the message, or by the default persistence of the input queue. The message retains this persistence throughout the message flow, unless it is changed in a subsequent message processing node.

    You can override the persistence value of each message when the message flow terminates at an output node. This node has a property that allows you to specify the message persistence of each message when it is put to the output queue, either as the required value, or as a default value. If you specify the default, the message takes the persistence value defined for the queues to which the messages are written.

    If a message passes through a Publication node, the persistence of messages sent to subscribers is determined by the subscribers' registration options. If a subscriber has requested persistent message delivery, and is authorized to do so by explicit or implicit (inherited) ACL, the message is delivered persistently regardless of its existing persistence property. Also, if the user has requested nonpersistent message delivery, the message is delivered nonpersistent regardless of its existing persistence property.

  • Processing messages under syncpoint control

    The default action of a message flow is to process incoming messages under syncpoint in a broker-controlled transaction. This means that a message that fails to be processed for any reason is backed out by the broker. Because it was received under syncpoint, the failing message is reinstated on the input queue and can be processed again. If the processing fails, the error handling procedures that are in place for this message flow (defined either by how you have configured the message flow, or by the broker) are executed.

    For full details of input node processing, see Managing errors in the input node.

WebSphere MQ Telemetry Transport
If you are using the SCADAInput node that accepts messages from telemetry devices across the MQIsdp protocol, this protocol does not have a concept of queues. Clients connect to a SCADAInput node by specifying the port number on which the node is listening. Messages are sent to clients using a clientId. However, you can specify a maximum QoS (Quality of Service) within a SCADA subscription message, which is similar to persistence:
  • QoS0 Nonpersistent.
  • QoS1 Persistent, but might be delivered more than once
  • QoS2 Once and once only delivery

If a persistent SCADA message is published, it might be downgraded to the highest level that the client can accept. In some circumstances, the message might become nonpersistent.

WebSphere MQ Real-time Transport and WebSphere MQ Multicast Transport
If you are using the Real-timeInput and Real-timeOptimizedFlow nodes that accept messages from JMS and multicast applications, no facilities are available to protect against message loss. You can, however, provide recovery procedures by configuring the message flow to handle its own errors.
Other transports and protocols
For user-defined input nodes that receive messages from another transport protocol, you must rely on the support provided by that transport protocol, or use the recovery procedures provided by the supplier of the user-defined nodes.
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. All Rights Reserved.
Last updated : 2009-01-07 15:39:38

ac00420_