The DLQ support for MDB really is handled by the EJB container, and is not part of JBoss Messaging itself. There are several pluggable DLQ strategies, see:
It does seem that there is no way to look at the exception/cause of redelivery.
For MDB, you're actually not supposed to throw exceptions from onMessage(). So, by design you would never know the "cause." If you want to get fancy, track your failures some other way...
This might be the wrong forum but..
I've had a look at the jboss 4.2.0 code and as far as I can see the DLQ handler never receives the exception,
it only receives the Message again and has to figure out if it should be dlq'ed or not..
I haven't had a chance to look at Messaging 1.4.0.CR1 source yet, but the release notes says it has fixed a redelivery delay issue.
It doesn't say how, but maybe there is something in the fix that might help..
For MDB, you're actually not supposed to throw exceptions from onMessage(). So, by design you would never know the "cause."
A MDB is not designed to throw a Application exception, but it is certainly designed to throw a System exception (as any other method).
When using Container managed MDBs, one of the ways to performing a rollback is actually to throw a System exception.