Remoting over JMS with receiveTimeout blocks service forever [SPR-13052]

[spring-projects-issues]

Erik van Paassen opened SPR-13052 and commented

I'm using remoting over JMS the way it is explained here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html. I'm using the receiveTimeout on the JmsInvokerProxyFactoryBean, which makes the temp-queue on which the reply is ought to be sent disappear after this timeout. This still works fine.

Since Spring Framework 4.0.7, the MessageListenerContainer does not remove the message from the queue when it can't deliver the reply to the reply queue, resulting in endless retries, as the temp queue will never come back. With Spring Framework 4.0.6 all just worked fine. I think the change has to be related to issue #16631, and the following commit: 7af1e00.

I created a test project (https://github.com/eveoh/spring-jms-remoting-test) which demonstrates the problem with the example code found in the Spring docs. First, run the Server and then run the Client. The client has a receive timeout of 1s and the Server waits 1.5s before sending a reply, so the reply is already gone. The server will keep retrying to process the message endlessly. There's also a spring-v4.0.6 branch, which uses Spring Framework 4.0.6 and works just fine. A message is processed only once and discarded when it can't be delivered to the reply destination.

(The server spawns an ActiveMQ broker, so there's no need to start one by hand.)

---

Affects: 3.2.11, 3.2.12, 3.2.13, 4.0.7, 4.0.8, 4.0.9

Reference URL: https://github.com/eveoh/spring-jms-remoting-test

Issue Links:

• AbstractMessageListenerContainer#doExecuteListener can cause a dropped message if using CLIENT_ACKNOWLEDGE and the container is stopped and subsequently started again. [SPR-12015] #16631 AbstractMessageListenerContainer#doExecuteListener can cause a dropped message if using CLIENT_ACKNOWLEDGE and the container is stopped and subsequently started again.
• Consider rewording ack modes on the listener container javadocs [SPR-12705] #17302 Consider rewording ack modes on the listener container javadocs
• Doc: Clarify AUTO_ACKNOWLEDGE semantics with SimpleMessageListenerContainer [SPR-13278] #17869 Doc: Clarify AUTO_ACKNOWLEDGE semantics with SimpleMessageListenerContainer

Referenced from: commits c111bd7, a64dcc2

Backported to: 3.2.14

[spring-projects-issues]

Juergen Hoeller commented

We're going to address this for 4.2 and the upcoming 4.1.7 / 3.2.14 maintenance releases.

Please note that there won't be any further 4.0.x releases. For remaining issues, we expect everyone to upgrade to 4.1.7 / 4.2 instead.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I've refined our rollback handling to only call Session.recover() in CLIENT_ACKNOWLEDGE mode, which was the original intention anyway. A recover call with the default AUTO_ACKNOWLEDGE mode is at best a no-op (in case of DefaultMessageListenerContainer) and at worst interferes with the broker's automatic redelivery handling (in case of SimpleMessageListenerContainer).

Juergen

[spring-projects-issues]

Juergen Hoeller commented

This is now in master and will be available in the upcoming 4.2.0.BUILD-SNAPSHOT. I'll backport it to 4.1.7 and 3.2.14 later today.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Erik van Paassen, have you had a chance to give this a try against 4.2 RC1 or a 4.1.7 / 3.2.14 snapshot? Would be great for this to be verified before 4.1.7 and 3.2.14 go to general availability towards the end of next week...

Juergen

[spring-projects-issues]

Erik van Paassen commented

We're already using 4.2 RC1 since it's released. I can confirm this now works fine again.

[spring-projects-issues]

Juergen Hoeller commented

Thanks, that's great to hear!