JMSXDeliveryCount with GenericDLQHandler

[svadu]

Hi all,

I use JBoss 4.2.2 configured for Tibco EMS as per: http://wiki.jboss.org/wiki/Wiki.jsp?page=IntegrationWithTibcoEMS

While normal reception of messages works:

2008-02-15 17:45:34,121 DEBUG [org.jboss.resource.adapter.jms.inflow.JmsActivation] Setting up org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@17f9401(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@f4104f destination=queue/MyQueue isTopic=false tx=true durable=false reconnect=10 provider=java:/TIBCOJMSProvider user=null maxMessages=1 minSession=1 maxSession=15 keepAlive=60000 useDLQ=true DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=5)

and I am able to receive and send messages to the queue.

However, I have problem that messages that are sent to DLQ are getting resent by the MDB to the DLQ in an infinite loop.
After some debugging it appeared that JMSXDeliveryCount in the message is not incrementing...
Since GenericDLQHandler is the one that treats messages in DLQ in this case I've check what it does and it appears that the only way I see for GenericDLQHandler to increment the resent counter is if msg.getIntProperty throws a JMSException which isn't happening.

Can someone give me a clue on the problem (I hope I described the problem more or less accurately)?
Do I need to rely (woudl require even more vendor specific configuration) on the external JMS server (Tibco in this case) to handle redelivery counts?

Thanks in advance.

[adrian.brock]

"svadu" wrote:

Can someone give me a clue on the problem (I hope I described the problem more or less accurately)?

JMSXDeliveryCount is a property set by the JMS provider (Tibco) not JBoss.
We just use it to determine number of redeliveries when it exists (it is optional).

Perhaps it is a property Tibco doesn't support, but the message originated
in some other system that does set the property. i.e. Tibco just copied it?

Do I need to rely (woudl require even more vendor specific configuration) on the external JMS server (Tibco in this case) to handle redelivery counts?

No idea. But I'd imagine Tibco has internal support for DLQs or
some other poisened message handler?.
So you probably don't need to configure a DLQ handler in JBoss at all?

* Set the activation-config-property useDLQ=false
* Configure a DLQ (or whatever mechanism they have) for your queue/topic in Tibco.

The only reason the DLQ handler exists in the MDB is because JBossMQ
doesn't support them internally. Most other JMS providers do support them
inside the server.

[svadu]

Hi Adrian,

Thanks for your reaction.

"svadu" wrote:

Can someone give me a clue on the problem (I hope I described the problem more or less accurately)?

JMSXDeliveryCount is a property set by the JMS provider (Tibco) not JBoss.
We just use it to determine number of redeliveries when it exists (it is optional).

Considering that GenericDLQHandler doesn't increment it I came to the same conclusion.

Perhaps it is a property Tibco doesn't support, but the message originated
in some other system that does set the property. i.e. Tibco just copied it?

Well it's imported from other messaging system (TIBCO specific) which doesn't know about JMSXDeliveryCount. But TIBCO EMS (which performes the import) does support the property.

Do I need to rely (would require even more vendor specific configuration) on the external JMS server (Tibco in this case) to handle redelivery counts?

No idea. But I'd imagine Tibco has internal support for DLQs or
some other poisened message handler?.

Yes in fact it does, but the queue is not configurable (and I like being able to configure DLQ name per queue, for example).

So you probably don't need to configure a DLQ handler in JBoss at all?

* Set the activation-config-property useDLQ=false
* Configure a DLQ (or whatever mechanism they have) for your queue/topic in Tibco.

Not using the DLQ at all might see the most portable option here, I don't like relying on TIBCO's dlq even more... Fortunately, it seemed that the problem was due to very high load in TIBCO EMS (or corrupt data). Anyway I set max delivery to 1 in the MDB so that if the counter is greater 1 (it was 2 in my case) it is delivered to DLQ. It works so far (and for new messages it is increasing for some reason). May be the problem was queue settings (queues can be made synchronized for better thread safety when writing to the file system). Anyway, the problem is, somewhat resolved.

The only reason the DLQ handler exists in the MDB is because JBossMQ
doesn't support them internally. Most other JMS providers do support them
inside the server.

I hope it stays this way (the generic DLQ support).