JMS Client Throws TimeoutException

[Damon Sutherland]

In the DeliveryExecutor.deliverMessageWithProtection(...) method, a timeout is set as an upper limit for how long a message can take to process.  This limit is configurable via the onMessageTimeoutMs property set in the RMQConnection ConnectionParams, but defaults to 2000 ms.

Although this seems reasonable, if we requeue a message due to failure (i.e. an exception is thrown in the MessageListener's onMessage), then we could get into an infinite loop if the message truly does take longer than that setting.  My thought is that a slow consumer shouldn't be managed by the client, but rather by the server.  The server should mark the consumer as "slow" and prefer other consumers over those marked slow.  If a consumer truly does hang, then that is a bug for that consumer to address, not the JMS client.  To prevent messages from stalling and never being delivered, a server property could be set to drop connections that do not respond within X ms (with a connection dropped exception can be thrown in the client, instead of a timeout).

I realize this is architectural opinion, and we can get around it by setting onMessageTimeoutMs to Integer.MAX_VALUE (or some appropriate high value), but I thought I would bring it up in case there is some reason this approach was chosen.

Two questions:

1. Do you see any problems with my suggested work around?
2. Is there a chance of removing this property in favor of server-side monitoring?