Reactor processors---Response Spring's Word Wizard

This series of articles index the "Response Spring's word Wizard"
Previously feed-response Flow | Reactor 3 Quick Start | Responsive Flow Specification

2.9 Processor

Processoris both a special publisher ( Publisher ) and a Subscriber ( Subscriber ). So you can subscribe to one Processor or call the methods they provide to manually insert the data into the sequence, or terminate the sequence.

The front has been talking about three of the four interfaces of the responsive stream:,, Publisher Subscriber Subscription , but the Processor delay did not mention. The reason is that it's not easy to use them well, and in most cases we should avoid them Processor , usually for special scenarios.

2.9.1 using Sink to thread safely to generate a stream

Rather than using processor directly, the better way is sink() to get its sink by calling. This sink is thread-safe and can be used to generate data in multiple threads and concurrently in the application. For example, by UnicastProcessor getting a thread-safe sink:

    UnicastProcessor<Integer> processor = UnicastProcessor.create();    FluxSink<Integer> sink = processor.sink(overflowStrategy);

Multiple threads can generate data to sink concurrently by using the method below.

    sink.next(n);

See if this feels generate like the way you generate data streams? So reactor official suggests that when you want to use processor, first look to see if you can do the generate same thing, or see if there's a corresponding operator to get the results you want .

2.9.2 Reactor built-in Processor

Reactor Core has multiple Processor built in. These processor have different syntaxes and are roughly divided into three categories.

• directly(direct) (Directprocessor and Unicastprocessor): These processors can only push data by invoking the Sink method directly.
• Synchronous (synchronous)(Emitterprocessor and Replayprocessor): These processors can either invoke the Sink method directly to push the data, You can also generate data synchronously by subscribing to an upstream publisher.
• Asynchronous (asynchronous)(Workqueueprocessor and Topicprocessor): These processors can push data from multiple upstream publishers. It is more robust because RINGBUFFER data structures are used to cache multiple datasets from upstream.

Asynchronous processor are most complex when instantiated, because there are many different options. So they expose a Builder interface. The simple processors has a static factory approach.

1) directprocessor

DirectProcessorSignals can be distributed to 0 or more Subscribers (subscriber). It is the easiest to instantiate, using the static method of Create (). On the other hand, its insufficiency is unable to handle back pressure. So, when a DirectProcessor push is n elements, and at least one subscriber has fewer than n requests, it emits one IllegalStateException .

Once Processor ends (usually by calling its Sink's error (Throwable) or the complete () method), it allows more subscribers to subscribe to it, but immediately sends the terminating signal back to them.

2) Unicastprocessor

UnicastProcessorYou can use a built-in cache to handle back pressure. The price is that it can only have one subscriber at most (the example from the previous section is publish converted ConnectableFlux to two subscribers).

UnicastProcessorThere are several options, so there are several different create static methods available. For example, it defaults to infinity (unbounded): If you let it push data without the subscriber requesting it, it caches all the data.

You can change the default behavior by providing a specific implementation of a custom Queue that is passed to the Create factory method. If the given queue is limited (bounded), and the cache is full and no downstream requests are received, processor rejects the push data.

In the "limited" example above, you can also provide a callback method when constructing processor, which can be invoked on every element that is rejected, giving developers the opportunity to clean up the elements.

3) Emitterprocessor

EmitterProcessorAbility to send data to multiple subscribers and back-pressure processing for each subscriber. It can also subscribe to a publisher and get data synchronously.

Initially, if there is no subscriber, it still allows to push some data to the cache, which is defined by the cache size bufferSize . Then, if there is still no subscriber subscribing to it and consuming data, the onNext call is blocked until there is a subscriber access (which can only be subscribed to concurrently).

So the first subscriber receives the most bufferSize elements. Subsequently, however, subscribers to subsequent accesses can only obtain data that is pushed after they start subscribing. This internal cache will continue to be used for back-pressure purposes.

By default, if all Subscribers cancel the subscription, it empties the internal cache and no longer accepts more subscribers. This can be configured by the Autocancel parameter of the Create static factory method.

4) Replayprocessor

ReplayProcessorElements that are pushed directly through their own Sink, as well as elements from the upstream publisher, are cached, and later subscribers receive the re-send (replay) elements.

It can be created in a variety of configurations:

• Caches an element (Cachelast).
• Caches a certain number of historical elements (create (int)), all historical elements (create ()).
• The cache is based on elements within the time window period (createtimeout (Duration)).
• Caches elements based on the history number and time window (createsizeortimeout (int, Duration)).

5) Topicprocessor

TopicProcessoris an asynchronous processor that can re-send elements from multiple upstream publishers, which needs to be configured shared (build () Share (Boolean) configuration when it is created).

If you attempt to invoke, or method in a concurrent environment, by a concurrent upstream publisher, you TopicProcessor onNext onComplete onError must configure it shared . Otherwise, concurrent calls are illegal, so processor is fully compliant with the responsive flow specification.

TopicProcessorAbility to send data to multiple subscribers. It does this by associating a thread with each subscriber, which is executed until the processor onError is issued or onComplete signaled, or the associated subscriber is canceled. The maximum number of subscribers that can be accepted is specified by the constructor method executor , ExecutorService which restricts this by providing a finite number of threads.

This processor is based on a data RingBuffer structure to store the sent information. Each Subscriber thread manages the index of its associated data in its own RingBuffer .

This processor also has a autoCancel constructor method: If set to true (default), then when all Subscribers are canceled, the upstream publisher is canceled.

6) Workqueueprocessor

WorkQueueProcessorIt is also an asynchronous processor, and the ability to re-send elements from multiple upstream publishers is also required to be configured at the time of Creation shared (it has the same configuration as most constructors TopicProcessor ).

It relaxes the compatibility of the response flow specification, but the benefit is that TopicProcessor fewer resources are needed relative to it. It is still based RingBuffer , but it is no longer required for each subscriber to associate a thread, so it is more extensible than it is TopicProcessor .

The tradeoff is that the distribution pattern is a bit different: Requests from Subscribers are aggregated, and the processor sends data to only one subscriber at a time, so it needs to loop (Round-robin) send data to subscribers instead of all-in-one mode (no guaranteed full fair loop distribution).

WorkQueueProcessorMost constructor methods are the same as, for TopicProcessor example, autoCancel share , and waitStrategy . The maximum number of downstream subscribers is also determined by the constructor executor configuration ExecutorService .

Note: It is best not to have too many subscribers WorkQueueProcessor , as this will lock processor. If you need to limit the number of subscribers, it's best to use one ThreadPoolExecutor or ForkJoinPool . This processor can detect (thread pool) capacity and throw exceptions when subscribers are too large.

The introduction of this article does not give an example, in the next chapter we write "Reactive Netty" when we introduce the use of processor.

Reactor processors---Response Spring's Word Wizard