JMS At Least Once

The JMS At Least Once policy applies to SOAP and JMS Bindings. It ensures that the JMS messages are delivered at least once to the recipients in case of exception scenarios by using the redelivery mechanism.

JMS AtLeastOnce policy is supported only when the configured JMS provider is Enterprise Message Service or Websphere MQ.

The JMS AtLeastOnce policy can be applied on JMS Binding on promoted service as well as promoted reference. At JMS Service Binding, policy will ensure that no message loss happens in case of exception scenarios and at JMS Reference Binding, policy dictates that the JMS Message delivery mode is "PERSISTENT".

Limitations

  • JMS At Least Once policy can only be used to satisfy At Least Once intent for the JMS transport bindings - JMS and SOAP/JMS bindings.
  • JMS At Least Once policy supports only In-only MEP.
  • JMS At LeastOnce policy can coexist with Virtualization At Least Once, Virtualize, Secure Virtualization and Threading Policy. It cannot coexist with JMS Transacted One Way, Virtualization Transacted OneWay, or At Most Once policies at any enforcement point.
  • Only TIBCO EMS and WebSphere MQ JMS providers are supported. An error is displayed if any other JMS provider is configured. If JNDI initial context factory is configured for any JMS provider other than TIBCO EMS or MQ, an error message is displayed.
  • If an error queue has not been created and the JMS Provider does not support dynamic queue creation or the user of the provider does not have create permissions, JMS binding deployment fails. If the error queue is deleted after the application is deployed, JMS binding attempts to move the erroneous message to the error queue. On failing to do so, it indefinitely attempts to move the message to the error queue regardless of the redelivery attempt configuration.

Properties

Following properties are configurable on JMS AtLeastOnce policy configured on JMS Binding on Promoted Service.

The JMS At Least Once policy configured on JMS Binding on Promoted Reference only indicates that the message delivery mode is "PERSISTENT" and no redelivery configuration is allowed.

Parameter Description
Max redelivery count The JMS binding continues to attempt delivery until either delivery succeeds, or the number of delivery attempts reaches this value. For example, with a value of 1, the Messaging Bus attempts only the initial delivery, then stops.

Zero is a special value, indicating no upper limit on redelivery.

Default: 0.

Redelivery delay interval (s) After each failed delivery attempt, the JMS binding waits for this interval before its next attempt.

Default: 15.

Exceptions upon which to stop redelivery If the provider throws any exception in this list, then the JMS binding cancels further delivery attempts (even if the maximum redelivery count has not yet reached).

Default: None.

Enable error queue Indicate how a message is treated when delivery fails—that is, the JMS binding exceeds the maximum delivery count or the service implementation throws an error that stops delivery.

When checked, place the message on the error queue defined in the Error queue name field. When unchecked, discard the message.

Default: Unchecked.

Transactional

Indicates whether move to error queue should happen in the same session transaction in which message from source destination was received.

Note: Transaction here is not an XA transaction, this is only a session transaction.
Error queue name The queue on which JMS binding places failed message if the error queue is enabled.

A warning is displayed on the Promoted Service indicating configured error queue should be present on the JMS provider.

Default: Default error queue name is JMSAtLeastOnce_ErrorQueue.

The JMS AtLeastOnce policy can be configured with the redelivery configuration by setting redelivery count and redelivery delay. In case when delivery fails, message is redelivered as per the configured redelivery count and with the redelivery delay. When message is moved to error queue following additional string properties describing the cause are added to the JMS message.

Property Description
_JMSJCA_ExceptionMessage Message from exception stack trace i.e. cause of redelivery.
_JMSJCA_ExceptionClass Java exception class
_JMSJCA_ExceptionStackTrace Stack trace of the exception occurred which initiated redelivery.
DeliveryFailureReason Failure reason if other than exception message otherwise exception message.
AMX_NODE_NAME Name of the AMX NODE on which application is deployed.
AMX_HOST_NAME Name of the AMX HOST, which contains AMX Node.
AMX_ERROR_MSG Property indicating whether this message is error message, TRUE when message is moved to error queue.
SourceDestinationName Name of the Source destination from which message was received.
SourceDestinationType Destination type of the source destination.
Contents
Search Results