| Class and Description |
|---|
| reactor.core.publisher.DirectProcessor
To be removed in 3.5, prefer clear cut usage of
Sinks. Closest sink
is Sinks.many().multicast().directBestEffort(),
except it doesn't terminate overflowing downstreams. |
| reactor.core.publisher.EmitterProcessor
To be removed in 3.5. Prefer clear cut usage of
Sinks through
variations of Sinks.many().multicast().onBackpressureBuffer().
If you really need the subscribe-to-upstream functionality of a Processor, switch
to Sinks.ManyWithUpstream with Sinks.unsafe() variants of Sinks.unsafe().manyWithUpstream().
This processor was blocking in EmitterProcessor.onNext(Object). This behaviour can be implemented with the Sinks API by calling
Sinks.Many.tryEmitNext(Object) and retrying, e.g.:
|
| reactor.core.publisher.FluxProcessor
Processors will be removed in 3.5. Prefer using
Sinks.Many instead,
or see https://github.com/reactor/reactor-core/issues/2431 for alternatives |
| reactor.util.Metrics
prefer using the new reactor-core-micrometer module Micrometer entrypoint. To be removed in 3.6.0 at the earliest.
|
| reactor.util.Metrics.MicrometerConfiguration
Prefer using the reactor-core-micrometer module and configuring it using the Micrometer entrypoint.
|
| reactor.core.publisher.MonoProcessor
Processors will be removed in 3.5. Prefer using
Sinks.One or Sinks.Empty instead,
or see https://github.com/reactor/reactor-core/issues/2431 for alternatives |
| reactor.core.publisher.ReplayProcessor
To be removed in 3.5, prefer clear cut usage of
Sinks through
variations under Sinks.many().replay(). |
| reactor.core.publisher.UnicastProcessor
to be removed in 3.5, prefer clear cut usage of
Sinks through
variations under Sinks.many().unicast(). |
| Method and Description |
|---|
| reactor.core.publisher.Hooks.addCallSiteInfo(P, String)
Should only be used by the instrumentation, DOES NOT guarantee any compatibility
|
| reactor.core.publisher.Hooks.addReturnInfo(P, String)
Should only be used by the instrumentation, DOES NOT guarantee any compatibility
|
| reactor.core.publisher.ReplayProcessor.cacheLast()
use
Sinks.many().replay().latest()
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.cacheLastOrDefault(T)
use
Sinks.many().replay().latestOrDefault(value)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.MonoProcessor.cancel()
the
MonoProcessor will cease to implement Subscription in 3.5 |
| reactor.core.publisher.UnicastProcessor.create()
use
Sinks.many().unicast().onBackpressureBuffer()
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.create()
use
Sinks.many().replay().all()
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.EmitterProcessor.create()
use
Sinks.many().multicast().onBackpressureBuffer()
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.DirectProcessor.create()
To be removed in 3.5. Closest sink is
Sinks.many().multicast().directBestEffort(),
except it doesn't terminate overflowing downstreams. |
| reactor.core.publisher.MonoProcessor.create()
Use
Sinks.one(), to be removed in 3.5 |
| reactor.core.publisher.EmitterProcessor.create(boolean)
use
Sinks.many().multicast().onBackpressureBuffer(bufferSize, boolean)
using the old default of Queues.SMALL_BUFFER_SIZE for the bufferSize
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.create(int)
use
Sinks.many().replay().limit(historySize)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.EmitterProcessor.create(int)
use
Sinks.many().multicast().onBackpressureBuffer(bufferSize)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.create(int, boolean)
use
Sinks.many().replay().limit(historySize)
for bounded cases (unbounded == false) or Sinks.many().replay().all(bufferSize)
otherwise (or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.EmitterProcessor.create(int, boolean)
use
Sinks.many().multicast().onBackpressureBuffer(bufferSize, autoCancel)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.UnicastProcessor.create(Queue<E>)
use
Sinks.many().unicast().onBackpressureBuffer(queue)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.UnicastProcessor.create(Queue<E>, Consumer<? super E>, Disposable)
use
Sinks.many().unicast().onBackpressureBuffer(queue, endCallback)
(or the unsafe variant if you're sure about external synchronization). The onOverflow callback is not
supported anymore. To be removed in 3.5. |
| reactor.core.publisher.UnicastProcessor.create(Queue<E>, Disposable)
use
Sinks.many().unicast().onBackpressureBuffer(queue, endCallback)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.createSizeAndTimeout(int, Duration)
use
Sinks.many().replay().limit(size, maxAge)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.createSizeAndTimeout(int, Duration, Scheduler)
use
Sinks.many().replay().limit(size, maxAge, scheduler)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.createTimeout(Duration)
use
Sinks.many().replay().limit(maxAge)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.ReplayProcessor.createTimeout(Duration, Scheduler)
use
Sinks.many().replay().limit(maxAge, scheduler)
(or the unsafe variant if you're sure about external synchronization). To be removed in 3.5. |
| reactor.core.publisher.MonoSink.currentContext()
To be removed in 3.6.0 at the earliest. Prefer using #contextView() instead.
|
| reactor.core.publisher.FluxSink.currentContext()
To be removed in 3.6.0 at the earliest. Prefer using #contextView() instead.
|
| reactor.core.publisher.SynchronousSink.currentContext()
To be removed in 3.6.0 at the earliest. Prefer using #contextView() instead.
|
| reactor.core.scheduler.Schedulers.disableMetrics()
prefer using Micrometer#timedScheduler from the reactor-core-micrometer module. To be removed at the earliest in 3.6.0.
|
| reactor.core.scheduler.Schedulers.enableMetrics()
prefer using Micrometer#timedScheduler from the reactor-core-micrometer module. To be removed at the earliest in 3.6.0.
|
| reactor.core.publisher.Mono.first(Iterable<? extends Mono<? extends T>>)
use
Mono.firstWithSignal(Iterable). To be removed in reactor 3.5. |
| reactor.core.publisher.Flux.first(Iterable<? extends Publisher<? extends I>>)
use
Flux.firstWithSignal(Iterable). To be removed in reactor 3.5. |
| reactor.core.publisher.Mono.first(Mono<? extends T>...)
use
Mono.firstWithSignal(Mono[]). To be removed in reactor 3.5. |
| reactor.core.publisher.Flux.first(Publisher<? extends I>...)
use
Flux.firstWithSignal(Publisher[]). To be removed in reactor 3.5. |
| reactor.util.Metrics.MicrometerConfiguration.getRegistry()
prefer using Micrometer setup in new reactor-core-micrometer module. To be removed at the earliest in 3.6.0.
|
| reactor.core.publisher.MonoProcessor.isCancelled()
the
MonoProcessor will cease to implement Subscription and this method will be removed in 3.5 |
| reactor.util.Metrics.isInstrumentationAvailable()
prefer explicit usage of the reactor-core-micrometer module. To be removed in 3.6.0 at the earliest.
|
| reactor.core.publisher.Flux.limitRequest(long)
replace with
take(n, true) in 3.4.x, then Flux.take(long) in 3.5.0.
To be removed in 3.6.0 at the earliest. See https://github.com/reactor/reactor-core/issues/2339 |
| reactor.core.publisher.Flux.mergeOrdered(Comparator<? super T>, Publisher<? extends T>...)
Use
Flux.mergeComparingDelayError(int, Comparator, Publisher[]) instead
(as Flux.mergeComparing(Publisher[]) don't have this operator's delayError behavior).
To be removed in 3.6.0 at the earliest. |
| reactor.core.publisher.Flux.mergeOrdered(int, Comparator<? super T>, Publisher<? extends T>...)
Use
Flux.mergeComparingDelayError(int, Comparator, Publisher[]) instead
(as Flux.mergeComparing(Publisher[]) don't have this operator's delayError behavior).
To be removed in 3.6.0 at the earliest. |
| reactor.core.publisher.Flux.mergeOrdered(Publisher<? extends I>...)
Use
Flux.mergeComparingDelayError(int, Comparator, Publisher[]) instead
(as Flux.mergeComparing(Publisher[]) don't have this operator's delayError behavior).
To be removed in 3.6.0 at the earliest. |
| reactor.core.publisher.Flux.mergeOrderedWith(Publisher<? extends T>, Comparator<? super T>)
Use
Flux.mergeComparingWith(Publisher, Comparator) instead
(with the caveat that it defaults to NOT delaying errors, unlike this operator).
To be removed in 3.6.0 at the earliest. |
| reactor.core.publisher.Flux.metrics()
Prefer using the
Flux.tap(SignalListenerFactory) with the SignalListenerFactory provided by
the new reactor-core-micrometer module. To be removed in 3.6.0 at the earliest. |
| reactor.core.publisher.Mono.metrics()
Prefer using the
Mono.tap(SignalListenerFactory) with the SignalListenerFactory provided by
the new reactor-core-micrometer module. To be removed in 3.6.0 at the earliest. |
| reactor.core.publisher.MonoProcessor.peek()
this method is discouraged, consider peeking into a MonoProcessor by
turning it into a CompletableFuture |
| reactor.core.publisher.Flux.publishNext()
use
Flux.shareNext() instead, or use `publish().next()` if you need
to `connect(). To be removed in 3.5.0 |
| reactor.util.context.Context.putAll(Context)
will be removed in 3.5, kept for backward compatibility with 3.3. Until
then if you need to work around the deprecation, use
Context.putAll(ContextView)
combined with Context.readOnly() |
| reactor.core.publisher.MonoProcessor.request(long)
the
MonoProcessor will cease to implement Subscription in 3.5 |
| reactor.core.publisher.FluxProcessor.sink()
To be removed in 3.5, prefer clear cut usage of
Sinks
through the Sinks.many() spec. |
| reactor.core.publisher.FluxProcessor.sink(FluxSink.OverflowStrategy)
To be removed in 3.5, prefer clear cut usage of
Sinks
through the Sinks.many() spec. |
| reactor.core.scheduler.Scheduler.start()
Use
Scheduler.init() instead. The use of this method is discouraged.
Some implementations allowed restarting a Scheduler, while others did not. One
of the issues with restarting is that checking
the disposed state is unreliable in concurrent scenarios. |
| reactor.core.publisher.Flux.subscribe(Consumer<? super T>, Consumer<? super Throwable>, Runnable, Consumer<? super Subscription>)
Because users tend to forget to
request the subsciption. If
the behavior is really needed, consider using Flux.subscribeWith(Subscriber). To be removed in 3.5. |
| reactor.core.publisher.Flux.switchMap(Function<? super T, Publisher<? extends V>>, int)
to be removed in 3.6.0 at the earliest. In 3.5.0, you should replace
calls with prefetch=0 with calls to switchMap(fn), as the default behavior of the
single-parameter variant will then change to prefetch=0.
|
| reactor.core.publisher.FluxProcessor.switchOnNext()
should use
Sinks, Sinks.Many.asFlux() and Flux.switchOnNext(Publisher). To be removed in 3.5.0. |
| reactor.core.publisher.Flux.switchOnNext(Publisher<? extends Publisher<? extends T>>, int)
to be removed in 3.6.0 at the earliest. In 3.5.0, you should replace
calls with prefetch=0 with calls to switchOnNext(mergedPublishers), as the default
behavior of the single-parameter variant will then change to prefetch=0.
|
| reactor.core.Scannable.tagsDeduplicated()
Micrometer APIs generally deduplicate tags and key-value pairs by default, so for related use cases prefer
Scannable.tags(). |
| reactor.util.Metrics.MicrometerConfiguration.useRegistry(MeterRegistry)
prefer using Micrometer setup in new reactor-core-micrometer module. To be removed at the earliest in 3.6.0.
|
| Constructor and Description |
|---|
| reactor.core.publisher.UnicastProcessor(Queue<T>, Consumer<? super T>, Disposable) |