message-driven-channel-adapter --

[jebscar]

We have a use case where we need to take a message off a JMS queue (websphere mq), transform it and insert it into a database. If for some reason processing fails (transformation or db insertion) we want to log the exception out using our logging framework and requeue the original message a separate queue so that a app support engineer can review it.

Our current configuration is below. The issue seems to be the that the message getting requeued using the outbound-channel-adapter contains the Spring integration Message object not just the original String message.

We have support tools to allow app support engineer to resubmit the message for processing after any issues have been resolved. Since the message now contain more than just the original String message processing fails.


Could this just be a simple configuration oversight on our part? Do we need a custom component? Any guidance would be appreciated.

thanks again.

	<int-jms:message-driven-channel-adapter container="listenerContainer" 
		channel="dataFeedV1InChannel" error-channel="invalidDataFeedV1OutChannel"/>
	 
	<bean id="dataFeedV1ListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
		<property name="concurrentConsumers"    value="2" />
		<property name="maxConcurrentConsumers" value="5" />
		<property name="connectionFactory"      ref="connectionFactory" />
		<property name="destinationResolver"    ref="destinationResolver" />
		<property name="destinationName"        value="DATAFEED.QUEUEV1" />
		<property name="cacheLevelName"         value="CACHE_NONE" />
		<property name="acceptMessagesWhileStopping" value="false" />
		<property name="recoveryInterval"            value="10000" />
	</bean>


	<int-jms:outbound-channel-adapter id="invalidDataFeedV1OutChannel" connection-factory="connectionFactory"
		destination-resolver="destinationResolver" destination-name="INVALID.DATAFEED.QUEUEV1"/>

[Mark Fisher]

Rather than setting up that explicit error-channel, can you not just rely on transaction management to handle this use-case? If not, can you explain how it's different?

Thanks,
Mark

[jebscar]

Mark, Thanks for the quick response. Our application does not manage the JMS operation and DB operation inside a single distributed transaction.

Our assumption is that once the message has been removed from the queue and that transaction committed that if we want to move the message to a different queue b/c the db insert failed that we would need to handle this ourselves.

The db transaction is handled inside a legacy stored procedure that has its own try/catch and it returns an error code on failure.

If for some reason putting the message onto the invalid queue when db insert fails we would write the message to disk.

[Mark Fisher]

The initial JMS transaction will only commit (and thereby remove the message) if the entire scope of the MessageListener's onMessage method does not throw an Exception. IF the DB failure is within that scope, then its Exception should propagate in such a way as to trigger the rollback for the JMS receive (thereby leaving the Message on the Queue). If you haven't already, check out this article which explains that idea and other approaches in much more detail: http://www.javaworld.com/javaworld/j...nsactions.html

Hope that helps,
Mark

[jebscar]

what is the db insert failure was the result of a poison message? You would not necessary want the transaction rolled back and put back on the queue, no? There would be no way to move past this. That is why we thought we needed an outbound channel adapter to move the message to another queue for further investigation. is there a simpler means of handling this use case?