Backpressure support in java SDK 2.1


We have have been using couchbase for some time and right now switching over to use the new rxjava in our own system integration with couchbase.

We have a flow of information passing through our system and using couchbase for storage.
Right now we try to both have a “Hot” and “Cold” Observables solution for each data object passing through the system.

Does couchbase java sdk api support backpressure?

There are some properties you can set for performance in the couchbase environment for performance.

Is there any properties/environment to configure for the couchbase api for the different solutions to maximize performance and throughput?

Do you recommend eather to use a “hot” or “cold” observable passing data to couchbase java api?

hi @martinz

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.

Concerning backpressure:
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 Query and 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.