MDB onMessage() holds the connection in case of redelivering message

Question

I need to redeliver a message if it can't be processed, for example because of some external endpoint failure. So I'm using following MDB configuration (it worth to mention that I'm using openMQ (Glassfish 4.1)):

@MessageDriven(mappedName = "MyQueue",  name = "MyQueue", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "endpointExceptionRedeliveryAttempts", propertyValue = "10"),
@ActivationConfigProperty(propertyName = "endpointExceptionRedeliveryInterval", propertyValue = "30000")})

Here's onMessage() method:

  @Override
  @TransactionAttribute(TransactionAttributeType.REQUIRED)
  public void onMessage (Message message)
  {
    try
    {
      //some processing here
    }
    catch (JMSException jmsException)
    {
      logger.log (Level.SEVERE, "Exception processing notification message", jmsException);
    }
    catch (BackingStoreException e)
    {
      // because of throwing RuntimeException, the message is going to be redelivered according to mdb configuration params(interval and attempts count)
      throw new RuntimeException ();
    }
  }

In order to redeliver a message it's also possible to rollback a transaction, however openMQ lacks the property for redelivery interval, so it doesn't suites me:

https://github.com/javaee/openmq/issues/220

https://github.com/javaee/openmq/issues/23

https://github.com/javaee/openmq/issues/134

All in all, redelivery works fine, besides one moment: if message is going to be redelivered, mdb doesn't release the connection and holds it for endpointExceptionRedeliveryInterval * endpointExceptionRedeliveryAttempts, in my case 5 minutes. So, cause the default values for maxPoolSize is 32, 32 "bad" messages are enough to block the mdb.

Is there are way to release the connection in case of message redelivering?

Answer 1

This is the expected behavior as per JMS specification and I do not think that there could be some way to release the connection object while some sort of message processing is under progress. Read JMS specs here and below is relevant except from "4.3.5 Closing a Connection":

If one or more of the connection’s session’s message listeners is processing a message at the point connection close is invoked, all the facilities of the connection and it’s sessions must remain available to those listeners until they return control to the JMS provider.

When connection close is invoked it should not return until message processing has been orderly shut down. This means that all message listeners that may have been running have returned and that all pending receives have returned.

I am not sure why you want to use such high numbers for retry mechanism, 10 attempts are too big to go for, maximum I have seen till now is 3 times, I think you can try to adjust your retry mechanism numbers, or may be having another connection which is dedicated to re-delivery.