INT-4519: Improve JMS inbound-c-a receiveTimeout #2540
Conversation
| super.setReceiveTimeout(JmsDestinationAccessor.RECEIVE_TIMEOUT_NO_WAIT); | ||
| } | ||
| else { | ||
| super.setReceiveTimeout(1000); |
There was a problem hiding this comment.
Sonar will bark about a "magic" number; should be a constant.
src/reference/asciidoc/jms.adoc
Outdated
| ---- | ||
| ==== | ||
|
|
||
| Starting with version 5.1, a default value of the `receive-timeout` is `-1` (no wait) for the `org.springframework.jms.connection.CachingConnectionFactory` and `cacheConsumers`, otherwise it is 1 second. |
There was a problem hiding this comment.
Conflicts with "cherry-pick" statement in commit comment.
|
Suspicious travis test failure.
|
JIRA: https://jira.spring.io/browse/INT-4519 * Modify `DynamicJmsTemplate` to default for `-1` if we get `CachingConnectionFactory` and it is with `cacheConsumers`, otherwise 1 second * Polishing for some JMS XML parsers, in particular remove `receiveTimeout` population **Cherry-pick to 5.0.x**
|
Hm... Not sure what's going on... |
|
I think it's because the outbound flow uses the non-caching CF, so the The outbound flow (and any template-based endpoints) should use the |
|
So, not related to this PR, but a test bug anyway. |
* INT-4519: Improve JMS inbound-c-a receiveTimeout JIRA: https://jira.spring.io/browse/INT-4519 * Modify `DynamicJmsTemplate` to default for `-1` if we get `CachingConnectionFactory` and it is with `cacheConsumers`, otherwise 1 second * Polishing for some JMS XML parsers, in particular remove `receiveTimeout` population **Cherry-pick to 5.0.x** * * Polishing according PR comments * * Properly use a `CachingConnectionFactory` in `JmsTests`
2 participants
JIRA: https://jira.spring.io/browse/INT-4519
DynamicJmsTemplateto default for-1if we getCachingConnectionFactoryand it is withcacheConsumers, otherwise1 second
receiveTimeoutpopulationCherry-pick to 5.0.x