Consuming unparseable JMS messages

[Gorky]

Greetings.

This scenario is a little complex (sorry).

Transaction Start
JMS->Sends XML->SI Listener->Transformer->Router->Processor->Database
Transaction End

"Happy Path" is working.

When the XML can not be transformed, it logs it (using the corporate logger).
Q: How does one "consume" the message so that it does not get passed to the Router, or rolled back on the JMS Queue? (There is no error channel for a Transformer -- and some Database errors, such as Deadlocks, we do want to roll the message back for a retry)

Regards,
Steve

[Gorky]

Transformer generates a dummy object for the invalid message, Router routes to a dummy processor. There has GOT to be a better way of handling this scenario.

[Mark Fisher]

Maybe you just need to add a <filter>? That can drop the Messages that you are not interested in, and if you prefer to do so quietly (not throwing an Exception), you can. That way the transaction can still commit.

If I'm not understanding your requirement, please let me know.

HTH,
Mark

[Gorky]

Hi Mark.

Sorry we missed in Dallas -- that was a really nasty storm a couple of weeks ago.

Unfortunately, until we try to Transform the Message from XML to a Jaxb object, we don't know if it's valid. The requirement here is that we need to remove invalid/non-conforming XML messages from the JMS Q so that they don't block the queue (its a FIFO Queue) continually retrying a message that can not be consumed, and the transformer is the first thing in line that has the ability to detect this.

-Steve

[Mark Fisher]

It sounds like you might want to specify an "error-channel" on the inbound adapter. You can view that as playing the role of a catch block for the message flow that initiates at that adapter. If you "handle" the validation errors there (e.g. record the data somewhere for auditing purposes), then the JMS transaction will commit so that no redelivery occurs.

[Gorky]

Hi Mark.

Thanks for the reply.

JMS Adapter -> Transformer -> JDBC Processor (End Consumer)

Transformer - errors here need to be consumed.
JDBC Processor - unhandled errors here need to be put back on the Queue for a retry.

How do I get both?

-Steve
[Edited for clarity]

[Mark Fisher]

If you add the 'error-channel' on the JMS adapter, it will be the starting point for an error-handling flow. You can think of that as the messaging equivalent to a catch block. As with a catch block, if you rethrow any Exception from within that flow, it will propagate, thereby triggering a rollback. If you "handle" the Exception (e.g. write to a log and suppress propagation), the TX will commit instead.

Is that clearer?
-Mark

[Gorky]

Yes, much, thanks!

[Gorky]

Question: How do you configure ErrorMessageExceptionTypeRouter? I've not found any examples anywhere in the documentation?
Answer: (Found this while looking for examples in Google)
http://forum.springsource.org/showthread.php?t=63715

Regards,
Steve

[Gorky]

That link seems to be SI 1.x, NOT 2.x, which is what I am working with. What I came up with was;
<router input-channel="errorChannel" default-output-channel="defaultErrorChannel">
<mapping
value="com.atxg.tm.utils.UserDefinedException"
channel="databaseErrorChannel" />
<beans:bean id="errorRouter"
class="org.springframework.integration.router.Erro rMessageExceptionTypeRouter">
</beans:bean>
</router>

<channel id="defaultErrorChannel" />
<channel id="databaseErrorChannel" />

And for the ExceptionHandlers:
@MessageEndpoint("exceptionHandler")
public class ExceptionHandler
{
@ServiceActivator(inputChannel = "defaultErrorChannel")
public void handleMessage(final Message<Exception> message)
{
final Exception exception = message.getPayload();
//do stuff
}
}

@MessageEndpoint("databaseExceptionHandler")
public class DatabaseExceptionHandler extends ExceptionHandler
{
@Override
@ServiceActivator(inputChannel = "databaseErrorChannel")
public void handleMessage(final Message<Exception> message){
//DO Stuff
//Otherwise, default handling
super.handleMessage(message);
}

Snippets from the attached log output:
2011-03-08 11:53:11,466 [main] INFO o.s.i.e.EventDrivenConsumer:AbstractEndpoint - started databaseExceptionHandler.handleMessage.serviceActi vator
2011-03-08 11:53:11,466 [main] INFO o.s.i.e.EventDrivenConsumer:AbstractEndpoint - started databaseExceptionHandler.handleMessage.serviceActi vator#2
2011-03-08 11:53:11,466 [main] INFO o.s.i.e.EventDrivenConsumer:AbstractEndpoint - started exceptionHandler.handleMessage.serviceActivator

Followed by a large number of:
2011-03-08 11:54:25,049 [org.springframework.jms.listener.DefaultMessageLis tenerContainer#0-1] WARN

o.s.j.l.DefaultMessageListenerContainer:AbstractMe ssageListenerContainer - Execution of JMS message listener failed, and no ErrorHandler has been set.
java.lang.IllegalArgumentException: payload must not be null

Q1) what's up that the DatabaseExceptionHandler seems to get setup twice?
Q2) Why does the listener think that no Exception Handlers have been configured?
NOTE: In some cases, the exception handler needs to throw an exception back to the Adapter for a Rollback, as there are cases when a message should be retried.

-Steve