Skip to content

GH-1201: Native BatchMessageListener Support #1202

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

Merged
merged 2 commits into from
May 18, 2020

Conversation

garyrussell
Copy link
Contributor

@garyrussell garyrussell commented May 15, 2020

Resolves #1201

Support de-batching producer batches to a List<Meessage> with native
BatchMessageListeners; previously this was only possible with
@RabbitListener which does the debatching itself.

cherry-pick to 2.2.x

Resolves spring-projects#1201

Support de-batching producer batches to a `List<Meessage>` with native
`BatchMessageListener`s; previously this was only possible with
`@RabbitListener` which does the debatching itself.
@artembilan
Copy link
Member

Not sure if related, but posting anyway since it has failed:

RabbitTemplateDirectReplyToContainerIntegrationTests > testReceiveTimeoutRequeue() FAILED

    java.lang.AssertionError at RabbitTemplateIntegrationTests.java:396

@garyrussell
Copy link
Contributor Author

Yeah - looks like a race in that test; rebuilding "solved" it 😄

spring-projects#1202 (comment)

The test has a very short timeout; there is a race such that the channel won't be
physically closed if we don't get the `ConsumeOK` in time.

This won't really cause a problem in a real application, but this change will
prevent the test from sporadically failing.
@artembilan artembilan merged commit 751326e into spring-projects:master May 18, 2020
artembilan pushed a commit that referenced this pull request May 18, 2020
Resolves #1201

Support de-batching producer batches to a `List<Meessage>` with native
`BatchMessageListener`s; previously this was only possible with
`@RabbitListener` which does the debatching itself.

* Fix race in test.

#1202 (comment)

The test has a very short timeout; there is a race such that the channel won't be
physically closed if we don't get the `ConsumeOK` in time.

This won't really cause a problem in a real application, but this change will
prevent the test from sporadically failing.
# Conflicts:
#	src/reference/asciidoc/amqp.adoc
@artembilan
Copy link
Member

... and cherry-picked to 2.2.x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support DeBatching Producer Batches in the DMLC
2 participants