Non-TransactionOperationFailed in Transactions API

Java SDK
1

Rarely, but we see these during transactions:

sbt.ForkMain$ForkError: java.lang.IllegalStateException: Non-TransactionOperationFailed '{err=OverflowException,ec=FAIL_OTHER,msg='Could not emit value due to lack of requests'}' received, this is a bug
	at com.couchbase.transactions.TransactionsReactive.executeHandleErrorsPostRetry(TransactionsReactive.java:279)
	at com.couchbase.transactions.TransactionsReactive.lambda$executeTransaction$4(TransactionsReactive.java:134)
	at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onError(FluxOnErrorResume.java:94)
	at reactor.core.publisher.SerializedSubscriber.onError(SerializedSubscriber.java:124)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenMainSubscriber.whenError(FluxRetryWhen.java:224)
	at reactor.core.publisher.FluxRetryWhen$RetryWhenOtherSubscriber.onError(FluxRetryWhen.java:273)
	at reactor.core.publisher.FluxConcatMap$ConcatMapImmediate.innerError(FluxConcatMap.java:308)

What could cause this?

2

Hi @zoltan.zvara
This is a Reactor error, it sometimes indicates a ‘hot source’ (one that emits ticks regardless of whether anything downstream is asking for them) is connected to a downstream source that cannot keep up with the tick stream. There can be various reasons for that, such as a code bug - e.g. the downstream source is doing something too slow - or sometimes the process is starved (CPU, GC or similar) and cannot keep up. Unfortunately there’s not enough in the stacktrace to show what’s going on.

Are you using the Reactive API yourself? (I know you weren’t in your previous forum posts, just want to check you haven’t moved to it.)

You should be getting a TransactionFailed error containing a logs() object. Would it be possible to provide the output of this? Using Couchbase Transactions | Couchbase Docs. That should give some indication where the OverflowException was originally raised.

Another thing that would provide some extra diagnostics is to enable Reactor’s improved stacktraces with:

 Hooks.onOperatorDebug();

There’s more info on it here - https://spring.io/blog/2019/03/28/reactor-debugging-experience - essentially it makes Reactor produce a much more helpful stacktrace that will hopefully point to the originator of the OverflowException.
(Note this onOperatorDebug slows things down and may not be suitable for production use as a result.)

1 Like