JMS Dead Messages

[MarcelRabe]

Hi experts,

in our scenario we sent messages from PI to the local SAP WebAS JMS Provider (on the PI host and instance) through the JMS Adapter (JNDI). The consumer (BlackBoard) can consume the messages just fine when only a few messagess are put on the queue with some minutes in between. But when a large sum of messages is put on the queue, ready to be consumed in a matter of seconds, the consumer doesn't seem to be able to acknowledge the processed messages and a large number of messages remain on the queue (even though they have been consumed). The messages seem dead to the consumer.

Is this something that can be resolved with server side settings (building in delays for instance) and if so how? Or does it sound like a problem with the consumer software (custom code)?

Rgds

Marcel

[Former Member · Accepted solution]

Hi Marcel,

How the consuming application is triggered? With a trigger monitor on the queue or it is scheduled, doing polling?

Do you see any different informations on the "dead" message, such as backout count?

Is the queue shareable?

Martin

[MarcelRabe · Accepted solution]

Hi Martin,

the consumer is triggered via a trigger on the queue.

I'm not sure what a backout count is, but the messages have a jmsxDeliveryCount value of 1 or 2, which is not enough to put them in a dead message queue (starts at 5).

If by shareable you mean that more consumers can consume the messages the answer is no.

Cheers

Marcel

[Former Member · Accepted solution]

Marcel,

What is the trigger type? Should be first, every or depth.

Depending on how your consumer apps is coded, to consume one message at a time or all of them, you could try changing the trigger type.

First means the trigger will be called once and all the msg present in the queue at the moment should be consumed, every means that the trigger will be called for each msg and that the consuming app should read only one msg at a time.

If you have a backout count on the message it means that the application tried more then once to consume it but it failed. You should see this information in the details of the message.

[MarcelRabe · Accepted solution]

Maybe my answer on the first question wasn't correct. The programmer didn't really know what I asked him (about the trigger or polling) but he replied back: blocking via queue.consume(timeout). I think this means polling right, not trigger.

The remaining messages have an unclear status. The are not marked as dead, have a JMSXDeliveryCount value 1 or 2. Maybe there is somehting wrong with the setup of the JMS Provider (we created our own, instead of using the default one.

Marcel