JMS Client - How to configure onMessageTimeoutMs properly?

[Steven Dürrenmatt]

Hello,

Using JMS Client, we encountered a timeout exception during delivery because our application receives big XML payloads. The default value for "onMessageTimeoutMs" is 2000 ms. Setting it to a higher value resolves the problem. However, we want to make sure that this cannot happen, because getting this exception means interrupting the delivery, so we would have to restart our application to be able to consume messages again.

See https://github.com/rabbitmq/rabbitmq-jms-client/blob/c9e02c36c246fcd6ba491ebdef1ad60beaa0ce58/src/main/java/com/rabbitmq/jms/client/DeliveryExecutor.java#L68

Several questions:

• What is the original purpose of this timeout?
• What is your recommandation on how to set the value? Should we try to measure it with load testing or set it to the highest possible? 
• Is there a way to prevent the loss of consumption? Could we catch the exception and easily recreate the consumer?

Thank you.

[Arnaud Cogoluègnes]

My answers below.

> * What is the original purpose of this timeout?

I'm not the original author of the code, but I'd say it's to avoid that some long message processing hogs all the resources, which could block the delivery for the AMQP channel. Historically the value was even fixed to 2 seconds, but someone contributed the code to make it configurable and we kept the default value.

> * What is your recommandation on how to set the value? Should we try to measure it with load testing or set it to the highest possible?

Setting a value according to your load seems a reasonable solution to me.

> * Is there a way to prevent the loss of consumption? Could we catch the exception and easily recreate the consumer?

Currently, there is not. The AMQP consumer does not have to be closed in case of timeout though, it is possible to catch the timeout exception and e.g. nack the message without requeueing, to kick in dead lettering for example. This cannot be the default behavior for backward compatibility reason, but a new option could be introduced.

Feel free to fill in an issue [1] and ideally submit a PR if this suggestion or any variant could be useful to your use case.

[1] https://github.com/rabbitmq/rabbitmq-jms-client/issues

[Steven Dürrenmatt]

Hello Arnaud,

Thanks a lot for your answer.

Dead-lettering the message (i.e. sending basic.nack) seems to be an excellent option. I will see what I can do with that one... ;)