Catch Exceptions inside a Message Driven Bean (MDB)

eclipselink, glassfish-3, java, jpa

Solution

You got a bad case of message poisoning...

The main issues I see are that:

- you are calling directly the `save()` method in your `onMessage()`: this means thet the container has no way to inject the proper transaction handling proxy around the `save` method

- in any case the `save()` method should have `@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)` in order to commit in a separate transaction, otherwise it will join the `onMessage` transaction (which default to `REQUIRED`) and bypass your exception handling code, beign committed after the successful execution of `onMessage`

What I woud do is:

Move the `save` method to a new Stateless session bean:

@Stateless
public class AnalyzerResultSaver
{
    @PersistenceContext(unitName="QIS") 
    private EntityManager em;

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    private void save(AnalyzerResult alyzres) throws PrdItemNotFoundException {
        Some s = em.find(Some.class, somepk);
        s.setSomeField("newvalue");
        // SQL Exception happens after leaving this method
    }
}

Inject this bean in your MDB:

public class SaveAdMessageDrivenBean implements MessageListener {

    @Inject  
    private AnalyzerResultSaver saver;

    @Resource
    private MessageDrivenContext mdc;

    public void onMessage(Message message) {
        try {
            if (message instanceof ObjectMessage) {
                ObjectMessage obj = (ObjectMessage)message;
                AnalyzerResult alyzres = (AnalyzerResult)obj.getObject();
                saver.save(alyzres);
            }
        } catch (Throwable e) { 
            mdc.setRollbackOnly();
            log.log(Level.SEVERE, e);
        }
    }
}

Another tip: in this code the message poisoning still exists. Now it derives from the line invoking `mdc.setRollbackOnly();`.

I'd suggest here to log the exception and transfer the message to a poison queue, thus preventing the container to resubmit the message ad infinitum.

UPDATE:

A 'poison queue' or 'error queue' is simply a mean to guarantee that your (hopefully recoverable) discarded messages will not be completely lost. It is used heavily in integration scenarios, where the correctness of the message data is not guaranteed.

Setting up a poison queue implies defining a destination queue or topic and redeliver the 'bad' messages to this destination.

Periodically, an operator should inspect this queue (via a dedicated application) and either modify the messages and resubmit to the 'good' queue, or discard the message and ask for a resumbit.

Problem

Original source