T - a generic type for the Mono view, allowing compositionpublic static interface Sinks.Empty<T> extends Scannable
Sinks with complete-or-fail semantics.
The sink can be exposed to consuming code as a Mono via its asMono() view.
Scannable.Attr<T>OPERATOR_NAME_UNRELATED_WORDS_PATTERN| 限定符和类型 | 方法和说明 |
|---|---|
Mono<T> |
asMono()
Return a
Mono view of this sink. |
int |
currentSubscriberCount()
Get how many
Subscribers are currently subscribed to the sink. |
void |
emitEmpty(Sinks.EmitFailureHandler failureHandler)
A simplified attempt at completing via the
tryEmitEmpty() API, generating an
onComplete signal. |
void |
emitError(java.lang.Throwable error,
Sinks.EmitFailureHandler failureHandler)
A simplified attempt at failing the sequence via the
tryEmitError(Throwable) API, generating an
onError signal. |
Sinks.EmitResult |
tryEmitEmpty()
Try to complete the
Mono without a value, generating only an onComplete signal. |
Sinks.EmitResult |
tryEmitError(java.lang.Throwable error)
Try to fail the
Mono, generating only an onError signal. |
actuals, from, inners, isScanAvailable, name, parents, scan, scanOrDefault, scanUnsafe, stepName, steps, tags, tagsDeduplicatedSinks.EmitResult tryEmitEmpty()
Mono without a value, generating only an onComplete signal.
The result of the attempt is represented as an Sinks.EmitResult, which possibly indicates error cases.
See the list of failure Sinks.EmitResult in #emitEmpty(EmitFailureHandler) javadoc for an
example of how each of these can be dealt with, to decide if the emit API would be a good enough fit instead.
Sinks.EmitResult, which should be checked to distinguish different possible failuresemitEmpty(Sinks.EmitFailureHandler),
Subscriber.onComplete()Sinks.EmitResult tryEmitError(java.lang.Throwable error)
Mono, generating only an onError signal.
The result of the attempt is represented as an Sinks.EmitResult, which possibly indicates error cases.
See the list of failure Sinks.EmitResult in #emitError(Throwable, EmitFailureHandler) javadoc for an
example of how each of these can be dealt with, to decide if the emit API would be a good enough fit instead.
error - the exception to signal, not nullSinks.EmitResult, which should be checked to distinguish different possible failuresemitError(Throwable, Sinks.EmitFailureHandler),
Subscriber.onError(Throwable)void emitEmpty(Sinks.EmitFailureHandler failureHandler)
tryEmitEmpty() API, generating an
onComplete signal.
If the result of the attempt is not a success, implementations SHOULD retry the
tryEmitEmpty() call IF the provided Sinks.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, tryEmitEmpty() is preferable since it allows a custom handling
of error cases, although this implies checking the returned Sinks.EmitResult and correctly
acting on it. This API is intended as a good default for convenience.
When the Sinks.EmitResult is not a success, vanilla reactor-core operators have the following behavior:
Sinks.EmitResult.FAIL_OVERFLOW: irrelevant as onComplete is not driven by backpressure.
Sinks.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 Sinks.UnicastSpec.onBackpressureError()).
Sinks.EmitResult.FAIL_CANCELLED: the completion can be ignored since nobody is interested.
Sinks.EmitResult.FAIL_TERMINATED: the extra completion is basically ignored since there was a previous
termination signal, but there is nothing interesting to log.
Sinks.EmitResult.FAIL_NON_SERIALIZED: throw an Sinks.EmissionException mentioning RS spec rule 1.3.
Note that Sinks.unsafe() never trigger this result. It would be possible for an Sinks.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 Sinks.EmitResult.FAIL_NON_SERIALIZED
as described above, ...).
failureHandler - the failure handler that allows retrying failed Sinks.EmitResult.Sinks.EmissionException - on non-serialized accesstryEmitEmpty(),
Subscriber.onComplete()void emitError(java.lang.Throwable error,
Sinks.EmitFailureHandler failureHandler)
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 Sinks.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 Sinks.EmitResult and correctly
acting on it. This API is intended as a good default for convenience.
When the Sinks.EmitResult is not a success, vanilla reactor-core operators have the following behavior:
Sinks.EmitResult.FAIL_OVERFLOW: irrelevant as onError is not driven by backpressure.
Sinks.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 Sinks.UnicastSpec.onBackpressureError()).
Sinks.EmitResult.FAIL_CANCELLED: the error can be ignored since nobody is interested.
Sinks.EmitResult.FAIL_TERMINATED: the error unexpectedly follows another terminal signal, so it is
dropped via Operators.onErrorDropped(Throwable, Context).
Sinks.EmitResult.FAIL_NON_SERIALIZED: throw an Sinks.EmissionException mentioning RS spec rule 1.3.
Note that Sinks.unsafe() never trigger this result. It would be possible for an Sinks.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 Sinks.EmitResult.FAIL_NON_SERIALIZED
as described above, ...).
error - the exception to signal, not nullfailureHandler - the failure handler that allows retrying failed Sinks.EmitResult.Sinks.EmissionException - on non-serialized accesstryEmitError(Throwable),
Subscriber.onError(Throwable)int currentSubscriberCount()
Subscribers are currently subscribed to the sink.
This is a best effort peek at the sink state, and a subsequent attempt at emitting
to the sink might still return Sinks.EmitResult.FAIL_ZERO_SUBSCRIBER where relevant.
Request (and lack thereof) isn't taken into account, all registered subscribers are counted.