Index Changes
This is version 2. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Redelivery QOS Enhancements

Redelivery processing is implemented by HTTP-BC and BPEL-SE, both of them use QOS library. Implementation is shared between the component and the QOS library.

QOS library implemented as decorator on JBI Delivery channel( com.sun.jbi.common.qos.messaging.MessagingChannel) keeps track on number of delivery attempts, and the error information associated with those invocations. It provides an API to query this information helps components making decision on retries. On completion of redelivery attempts component and QOS library share what is the due course for the Message Exchange (MEx). If user configured to "propagate error" or "suspend", component owns the responsibility. Otherwise namely "delete" or "error endpoint" QOS does the work and sends "Done" to component.


It would be simple and easy if QOS library could take the complete responsibility for redelivery. Here are the thoughts


When MEx associated with transaction. QOS library can not redeliver the MEx if transaction is set to rollback only as it would not know how to create a transaction. Same time it would not know whether the component is participating in transaction or initiating new transaction and component's logic involved with the transaction.

Can we reduce the burden for the components that are not transaction aware? It could be done by * Resetting MEx state to initial state. * QOS library creates a new MEx and copies input ( source - NormalizedMessage.getContent()), subject, attachment and properties.

Can we come up with exhaustive list of items to be copied from error MEx to new MEx for the second approach? After reviewing the API it does not look like an issue.

Does this approach work if the provisioning component changes the MEx input or properties before setting error. When the MEx is redelivered can the provisioning work with the redelivered MEx? The components reviewed are not changing the MEx they have received, certainly we do not know all the components.

Proposal - I

com.sun.jbi.common.qos.messaging.BaseMessagingChannel(decorator on DeliveryChannel) is defined in QOS. It is constructed in the ComponentLifeCycle.init method.

Component's call DeliveryChannel.send(MessageExchange me)to send the message.

if the MEx received is set to error and there is room for retry, and no transaction (MessageExchange.JTA_TRANSACTION_PROPERTY_NAME is empty), it clones MEx and proceeds with redelivery.

If there no room for retry or MEx is associated with transaction it would return errored MEx to component.


It is simple


It would only work with components that initiate MEx that are not associated with Transaction It may not work for scenarios where Provisioning component or interceptor modifies the MEx.

Proposal - II

Add new operation send(MessageExchangeBuilder mb) to com.sun.jbi.common.qos.messaging.MessagingChannel (decorator on DeliveryChannel) interface defined in QOS.

MessageExchangeBuilder interface is public interface MessageExchangeBuilder { public MessageExchange createMessageExchange(boolean failureOnFirstAttempt); }

QOS could provide implementation of this interface, it would have the logic to create MEx, set input, associate properties, attachments, security/subject and transaction. Component would pass the object of this type to MessagingChannel .send as a parameter.

MessagingChannel .send delegates the call to DeliveryChannel.send with MEx object returned from callback method.

MessagingChannel.accept would delegate to DeliveryChannel.accept, if the MEx received is set to error and there is room for retry, it calls MessageExchangeBuilderObject.createMessageExchange(true). If this operation returns MessageExchange object, it proceeds with redelivery. If the callback method throws Exception, it would return errored MEx to component.

If no room for retry or MEx gets "Done", no change in current logic.


Component has complete control on how it constructs MEx for first attempt and redelivery, but no hassle of managing the redelivery. It works even when MEx is associated with transaction. If component is initiating a transaction, they could rollback transaction and start new. If it is participating, it could throw exception.


Component needs to know new interface MessageExchangeBuilder, & MessagingChannel interface.

JSPWiki v2.4.100
« Home Index Changes Prefs
This particular version was published on 10-Jun-08 19:25 PM, -0700 by Murali