Reactor Core 3.6.0 · reactor.core.publisher.InternalManySink

Modifier and Type	Method and Description
public default void	emitComplete(Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. failureHandler) Implements reactor.core.publisher.Sinks.Many.emitComplete. A simplified attempt at completing via the `tryEmitComplete()` API, generating an `onComplete` signal.
public default void	emitError(Throwable the exception to signal, not null error, Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. failureHandler) Implements reactor.core.publisher.Sinks.Many.emitError. A simplified attempt at failing the sequence via the `tryEmitError(Throwable)` API, generating an `onError` signal.
public default void	emitNext(T the value to emit, not null value, Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. failureHandler) Implements reactor.core.publisher.Sinks.Many.emitNext. A simplified attempt at emitting a non-null element via the `tryEmitNext(Object)` API, generating an `onNext` signal.

Method Detail

emitComplete back to summary

emitComplete	back to summary
public default void emitComplete(Sinks.EmitFailureHandler failureHandler) Implements reactor.core.publisher.Sinks.Many.emitComplete. Doc from reactor.core.publisher.Sinks.Many.emitComplete. A simplified attempt at completing via the `tryEmitComplete()` API, generating an `onComplete` signal. If the result of the attempt is not a `success`, implementations SHOULD retry the `tryEmitComplete()` call IF the provided `EmitFailureHandler` returns `true`. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior). Generally, `tryEmitComplete()` is preferable since it allows a custom handling of error cases, although this implies checking the returned `EmitResult` and correctly acting on it. This API is intended as a good default for convenience. When the `EmitResult` is not a success, vanilla reactor-core operators have the following behavior: `EmitResult#FAIL_OVERFLOW`: irrelevant as onComplete is not driven by backpressure. `EmitResult#FAIL_ZERO_SUBSCRIBER`: the completion can be ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onComplete, replaying the terminal signal to later subscribers instead (to the exception of `UnicastSpec#onBackpressureError()`). `EmitResult#FAIL_CANCELLED`: the completion can be ignored since nobody is interested. `EmitResult#FAIL_TERMINATED`: the extra completion is basically ignored since there was a previous termination signal, but there is nothing interesting to log. `EmitResult#FAIL_NON_SERIALIZED`: throw an `EmissionException` mentioning RS spec rule 1.3. Note that `Sinks#unsafe()` never trigger this result. It would be possible for an `EmitFailureHandler` to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks... Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a `EmitResult#FAIL_NON_SERIALIZED` as described above, ...). Parameters failureHandler:Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. Annotations @Override

public default void emitComplete(Sinks.EmitFailureHandler failureHandler)

Implements reactor.core.publisher.Sinks.Many.emitComplete.

Doc from reactor.core.publisher.Sinks.Many.emitComplete.

A simplified attempt at completing via the tryEmitComplete() API, generating an onComplete signal. If the result of the attempt is not a success, implementations SHOULD retry the tryEmitComplete() call IF the provided EmitFailureHandler returns true. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior).

Generally, tryEmitComplete() is preferable since it allows a custom handling of error cases, although this implies checking the returned EmitResult and correctly acting on it. This API is intended as a good default for convenience.

When the EmitResult is not a success, vanilla reactor-core operators have the following behavior:

EmitResult#FAIL_OVERFLOW: irrelevant as onComplete is not driven by backpressure.
EmitResult#FAIL_ZERO_SUBSCRIBER: the completion can be ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onComplete, replaying the terminal signal to later subscribers instead (to the exception of UnicastSpec#onBackpressureError()).
EmitResult#FAIL_CANCELLED: the completion can be ignored since nobody is interested.
EmitResult#FAIL_TERMINATED: the extra completion is basically ignored since there was a previous termination signal, but there is nothing interesting to log.
EmitResult#FAIL_NON_SERIALIZED: throw an EmissionException mentioning RS spec rule 1.3. Note that Sinks#unsafe() never trigger this result. It would be possible for an EmitFailureHandler to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks...

Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a EmitResult#FAIL_NON_SERIALIZED as described above, ...).

