* GH-1210: Add Kotlin suspend functions support
Fixes https://github.com/spring-projects/spring-amqp/issues/1210
Kotlin Coroutines are essentially `Future` wrapping.
Therefore, it is natural to have `suspend` support on `@RabbitListener`
methods as we do now for `CompletableFuture` and `Mono`
* Introduce some utilities since we cannot reuse existing from Spring Messaging:
they are there about Kotlin Coroutines only for reactive handlers
* Some code clean up in the `RabbitListenerAnnotationBeanPostProcessor`
for the latest Java
* Add optional dep for `kotlinx-coroutines-reactor` and document the feature
* Fix since javadocs to reflect 2.4.x.
Co-authored-by: Artem Bilan <abilan@vmware.com>
Resolves https://github.com/spring-projects/spring-amqp/issues/2482
`forceStop` means stop after the current record and requeue all prefetched.
Just close the channel - canceling the consumer first causes a race condition which
could allow another exclusive or single-active consumer to start processing while
this container is still running.
Also support async stop on DMLC (previously only available on the SMLC).
**cherry-pick to 2.4.x**
# Conflicts:
# spring-rabbit/src/main/java/org/springframework/amqp/rabbit/listener/AbstractMessageListenerContainer.java
# spring-rabbit/src/main/java/org/springframework/amqp/rabbit/listener/DirectMessageListenerContainer.java
Resolves https://github.com/spring-projects/spring-amqp/issues/1533
Allow setting consumer arguments when using non-zero receive
timeouts using the `RabbitTemplate`.
**cherry-pick to 2.4.x**
# Conflicts:
# spring-rabbit/src/main/java/org/springframework/amqp/rabbit/core/RabbitTemplate.java
Resolves https://github.com/spring-projects/spring-amqp/issues/1419
Use Spring WebFlux instead, while allowing the user to choose some other technology
in the `LocalizedQueueConnectionFactory`.
* Rename DefaultNodeLocator; add generics.
* Remove unnecessary dependencies.
GH-1419: Add RestTemplateNodeLocator
- also remove hard dependency on `spring-webflux` from `spring-rabbit-junit`.
Fix Javadoc.
Use RestTemplate for aliveness test; JVM HttpClient not available in Java 8.
Restore spring-rabbit-junit jackson dependency.
Resolves https://github.com/spring-projects/spring-amqp/issues/1473
Given the stability of the project, it was simplest to copy the `AsyncRabbitTemplate`
rather than adding a lot of conditional code.
**2.4.x only; I will submit a separate PR for main**
Resolves https://github.com/spring-projects/spring-amqp/issues/1455
Add an advice chain to the stream listener container and its factory.
Add a `StreamMessageRecoverer` for native stream messages.
Add a retry interceptor to work with native stream messages.
**cherry-pick to 2.4.x**
* Add since to new setter.
Resolves https://github.com/spring-projects/spring-amqp/issues/1420
- detect and use `charset` in `contentType` when present
- allow Jackson to determine the decode `charset` via `ByteSourceJsonBootstrapper.detectEncoding()`
- allow configuration of the `MimeType` to use, which can include a `charset` parameter
**cherry-pick to main - will require what's new fix**
* Fix typo in doc.
Resolves https://github.com/spring-projects/spring-amqp/issues/1422
Broker-named queues did not work with `@RabbitListener` because the BPP
only passed the name of the queue bean, not the bean itself, into the
endpoint.
Support bean injection; fall back to the previous behavior if a mixture
of beans and names are encountered (the containers don't support both
types of configuration).
Add a note to the javadoc to indicate that broker-named queues are not
supported via `queuesToDeclare` and `bindings` properties; such queues
must be declared as discrete beans.
* Docs.
**cherry-pick to `2.4.x` & `2.3.x`**
Resolves https://github.com/spring-projects/spring-amqp/issues/1409
Normally, when message has a fatal exception (such as message conversion)
`basicNack` with `multiple` true is used, to nack any previously unacked
messages (e.g. when using batch size to limit the ack traffic).
Even when using manual acks, fatal exceptions are nacked by the container
because the user does not have access to the message.
However, when using async replies, this has the side effect of nacking
unprocessed messages.
Detect whether async replies are being used and only nack individual
records that cause fatal exceptions.
Also, coerce the `AcknowledgeMode` to `MANUAL` for such listners.
Add a test for both containers; send a good message followed by a
bad one without actually completing the reply future.
After the exception occurs and the container is stopped, there should
be one messag in the queue.
* Remove warning, deprecation; add docs.
* Docs.
**Cherry-pick to `2.3.x` & `2.2.x`**
This commit b945d1cc02
incorrectly added text about reducing the prefetch to 1 when using manual acks.
While changing it to 1 fixed a test case (`testListenerRecoversFromBogusDoubleAck`) it should
not have been a general recommendation since acking the same message twice is not a valid
situation.
**cherry-pick to all supported branches**
- a checkstyle bug prevented detection of javadoc tag ordering
- `allowMissingJavadoc` is no longer available on `JavadocMethod`
(replaced by `MissingJavadocMethod`)
* Add links to alternate documentation formats
Link the HTML to the PDF and vice-versa.
* Update src/reference/asciidoc/index.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
Resolves https://github.com/spring-projects/spring-amqp/issues/1339
Error handler was not called for conversion exceptions, preventing
the application from returning some error to the caller for request/reply processing.
**cherry-pick to 2.2.x**
Resolves https://github.com/spring-projects/spring-amqp/issues/1295
GH-1295: add custom HandlerMethodArgumentResolver
Signed-off-by: Dmitrii Bocharov <bdshadow@gmail.com>
GH-1295: simplify configuration of argument Validator. Add argument validation support for @RabbitHandler methods
Signed-off-by: Dmitrii Bocharov <bdshadow@gmail.com>
Avoid double payload validation in the listener that has no default handler, when a validator is provided
Signed-off-by: Dmitrii Bocharov <bdshadow@gmail.com>
Resolves https://github.com/spring-projects/spring-amqp/issues/1331
Provide a mechanism so that a thread can hand off its channel(s) to another thread.
Add protection to close a channel that would be orphaned if a second channel is transferred
to the thread and the thread failed to close its channel beforehand.
Other improvements:
- only call the channel listener when a channel is actually created
- physically close a transactional channel that is no longer in the thread local because
`closeThreadChannel` was called
- move reset of physical close flag to the actual close
* Suggestions from PR review + other improvements:
- protect against calling 'prepare' when no channels bound
- log warning for unclaimed context switches
- add more tests