HornetQ Resource Adapter and DLQ handling

[ataylor]

Theres currently an issue with DLQ handling in the HornetQ resource Adapter. Basically we ignore the DLQ settings in the Activation spec. These were only added because there is some code that calls these and sets these with defaults, but basically they are no ops.

The problem is that these methods dont really make sense in a HornetQ context, for instance one seting is for the providers JNDI, but in our RA code we dont use JNDI at all, this is so our RA will work with any container. Also we dont have the notion of a DLQ we have a dead letter address which could have n queues bound to it.

As far as I can see there are the following solutions.

1. We change the activation spec to have HornetQ specific settings. This means however that apps being migrated will have to be ported.

2. We keep the same spec and handle this at th ejb3 layer.

3. We keep the same spec but change our RA to somehow handle this, altho it would be a huge hack and we dont really want to do this.

thoughts guys, any other possible solutions.

P.S Jaikirin is looking in the ejb3 code to see where these defaults are set as this would need changing too

[jaikiran]

Actually, there are 2 things to be considered here:

1) Provider specific activation config properties : As Andy says - JBM used to support some of the activation config props which are no longer valid in HornetQ. As Andy and I discussed over IRC, I'll see if EJB3 code mandates some of these properties to be available. If it does, then we will have to move it out of EJB3 (including the related documentation) to make it a JMS provider specific config.

2) The meaning/usage of DLQ : In HornetQ, there are just Dead letter Addresses. But from the point of view of a JMS client (like MDB) which are just aware of (JMS) queues and (JMS) topics, how would the MDB subscribe to a dead letter (JMS) queue. I am still looking at the hornetq configs in AS and reading through the docs to see how the (hornetq) DLA is being setup. I guess, there needs to be some layer which sets up a (HornetQ) queue subscription to the DLA to make it look like the (JMS) DLQ.

[jaikiran]

By the way, currently we also allow MDB specific dead letter  queue which overrides the global DLQ. We'll have to see how that works out with HornetQ.

The entire set of JBoss specific (actually JBM specific) activation config properties are here http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/tutorial/1.0.7/html/Message_Driven_Beans.html in the second table.

[jaikiran]

jaikiran pai wrote:

I am still looking at the hornetq configs in AS and reading through the docs to see how the (hornetq) DLA is being setup. I guess, there needs to be some layer which sets up a (HornetQ) queue subscription to the DLA to make it look like the (JMS) DLQ.

More specifically, I am checking how this is any different from a MDB listening to a "normal" queue in HornetQ

[jaikiran]

jaikiran pai wrote:

2) The meaning/usage of DLQ : In HornetQ, there are just Dead letter Addresses. But from the point of view of a JMS client (like MDB) which are just aware of (JMS) queues and (JMS) topics, how would the MDB subscribe to a dead letter (JMS) queue. I am still looking at the hornetq configs in AS and reading through the docs to see how the (hornetq) DLA is being setup. I guess, there needs to be some layer which sets up a (HornetQ) queue subscription to the DLA to make it look like the (JMS) DLQ.

We can stop worrying about this part now, because the reason why the DLQ/DLA is not being triggered for the MDB, is because of this bug/config issue in HornetQ http://community.jboss.org/message/537970#537970

I quickly hacked the MessageReference#getDeliveryCount() impl to return a value higher than the max-delivery-count and I could see that the message is redirected to the DLQ and the EJB3 test passes. So it's just a matter of fixing that issue mentioned in the other thread.

As for the other questions raised in this thread, they are still valid.

[jaikiran]

Andy Taylor wrote:

P.S Jaikirin is looking in the ejb3 code to see where these defaults are set as this would need changing too

I looked at the EJB3 code. The provider specific activation config properties (like dlqMaxResent) are set only if the user configuring the MDB with those properties. Without those properties, EJB3 does not invoked the corresponding method on the activation spec. And from what I tested, I don't see those methods on HornetQActivationSpec being called, unless someone explicitly sets these properties.