[marklittle]

"beve" wrote:

Why don't you use transacted JMS sessions

Well, we also have the use case when it does not make sense to redeliver the message, like when a transformation or validation fails. The redelivery service can be configured with a retry count which we could then take advantage of. This is not an optimal solution as we will still be trying to redeliver/re-execute a message that we know will fail.

OK. I'm not sure if that feature request will get into the 4.2.1 release though.

While we are on the subject of transacted JMS Sessions, we are using the JMSGatewayListener and as far as I can see these JMSSessions are created without transactions and AUTO_ACKNOWLEDGE. But there is a JIRA (http://jira.jboss.com/jira/browse/JBESB-439), which I'm sure you know:)
Lets say we make this configurable so that the JMSGatewayListener's sessions are transacted, and also make the ack mode be configurable.
How do we commit the transaction upon sucessfully completing the action pipeline?

Yes, this is all related to the recent re-assignment ;-)

[beve]

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

[beve]

Just to follow up on this and not to confuse other reading this thread.
The functionality mentioned in this thread is outdated. The code changes mentioned did not make it into the code base and will not be added.

We later reverted to use a retry funtionality similar to what it demonstrated in the quickstart jms_transacted.

/Daniel

[prasha8]

Hi Daniel

Can you pls tell me how did u sort out the webservice redelivery issue?

I am also trying to do something similar

1. get message, transform the message

2. call external webservice to post the message via SoapClient action

Trying to figure out

1. how do i handle "network / webservice unavailability" issues

2. How do handle any buinsess fault thrown by the external service.. need to resubmit the message again