As you can see from the table above Supplier can be reactive - Supplier<Flux<T>>
+or imperative - Supplier<T>. From the invocation standpoint this should make no difference
+to the implementor of such Supplier. However, when used within frameworks
+(e.g., Spring Cloud Stream), Suppliers, especially reactive,
+often used to represent the source of the stream, therefore they are invoked once to get the stream (e.g., Flux)
+to which consumers can subscribe to. In other words such suppliers represent an equivalent of an infinite stream.
+However, the same reactive suppliers can also represent finite stream(s) (e.g., result set on the polled JDBC data).
+In those cases such reactive suppliers must be hooked up to some polling mechanism of the underlying framework.
To assist with that Spring Cloud Function provides a marker annotation
+org.springframework.cloud.function.context.PollableSupplier to signal that such supplier produces a
+finite stream and may need to be polled again. That said, it is important to understand that Spring Cloud Function itself
+provides no behavior for this annotation.
In addition PollableSupplier annotation exposes a splittable attribute to signal that produced stream
+needs to be split (see Splitter EIP)
Here is the example:
+@PollableSupplier(splittable = true)
+public Supplier<Flux<String>> someSupplier() {
+ return () -> {
+ String v1 = String.valueOf(System.nanoTime());
+ String v2 = String.valueOf(System.nanoTime());
+ String v3 = String.valueOf(System.nanoTime());
+ return Flux.just(v1, v2, v3);
+ };
+}TBD
+Consumer is a little bit special because it has a void return type,
which implies blocking, at least potentially. Most likely you will not
@@ -424,6 +471,7 @@ function that returns a publisher, so that it can be subscribed to in
a controlled way.