Basic questions about Reactor signals

Question

I have some questions regarding the output of the following code:

Flux.just("a", "b", "c", "d")
        .log(null, Level.INFO, true) // line: 18
        .flatMap(value ->
                Mono.just(value.toUpperCase()).publishOn(Schedulers.elastic()), 2)
        .log(null, Level.INFO, true) // line: 21
        .take(3)
        .log(null, Level.INFO, true) // line: 23
        .subscribe(x -> 
             System.out.println("Thread: " + Thread.currentThread().getName() +
                               " , " + x));

Thread.sleep(1000 * 1000);

Output:

1. 11:29:11 [main] INFO  - | onSubscribe([Synchronous Fuseable] FluxArray.ArraySubscription)    Flux.log(App.java:18)
2. 11:29:11 [main] INFO  - onSubscribe(FluxFlatMap.FlatMapMain)     Flux.log(App.java:21)
3. 11:29:11 [main] INFO  - onSubscribe(FluxTake.TakeSubscriber)     Flux.log(App.java:23)
4. 11:29:11 [main] INFO  - request(unbounded)   Flux.log(App.java:23)
5. 11:29:11 [main] INFO  - request(unbounded)   Flux.log(App.java:21)
6. 11:29:11 [main] INFO  - | request(2)     Flux.log(App.java:18)
7. 11:29:11 [main] INFO  - | onNext(a)  Flux.log(App.java:18)
8. 11:29:11 [main] INFO  - | onNext(b)  Flux.log(App.java:18)
9. 11:29:11 [elastic-2] INFO  - onNext(A)   Flux.log(App.java:21)
10. 11:29:11 [elastic-2] INFO  - onNext(A)  Flux.log(App.java:23)
11. Thread: elastic-2 , A
12. 11:29:11 [elastic-2] INFO  - | request(1)   Flux.log(App.java:18)
13. 11:29:11 [main] INFO  - | onNext(c)     Flux.log(App.java:18)
14. 11:29:11 [elastic-3] INFO  - onNext(B)  Flux.log(App.java:21)
15. 11:29:11 [elastic-3] INFO  - onNext(B)  Flux.log(App.java:23)
16. Thread: elastic-3 , B
17. 11:29:11 [elastic-3] INFO  - | request(1)   Flux.log(App.java:18)
18. 11:29:11 [elastic-3] INFO  - | onNext(d)    Flux.log(App.java:18)
19. 11:29:11 [elastic-3] INFO  - | onComplete()     Flux.log(App.java:18)
20. 11:29:11 [elastic-3] INFO  - onNext(C)  Flux.log(App.java:21)
21. 11:29:11 [elastic-3] INFO  - onNext(C)  Flux.log(App.java:23)
22. Thread: elastic-3 , C
23. 11:29:11 [elastic-3] INFO  - cancel()   Flux.log(App.java:21)
24. 11:29:11 [elastic-3] INFO  - onComplete()   Flux.log(App.java:23)
25. 11:29:11 [elastic-3] INFO  - | cancel()     Flux.log(App.java:18)

Questions: Each question is about a specific line inside the output (not a line in the code). I also added my answers to some of them but I'm not sure I'm correct.

4. When subscribing, the subscribe operation ask for unbounded amount of elements. Then why the event: request(unbounded) is going down in the pipeline instead of going up? My answer: The request for unbounded amount is going up to take and then take sending it down again.

5. flatMap send cancel signal. Why doesn't take sends it instead?

Last question: There is more then one terminal signal in the output. Isn't it a vaulation of reactive-streams spec?

Answer 1

In that case, will be produced ONLY one terminal signal.

Flux.just("a", "b", "c", "d")
            .log(null, Level.INFO, true) // line: 18
            .flatMap(value ->
                    Mono.just(value.toUpperCase()).publishOn(Schedulers.elastic()), 2)
            .log(null, Level.INFO, true) // line: 21
            .take(3)
            .log(null, Level.INFO, true) // line: 23
            .subscribe(x ->
                    System.out.println("Thread: " + Thread.currentThread().getName() +
 " , " + x), t -> {}, () -> System.out.println("Completed ""Only Once"));

The tricky part here is that each Reactor 3 operator has its own life, and they all are playing by the same rule - emit onComplete to notify downstream operator that there is no data anymore.

Since you have .log() operator and three different points thus you will observe three independent onComplete signals from .just , from .flatMap , and from .take(3) .

Firstly, you will see onComplete from .just because the default behavior of .flatMap is 'ok, let's try to request first concurrency elements, and then let's see how it goes', since .just may produce (in your case) only 4 elements, on 2 (which is concurrency level in your example) requested demand it will emit 2 onNext and after two request(1) you will see onComplete . In turn, emitted onComplete lets the .flatMap knows that when 4 flatted streams emit their .onComplete signals, it will be allowed to emit its own onComplete to downstream. In turn, downstream is .take(3) operator which is also after first three elements will emit its own onComplete signal without waiting for upstream onComplete . Since there is .log operator after .take this signal also will be recorded. Finally, in your flow, you have 3 independent log operators, which will record 3 independent onComplete from 3 independent operators, but despite that fact, the final terminal .subscribe will receive only one onComplete from the first operator up to the flow.

Small update regarding .take behavior

The central idea of .take is taking elements until the remaining count has been satisfied. Since the upstream may produce more than was requested we need to have a mechanism to prevent sending more data. One of the mechanisms that Reactive-Streams spec offers to us is collaborations over Subscription . Subscription has two primary methods - request - to show the demand and cancel - to show that data is not needed anymore even if requested demand was not satisfied. In case of .take operator, initial demand is Long.MAX_VALUE , which considers as unbounded demand. Therefore, the only way to stop consuming potentially infinitive stream of data is to cancel subscription, or in other word unsubscribe

Hope it helps you :)