MDB behaviour during retry

[marcanthony]

Hi guys

I have a question concerning the behaviour of HornetQ whilst retrying a delivery.

This is my config under wildly (8.0.0 final)

<address-setting match="#">

                        <dead-letter-address>jms.queue.DLQ</dead-letter-address>

                        <expiry-address>jms.queue.ExpiryQueue</expiry-address>

                        <redelivery-delay>180000</redelivery-delay>

                        <max-delivery-attempts>30</max-delivery-attempts>

                        <max-size-bytes>10485760</max-size-bytes>

                        <page-size-bytes>2097152</page-size-bytes>

                        <address-full-policy>PAGE</address-full-policy>

                        <message-counter-history-day-limit>10</message-counter-history-day-limit>

</address-setting>

Lets say my MDB throws an exception, it will get put to aside and reattempted after 3mins, in the meantime are other messages processed or does the queue block?

thanks

Marc

[dgrove_redhat.com]

Hi Marc,

The JCA is responsible for message delivery and activation of the MDB.  The JCA starts JMS sessions and places a message listener on those sessions.  When a message comes in, the JCA delivers the message to the MDB.

So in your scenario, messages are still delivered.

I hope that helps,

Doug

[marcanthony]

Hi Doug

Thanks for the reply, looks like I may have a problem then. My MDB tries to obtain a write lock on a row then do some processing, so if there are 2 messages for the same entity one will have to wait. Now assuming I have 20 mdbs listening on the queue, yesterday I found a thousand or so messages waiting to be processed, with roughly 4 of them had been processed and couldn't acquire a lock and the rest stuck. Only after restarting the dB the queue started to be processed again. It was rather weird that the db is correlated with the mdb business process not the queue  itself. It seems that the messages that couldn't acquire a lock were stuck and stopped the rest from getting through, do you think that is possible?

Thanks

Marc

[jbertram]

It's worth getting a thread dump from the application server when it gets in this state.  It's possible that your MDB instances are hung in a database operation (or otherwise) and therefore not able to process additional messages.

You could also look at the statistics for the queue when it gets into this state and check the message-count, consumer-count, and delivering-count.  If all those are > 0 but never decrease that indicates your consumers are stuck.

[marcanthony]

I have slightly changed the db settings and will monitor, it I hit the lock again will get dumps and post them.

thanks for the help guys

Marc