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.

Redelivery QOS library implemented as decorator (com.sun.jbi.common.qos.messaging.BaseMessagingChannel) on JBI Delivery channel and implements interface com.sun.jbi.common.qos.messaging.MessagingChannel an extension to JBI Delivery channel.

It 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.

Component's ServiceUnitManager reads the QOS configuration from SU deployment descriptor (jbi.xml) using the utility from QOS module and sets on BaseMessagingChannel.

Goal

It would be simple and easy if QOS library could take the complete responsibility for redelivery both runtime and deployment.

Challenges

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.

Proposals for runtime

Proposal - I

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.

Pros

It is simple

Cons

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 interface defined in QOS. BaseMessagingChannel implements it.

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, type of MEx (InOnly/InOut), 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.

Pros

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.

Cons

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

Proposal for deployment

Component's ServiceUnitManager.init(), it could set SU name and SU path on BaseMessagingChannel. BaseMessagingChannel read the QOS configuration from descriptor instead of Component setting it.

This page (revision-5) was last changed on 10-Jun-08 23:07 PM, -0700 by Murali.
This page was created on 10-Jun-08 15:44 PM, -0700 by Murali.

More info...