RequestCancelledException

Java SDK
1

Hi,
We have a Couchbase Enterprise 6.5.1 server and we are using Java SDK 2.7.7 client. Our service was working fine until last week when we implemented a business logic to reduce the number of DB calls. Now after this we are seeing some Request cancelled in-flight exceptions.

rootCause=
org.springframework.data.couchbase.core.OperationCancellationException: Request cancelled in-flight.; nested exception is com.couchbase.client.core.RequestCancelledException: Request cancelled in-flight.
	at org.springframework.data.couchbase.core.CouchbaseExceptionTranslator.translateExceptionIfPossible(CouchbaseExceptionTranslator.java:107)
	at org.springframework.data.couchbase.core.CouchbaseTemplate.execute(CouchbaseTemplate.java:556)
	at org.springframework.data.couchbase.core.CouchbaseTemplate.queryN1QL(CouchbaseTemplate.java:510)
	at org.springframework.data.couchbase.core.CouchbaseTemplate.findByN1QL(CouchbaseTemplate.java:445)
	at

I have gone through this forum and found this error generally occurs for older versions of client SDK.
Is there anything we can do to remove this error on our end?

@ingenthr @daschl @vsr1 @subhashni

2

@Ashish_Mishra this error comes up when a network socket is closed and a request has been in-flight on that socket. So something happened on your network at that time. If you have java SDK logging enabled with info and above, at a similar time window you should see what could’ve caused that exception.

Was it a one-off or is it coming at (regular) intervals?

Also note that you are on a quite old SDK version - please consider upgrading to SDK 3 soon or at least pick up the latest 2.7.x version so that you have all the bugfixes and minimize incompatibilities with later server versions.

1 Like
3

@daschl … is there anything else we can configure, like some option where SDK can re try for such failures.

4

@kaintharinder in SDK 2 there is no automatic retry for this kind of exception because we do not know what side effect it could have caused on the server side if it was a mutation operation (even with n1ql you could’ve performed a DML operation). If you know that your n1ql quers is select-only and idempotent, you can retry yourself.

SDK 3 is more advanced in this regard, if you set readonly(true) on the QueryOptions then the SDK will retry it for you.

1 Like
5

Hi @daschl ,

Mostly we will go with custom retry for the time being.
Can you suggest a sure shot way to reproduce this for testing , currently it is intermittent and we are not able to reproduce it on purpose.

6

@kaintharinder you can put constant query load on a system and then stop the node, or interrupt the sockets with i.e. a firewall. Or you put some kind of proxy in the middle which allows you to cut of sockets while operations are in-flight.