From e95acd8a2997dafcdbeff44b39308e053956f89f Mon Sep 17 00:00:00 2001 From: Oleg Zhurakousky Date: Mon, 8 Feb 2021 16:24:13 +0100 Subject: [PATCH] GH-2103 - Added documentation to clarify threading expectation when using Supplier Resolves #2103 --- docs/src/main/asciidoc/spring-cloud-stream.adoc | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/src/main/asciidoc/spring-cloud-stream.adoc b/docs/src/main/asciidoc/spring-cloud-stream.adoc index 4cf41e3a9..1ae26a265 100644 --- a/docs/src/main/asciidoc/spring-cloud-stream.adoc +++ b/docs/src/main/asciidoc/spring-cloud-stream.adoc @@ -517,6 +517,16 @@ the framework will split the returning sending out each item as an individual me he desired behavior you can set it to `false` at which point such supplier will simply return the produced Flux without splitting it. +====== Supplier & threading + +NOTE: As you have learned by now, unlike `Function` and `Consumer`, which are triggered by an event (they have input data), `Supplier` does not have +any input and thus triggered by a different mechanism - _poller_, which may have an unpredictable threading mechanism. And while the details of the +threading mechanism most of the time are not relevant to the downstream execution of the function it may present an issue in certain cases +especially with integrated frameworks that may have certain expectations to thread affinity. For example, https://spring.io/projects/spring-cloud-sleuth[Spring Cloud Sleuth] which relies +on tracing data stored in thread local. +For those cases we have another mechanism via `StreamBridge`, where user has more control over threading mechanism. You can get more details +in <> section. + ===== Consumer (Reactive) Reactive `Consumer` is a little bit special because it has a void return type, leaving framework with no reference to subscribe to.