[cpuffalt]

Justin,

Thanks for your response.  Here are the settings on the MDB:

@MessageDriven(name = "MailProcessorMDB", activationConfig = {
  @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
  @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:/jms/queue/KdmMailServiceQ"),
  // Attempt to workaround JBoss bug: https://issues.jboss.org/browse/WFLY-2608
  // See also https://community.jboss.org/message/846746
  @ActivationConfigProperty(propertyName = "clientFailureCheckPeriod", propertyValue = "600000"),
  @ActivationConfigProperty(propertyName = "connectionTTL", propertyValue = "-1") })
@Singleton
@Startup
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class MailProcessor implements MessageListener
{
 ....

Our use case is very straightforward, just a simple MDB processing items from a JMS queue internal to JBoss.  Although the fix in HORNETQ-1314 should resolve our particular issue it doesn't sound like a complete fix as you could still see this issue in the case where the JMS queue is remote unless there were also changes made to actually retry the connection properly in the case of a timeout (no idea if this is a JBoss issue or HornetQ issue). That said, do you know which versions of Wildfly and JBoss EAP have the upgraded HornetQ library with the fix?  I checked the Wildfly 8 & 8.1 release notes but don't see any mention of a HornetQ upgrade and the JBoss EAP matrix (https://access.redhat.com/articles/112673) doesn't appear to be updated for 6.3 yet.

Thanks,

Corey

[jbertram]

Our use case is very straightforward, just a simple MDB processing items from a JMS queue internal to JBoss.

In that case I would fully expect the activation configuration properties you have set to work around the issue.  Since they didn't I will need a reproducible test-case or at the very least trace level logging from the time the server started until the error was observed.

Although the fix in HORNETQ-1314 should resolve our particular issue it doesn't sound like a complete fix as you could still see this issue in the case where the JMS queue is remote unless there were also changes made to actually retry the connection properly in the case of a timeout (no idea if this is a JBoss issue or HornetQ issue).

Presumably in that case the connection failure would bubble up to the MDB activation layer and trigger re-activation of the MDB.  I haven't seen any complaints about remote MDBs not recovering from connection time-outs.

In any case, this is a HornetQ issue, not a JBoss AS or WildFly issue.

That said, do you know which versions of Wildfly and JBoss EAP have the upgraded HornetQ library with the fix?  I checked the Wildfly 8 & 8.1 release notes but don't see any mention of a HornetQ upgrade and the JBoss EAP matrix (https://access.redhat.com/articles/112673) doesn't appear to be updated for 6.3 yet.

I don't think either WildFly or JBoss EAP have HornetQ 2.4.2.Final (which contains the fix from HORNETQ-1314) yet.  You'd need to upgrade HornetQ yourself to get that.