This problem bites as well when it comes to web based messaging (IE teeing up BizTalk exchanges with the business requirements around duplicates).

So, the last time I worked this kind of system (XML messaging over JMS), we went live and naturally the surprise exceptions came in. But what was really biting us were the unhappy side effects of either trying to recover inside onMessage() or the JMS provider sending the message back in. For the most we didn’t see transient failures at that level; if it didn’t go the first time it probably ain’t gonna go period. Web systems are very different in terms of transient failures (retrying is entirely justified).

So, after a few months I decided to change the onMessage() failure behaviour to use an an application level DLQ - a file system write. We removed a lot of code. No exceptions ever thrown back to the provider, no smart handling, no recovery behaviour. To heck with commits and rollbacks, just crash out, log the problem, plonk the message on disk, and wait for the next message. As dumb as you like, but with no partial failure. It’s unintuitive, but it was a very good way to get a highly robust application that had the required business semantics. What was lost in leveraging JMS infrastructure (after all, who the heck writes a custom DLQ on top of JMS), was gained in transparency.

Also note, doing efficient parallel consumption across threads in JMS is harder than it might first appear - quick answer, take a look at ServerSessionPool in JMS.

If I’m not mistaken, this means that most of the benefits claimed by using J2EE containers or Spring for processing producer-consumer style messages is lost - meaning session and whatever polling & thread pool & stuff.

As for topics I think a thread pool is easily written. I see no reason whatsoever to tie myself to a particular framework and philosophy in order to achieve that stuff.

Come XA, I definitely need a transaction manager…

But this is exactly what the JMS containers (be it MDB or MDP) do for you.

(Also note that a JMS container will do nice JMS connection, session & thread pooling for you too - not using a regular client side JMS consumer, but using the ServerSessionPool stuff - with a configurable thread pool so you can define how parallel things go & how threads work across multiple subscriptions etc).

This reminds me a bit of Joe’s recent post on DAO frameworks. You’re effectively writing a mini-JMS container to handle the transactions & retry. This is totally fine (I’ve done the same before in the past).

However you could try just reuse an MDB / MDP container, which does everything you need - plus lots more (connection pooling, thread pooling, nicer configuration, full XA support if required etc etc) - without using proprietary APIs.

i.e. there’s no reason why you can’t do this using JBoss, Geronimo or Spring today.

The only real trick is - for invalid messages, send to a DLQ, otherwise throw a runtime exception for system failures. Other than that you can reuse the rest - if you wish. But by all means write your own mini-JMS container if you wish - horses for courses etc.

(BTW the links work currently for the ActiveMQ examples on the JCA container :)

I’m not sure how using spring would do anything different, apart from perhaps having me code a configuration file rather than write some actual code. Oh, and I’d love to read the ActiveMQ documentation, but it seems all the example links go to your now non-existant CVS repository :-)

And as for keeping transaction management out of business logic, how does that work where transaction management is business logic? For us, we have faliure scenarios which as an implementational detail have been implemented as transactions.

Then if you can detect an invalid message in some way, send it to a dead letter queue? Then for bad messages, you process them successfully but place them on a DLQ. For any bad errors, you let runtime exceptions bubble up.

Once you’ve done that you can use a JMS container (MDB container or a Message Driven POJO container, like the one for Spring) to process the messages and let it worry about handling JMS transactions start/commit/rollback, XA transactions or message acknowledgements, re-try, timeouts and the like?

i.e. keep the middleware stuff out of your business logic & focus on the main logic you need to do - process the messages and detect bad messages.

If you wanna Message Driven POJO container using Spring, try this…

http://activemq.codehaus.org/JCA+Container

Otherwise any old MDB container would do the trick (though you might wanna wrap your MessageListeners’s in MDB wrappers to make them full MDBs).