Parameters

failureHandler:Sinks.EmitFailureHandler: the failure handler that allows retrying failed EmitResult.

Annotations

@Override

emitError back to summary

emitError	back to summary
public default void emitError(Throwable error, Sinks.EmitFailureHandler failureHandler) Implements reactor.core.publisher.Sinks.Many.emitError. Doc from reactor.core.publisher.Sinks.Many.emitError. A simplified attempt at failing the sequence via the `tryEmitError(Throwable)` API, generating an `onError` signal. If the result of the attempt is not a `success`, implementations SHOULD retry the `tryEmitError(Throwable)` call IF the provided `EmitFailureHandler` returns `true`. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior). Generally, `tryEmitError(Throwable)` is preferable since it allows a custom handling of error cases, although this implies checking the returned `EmitResult` and correctly acting on it. This API is intended as a good default for convenience. When the `EmitResult` is not a success, vanilla reactor-core operators have the following behavior: `EmitResult#FAIL_OVERFLOW`: irrelevant as onError is not driven by backpressure. `EmitResult#FAIL_ZERO_SUBSCRIBER`: the error is ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onError, replaying the terminal signal to later subscribers instead (to the exception of `UnicastSpec#onBackpressureError()`). `EmitResult#FAIL_CANCELLED`: the error can be ignored since nobody is interested. `EmitResult#FAIL_TERMINATED`: the error unexpectedly follows another terminal signal, so it is dropped via `Operators#onErrorDropped(Throwable, Context)`. `EmitResult#FAIL_NON_SERIALIZED`: throw an `EmissionException` mentioning RS spec rule 1.3. Note that `Sinks#unsafe()` never trigger this result. It would be possible for an `EmitFailureHandler` to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks... Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a `EmitResult#FAIL_NON_SERIALIZED` as described above, ...). Parameters error:Throwable the exception to signal, not null failureHandler:Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. Annotations @Override

public default void emitError(Throwable error, Sinks.EmitFailureHandler failureHandler)

Implements reactor.core.publisher.Sinks.Many.emitError.

Doc from reactor.core.publisher.Sinks.Many.emitError.

A simplified attempt at failing the sequence via the tryEmitError(Throwable) API, generating an onError signal. If the result of the attempt is not a success, implementations SHOULD retry the tryEmitError(Throwable) call IF the provided EmitFailureHandler returns true. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior).

Generally, tryEmitError(Throwable) is preferable since it allows a custom handling of error cases, although this implies checking the returned EmitResult and correctly acting on it. This API is intended as a good default for convenience.

When the EmitResult is not a success, vanilla reactor-core operators have the following behavior:

EmitResult#FAIL_OVERFLOW: irrelevant as onError is not driven by backpressure.
EmitResult#FAIL_ZERO_SUBSCRIBER: the error is ignored since nobody is listening. Note that most vanilla reactor sinks never trigger this result for onError, replaying the terminal signal to later subscribers instead (to the exception of UnicastSpec#onBackpressureError()).
EmitResult#FAIL_CANCELLED: the error can be ignored since nobody is interested.
EmitResult#FAIL_TERMINATED: the error unexpectedly follows another terminal signal, so it is dropped via Operators#onErrorDropped(Throwable, Context).
EmitResult#FAIL_NON_SERIALIZED: throw an EmissionException mentioning RS spec rule 1.3. Note that Sinks#unsafe() never trigger this result. It would be possible for an EmitFailureHandler to busy-loop and optimistically wait for the contention to disappear to avoid this case in safe sinks...

Parameters

error:Throwable: the exception to signal, not null
failureHandler:Sinks.EmitFailureHandler: the failure handler that allows retrying failed EmitResult.

Annotations

@Override

emitNext back to summary

