Class PublishProcessor<T>

java.lang.Object
io.reactivex.rxjava4.core.Flowable<T>
io.reactivex.rxjava4.processors.FlowableProcessor<T>
io.reactivex.rxjava4.processors.PublishProcessor<T>
Type Parameters:
T - the value type multicasted to Subscribers.
All Implemented Interfaces:
FlowableSubscriber<T>, Flow.Processor<T,T>, Flow.Publisher<T>, Flow.Subscriber<T>
public final class PublishProcessor<@NonNull T> extends FlowableProcessor<T>
Processor that multicasts all subsequently observed items to its current Flow.Subscribers.

This processor does not have a public constructor by design; a new empty instance of this PublishProcessor can be created via the create() method.

Since a PublishProcessor is a Reactive Streams Processor type, nulls are not allowed (Rule 2.13) as parameters to onNext(Object) and onError(Throwable). Such calls will result in a NullPointerException being thrown and the processor's state is not changed.

PublishProcessor is a Flowable as well as a FlowableProcessor, however, it does not coordinate backpressure between different subscribers and between an upstream source and a subscriber. If an upstream item is received via onNext(Object), if a subscriber is not ready to receive an item, that subscriber is terminated via a MissingBackpressureException. To avoid this case, use offer(Object) and retry sometime later if it returned false. The PublishProcessor's Flow.Subscriber-side consumes items in an unbounded manner.

For a multicasting processor type that also coordinates between the downstream Subscribers and the upstream source as well, consider using MulticastProcessor.

When this PublishProcessor is terminated via onError(Throwable) or onComplete(), late Flow.Subscribers only receive the respective terminal event.

Unlike a BehaviorProcessor, a PublishProcessor doesn't retain/cache items, therefore, a new Subscriber won't receive any past items.

Even though PublishProcessor implements the Flow.Subscriber interface, calling onSubscribe is not required (Rule 2.12) if the processor is used as a standalone source. However, calling onSubscribe after the PublishProcessor reached its terminal state will result in the given Flow.Subscription being canceled immediately.

Calling onNext(Object), offer(Object), onError(Throwable) and onComplete() is required to be serialized (called from the same thread or called non-overlappingly from different threads through external means of serialization). The FlowableProcessor.toSerialized() method available to all FlowableProcessors provides such serialization and also protects against reentrance (i.e., when a downstream Subscriber consuming this processor also wants to call onNext(Object) on this processor recursively). Note that serializing over offer(Object) is not supported through toSerialized() because it is a method available on the PublishProcessor and BehaviorProcessor classes only.

This PublishProcessor supports the standard state-peeking methods hasComplete(), hasThrowable(), getThrowable() and hasSubscribers().

Backpressure:
The processor does not coordinate backpressure for its subscribers and implements a weaker onSubscribe which calls requests Long.MAX_VALUE from the incoming Subscriptions. This makes it possible to subscribe the PublishProcessor to multiple sources (note on serialization though) unlike the standard Subscriber contract. Child subscribers, however, are not overflown but receive an IllegalStateException in case their requested amount is zero.
Scheduler:
PublishProcessor does not operate by default on a particular Scheduler and the Subscribers get notified on the thread the respective onXXX methods were invoked.
Error handling:
When the onError(Throwable) is called, the PublishProcessor enters into a terminal state and emits the same Throwable instance to the last set of Subscribers. During this emission, if one or more Subscribers cancel their respective Subscriptions, the Throwable is delivered to the global error handler via RxJavaPlugins.onError(Throwable) (multiple times if multiple Subscribers cancel at once). If there were no Subscribers subscribed to this PublishProcessor when the onError() was called, the global error handler is not invoked.
Example usage: 

 PublishProcessor<Object> processor = PublishProcessor.create();
 // subscriber1 will receive all onNext and onComplete events
 processor.subscribe(subscriber1);
 processor.onNext("one");
 processor.onNext("two");
 // subscriber2 will only receive "three" and onComplete
 processor.subscribe(subscriber2);
 processor.onNext("three");
 processor.onComplete();
See Also: