Index Changes

Difference between version and version     

Back to Redelivery Enhancements, or Redelivery Enhancements Info

At line 1 added 1 line.
!!!Redelivery QOS Enhancements
At line 3 added 66 lines.
[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.
It would be simple and easy if QOS library could take the complete responsibility for redelivery both runtime and deployment.
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.
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(ExchangeTemplates et) to com.sun.jbi.common.qos.messaging.MessagingChannel interface defined in QOS. BaseMessagingChannel implements it. ExchangeTemplates interface is defined as:
public MessageExchange createExchange() throws MessagingException;
QoS provides a base implementation of this interface; it is the responsibility of the component to extend with 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 ExchangeTemplates.createMessageExchange(). 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 ExchangeTemplates & 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.
!!! Include Throttling in QOS
QOS library can be enhanced to do Throttling. Should it pause the invokes from the component for given EP/SU when SU is stopped?

JSPWiki v2.4.100
« Home Index Changes Prefs
This page (revision-8) was last changed on 06-Aug-08 15:28 PM, -0700 by KevanSimpson