emitNext	back to summary
public default void emitNext(T value, Sinks.EmitFailureHandler failureHandler) Implements reactor.core.publisher.Sinks.Many.emitNext. Doc from reactor.core.publisher.Sinks.Many.emitNext. A simplified attempt at emitting a non-null element via the `tryEmitNext(Object)` API, generating an `onNext` signal. If the result of the attempt is not a `success`, implementations SHOULD retry the `tryEmitNext(Object)` call IF the provided `EmitFailureHandler` returns `true`. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior). Generally, `tryEmitNext(Object)` is preferable since it allows a custom handling of error cases, although this implies checking the returned `EmitResult` and correctly acting on it. This API is intended as a good default for convenience. When the `EmitResult` is not a success, vanilla reactor-core operators have the following behavior: `EmitResult#FAIL_ZERO_SUBSCRIBER`: no particular handling. should ideally discard the value but at that point there's no `Subscriber` from which to get a contextual discard handler. `EmitResult#FAIL_OVERFLOW`: discard the value (`Operators#onDiscard(Object, Context)`) then call `emitError(Throwable, Sinks.EmitFailureHandler)` with a `Exceptions#failWithOverflow(String)` exception. `EmitResult#FAIL_CANCELLED`: discard the value (`Operators#onDiscard(Object, Context)`). `EmitResult#FAIL_TERMINATED`: drop the value (`Operators#onNextDropped(Object, Context)`). `EmitResult#FAIL_NON_SERIALIZED`: throw an `EmissionException` mentioning RS spec rule 1.3. Note that `Sinks#unsafe()` never trigger this result. It would be possible for an `EmitFailureHandler` to busy-loop and optimistically wait for the contention to disappear to avoid this case for safe sinks... Might throw an unchecked exception as a last resort (eg. in case of a fatal error downstream which cannot be propagated to any asynchronous handler, a bubbling exception, a `EmitResult#FAIL_NON_SERIALIZED` as described above, ...). Parameters value:T the value to emit, not null failureHandler:Sinks.EmitFailureHandler the failure handler that allows retrying failed `EmitResult`. Annotations @Override

public default void emitNext(T value, Sinks.EmitFailureHandler failureHandler)

Implements reactor.core.publisher.Sinks.Many.emitNext.

Doc from reactor.core.publisher.Sinks.Many.emitNext.

A simplified attempt at emitting a non-null element via the tryEmitNext(Object) API, generating an onNext signal. If the result of the attempt is not a success, implementations SHOULD retry the tryEmitNext(Object) call IF the provided EmitFailureHandler returns true. Otherwise, failures are dealt with in a predefined way that might depend on the actual sink implementation (see below for the vanilla reactor-core behavior).

Generally, tryEmitNext(Object) is preferable since it allows a custom handling of error cases, although this implies checking the returned EmitResult and correctly acting on it. This API is intended as a good default for convenience.

When the EmitResult is not a success, vanilla reactor-core operators have the following behavior:

EmitResult#FAIL_ZERO_SUBSCRIBER: no particular handling. should ideally discard the value but at that point there's no Subscriber from which to get a contextual discard handler.
EmitResult#FAIL_OVERFLOW: discard the value (Operators#onDiscard(Object, Context)) then call emitError(Throwable, Sinks.EmitFailureHandler) with a Exceptions#failWithOverflow(String) exception.
EmitResult#FAIL_CANCELLED: discard the value (Operators#onDiscard(Object, Context)).
EmitResult#FAIL_TERMINATED: drop the value (Operators#onNextDropped(Object, Context)).
EmitResult#FAIL_NON_SERIALIZED: throw an EmissionException mentioning RS spec rule 1.3. Note that Sinks#unsafe() never trigger this result. It would be possible for an EmitFailureHandler to busy-loop and optimistically wait for the contention to disappear to avoid this case for safe sinks...

Parameters

value:T: the value to emit, not null
failureHandler:Sinks.EmitFailureHandler: the failure handler that allows retrying failed EmitResult.

Annotations

@Override

pack-priv Interface InternalManySink<T>

Method Summary

Method Detail