Concerning configuration, I think the
retryStrategy can be interesting to you. By default, it is a
BestEffortRetryStrategy, which will reschedule an operation upon failure until said operation exceeds its allowed lifetime. You can alternatively choose to fail faster with the
FailFastRetryStrategy which will propagate the error and abandon the operation upon failure.
First thing to note is that we have a
BackpressureException but it is different from the RxJava concept of backpressure (which is also called Reactive Pull Backpressure).
- RxJava’s backpressure includes a mean of controlling the amount of data that flows through a stream, by letting the consumer tell the producer how much data it can handle without being overwhelmed.
- Couchbase SDK’s backpressure is simpler, an indication that the underlying architecture for requests is at maximum capacity, in which case a
BackpressureException is propagated to the client. Clients should in this case back off (maybe with a growing delay) and retry later. The request(s) will have been cancelled.
So in this sense, the SDK doesn’t really support
Reactive Pull Backpressure. We make use of some operators and structures that don’t support it (especially in handling
ViewQuery, which are based on
Subjects). You probably only need it on querying (with multiple rows) anyway, since key-value operations are “one-shot”.
Note that when using
Subjects, we use
onBackpressureBuffer() which will bufferize the items that couldn’t be consumed.
Concerning Hot vs Cold:
If you’re talking about creating your very own
Observables, then I think it only depends on your use case. We’ll create our own
Observables in the SDK so these concerns will be decoupled.
In the SDK, we initially made everything hot. In insight, notably for retry purposes and because we need to correctly manage Netty’s resources (
ByteBuf), a cold approach would be better. We have now started moving toward this goal.