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

Support non-blocking receiveTimeout in AbstractPollingMessageListenerContainer [SPR-14212] #18786

Closed
spring-issuemaster opened this issue Apr 24, 2016 · 1 comment
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Apr 24, 2016

Erik Wramner opened SPR-14212 and commented

AbstractPollingMessageListenerContainer#receiveMessage currently blocks indefinitely both on negative values and 0 as receiveTimeout. The documentation for receiveTimeout mentions -1, but not 0. However, MessageConsumer#receive blocks if the timeout is 0 and AbstractPollingMessageListenerContainer uses receive() or receive(timeout) - never receiveNoWait().

In some cases, for example with Oracle AQ, receiveNoWait yields better performance.

It is very simple to fix this. Simply check for 0 and call receiveNoWait. I will create a pull request.


Reference URL: #1043

Issue Links:

  • #18799 Client-side polling delay as alternative for receive timeout for JMS

Referenced from: commits 87b93a7

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Apr 26, 2016

Juergen Hoeller commented

This is actual an unintended inconsistency: As with JmsTemplate, aligning with the JMS spec, 0 should indicate an indefinite wait attempt (even if it can be argued as no-wait, the definition of the JMS spec receive method is the more important guideline), whereas negative values such as -1 are to be treated as no-wait (since they have no other semantics in the JMS spec).

Additionally, an indefinite wait is a particularly bad idea with a DefaultMessageListenerContainer since it cannot cleanly shut down in such a scenario.

So as of 4.3, I've reworded our setReceiveTimeout javadoc to consistently declare -1 for no-wait and leave 0 for indefinitive wait. I doubt that anyone ever specified -1 there, and if they (unintentionally) did, they are arguably better off with no-wait behavior by default.

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