Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue May 21, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented May 21, 2015

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:

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

Referenced from: commits c111bd7, a64dcc2

Backported to: 3.2.14

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 21, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 22, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 22, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 11, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 11, 2015

Erik van Paassen commented

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 11, 2015

Juergen Hoeller commented

Thanks, that's great to hear!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.