I'm going to try describe this and hopefully this will be clearer. I'll first show the configuration for a single service and then list the changes that we needed to make to get this working for us. We are going to use this solution in production shortly. Service : jboss-esb.xml | <actions> | <action name="PersistMessageOnEnter" class="org.jboss.soa.esb.actions.MessagePersister" > | <property name="classification" value="TicketService-Cl"/> | <property name="ignore-message-classification" value="true"/> | <property name="message-store-class" value="org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl"/> | </action> | | <action name="Catch all Exceptions Action" class="xxx.exceptions.ExceptionHandlingAction" > | <property name="exceptionMethod" value="catchesException" /> | <property name="replyTo-ServiceCategory" value="TicketService" /> | <property name="replyTo-ServiceName" value="TicketInformationResponse" /> | <property name="redeliver-ServiceCategory" value="TicketService" /> | <property name="redeliver-ServiceName" value="TicketInformationService" /> | <property name="classification" value="TicketService-Cl" /> | <property name="rdlv-classification" value="TicketService-Cl-RDLV" /> | <property name="retries" value="3" /> | <property name="undeliverable-classification" value="IPL_ERR_TicketService-Cl-RDLV"/> | </action> | | ...actions that to the real work (transform,validate,poll webservices...) | <action name="RemoveMessageOnExit" class="org.jboss.soa.esb.actions.MessagePersister" | process="removeMessage"> | <property name="classification" value="TicketService-Cl"/> | <property name="ignore-message-classification" value="true"/> | <property name="message-store-class" value="org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl"/> | </action> | </actions> | org.jboss.soa.esb.actions.MessagePersister Has been updated so that one can specify that the classification that has been set as a property on the ESB Message object should be ignored. This is needed in the case where the message is being redelivered and would in our case would have a classification with the suffix "_RDLV". We want the message to be saved to the message store with a suffix of "_Cl" (Classification) upon entry to the service. The same logic is behind the action named "RemoveMessageOnExit" which should always remove the message from the store on exit. We also have a redelivery service for every service: | <listeners> | <scheduled-listener name="redeliver-scheduled-listener" | scheduleidref="rdlv-trigger" | event-processor="xxx.redeliver.RedeliverEventMessageComposer"> | <property name="classification" value="TicketService-Cl-RDLV"/> | </scheduled-listener> | </listeners> | Our custom RedeliverEventMessageComposer is identical to the one in services/jbossesb the only difference being that the classification is configurable. xxx.exceptions.ExceptionHandlingAction | public void catchesException(Message message, Throwable exception) | { | log.debug( " ############### Caught Exception #############" ); | log.debug( "Exception was : " + exception.getMessage() ); | | if ( exception instanceof ActionProcessingFaultException ) | message = ((ActionProcessingFaultException)exception).getFaultMessage(); | | final URI messageURI = (URI) message.getProperties().getProperty( MessageStore.MESSAGE_URI ); | | final Message messageFromMessageStore = getMessageFromMessageStore( messageURI ); | | if ( checkRetries( messageFromMessageStore ) ) | { | addForRedelivery( messageFromMessageStore ); | } | else | { | messageFromMessageStore.getProperties().remove( RETRY_COUNT ); | addToMessageStore(messageFromMessageStore, undeliverableMesssageStoreClassification); | } | | removeMessageFromMessageStore( messageURI ); | setErrorMessage(message, exception); | setReplyTo(message); | | log.debug( " ############### Caught Exception done #############" ); | } | 1. We retreive the message that was stored upon entring the service. 2. We check if the we have reached the number of retries specifiec in the configuration (property name="retries" value="3") 3. If "retries" has not been reached, we store the message with the redelivery classification specified in the configuration. 4. If "retries has been reached, we store the message with the undeliverable classification specified in the configuration. 5. We remove the message that was saved upon entry to the service. 6. We set an error message to the message object with a stacktrace and some other information. 7. Set the reply to for the message according to the configuration. This gives us a simple mechanism for error handling and a way to try automatic redelivery and also minimizes the risk of loosing messages. This also gives us a way to force messages to be redelivered by simply updating their classification in the message store database. As said in a previous post this is a short term solution as we need this right now, and we will be building a more complete error handling process in the coming months. Any thought or comments are appreciated. Thanks, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086161#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...