Getting Concurrent Timeout error while connecting to bucket using CB 7.1.3 and java sdk spring CB version 3.1.9.RELEASE

Java SDK
1

Occasionally getting timeout error while making a n1q1 get query after a week which does not occur regularly. Any specific config to check on why getting timeout error. Any suggestion around this. This resolves only after a server restart.

java.util.concurrent.TimeoutException: {“b”:“bucket”,“s”:“n1ql”,“t”:75000000,“i”:“6a2dce72-f751-4e24-93e0-8d2251e9b556”}
java.lang.RuntimeException: java.util.concurrent.TimeoutException: {“b”:“vod-content”,“s”:“n1ql”,“t”:75000000,“i”:“6a2dce72-f751-4e24-93e0-8d2251e9b556”}
at rx.exceptions.Exceptions.propagate(Exceptions.java:57) ~[rxjava-1.3.8.jar!/:1.3.8]
at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:463) ~[rxjava-1.3.8.jar!/:1.3.8]
at rx.observables.BlockingObservable.single(BlockingObservable.java:340) ~[rxjava-1.3.8.jar!/:1.3.8]
at com.couchbase.client.java.CouchbaseBucket.query(CouchbaseBucket.java:650) ~[java-client-2.7.9.jar!/:?]
at com.couchbase.client.java.CouchbaseBucket.query(CouchbaseBucket.java:564) ~[java-client-2.7.9.jar!/:?]
Caused by: java.util.concurrent.TimeoutException: {“b”:“bucket”,“s”:“n1ql”,“t”:75000000,“i”:“6a2dce72-f751-4e24-93e0-8d2251e9b556”}
at com.couchbase.client.java.bucket.api.Utils$1.call(Utils.java:131) ~[java-client-2.7.9.jar!/:?]
at com.couchbase.client.java.bucket.api.Utils$1.call(Utils.java:127) ~[java-client-2.7.9.jar!/:?]
at rx.internal.operators.OperatorOnErrorResumeNextViaFunction$4.onError(OperatorOnErrorResumeNextViaFunction.java:140) ~[rxjava-1.3.8.jar!/:1.3.8]

2

There is no information in that partial stack trace than a timeout has occurred. If restarting the server resolves the problem, then it would point to a server problem. The Couchbase Java SDK version you are using - 2.7.9 - is very old, you may wish to consider upgrading.

4

thank you mreiche, w.r.t to below error is it some thing query timeout error? what is the t stands for .

java.util.concurrent.TimeoutException: {“b”:“bucket”,“s”:“n1ql”,“t”:75000000,“i”:“6a2dce72-f751-4e24-93e0-8d2251e9b556”}
java.lang.RuntimeException: java.util.concurrent.TimeoutException: {“b”:“vod-content”,“s”:“n1ql”,“t”:75000000,“i”:“6a2dce72-f751-4e24-93e0-8d2251e9b556”}

5

And also I see the below logs w.r.t connection degrade and channel inactive, outdated connection. Any specific issue thats causing this. Thanks.

[INFO ] 2023-09-06 03:06:31.037 [cb-io-1-3] Endpoint - [/10.8.16.192:8093][QueryEndpoint]: Got notified from Channel as inactive, attempting reconnect.
[DEBUG] 2023-09-06 03:06:31.037 [cb-core-5-1] ConfigurationProvider - Received signal to proactively refresh (a maybe outdated) configuration.
[DEBUG] 2023-09-06 03:06:31.037 [cb-core-3-1] ConfigurationProvider - Received signal to proactively refresh (a maybe outdated) configuration.
[DEBUG] 2023-09-06 03:06:31.038 [cb-io-4-1] Endpoint - [/10.8.16.192:8093][QueryEndpoint]: Connected Endpoint.
[DEBUG] 2023-09-06 03:06:31.038 [cb-io-1-3] Endpoint - [/10.8.16.192:8093][QueryEndpoint]: Connected Endpoint.
[DEBUG] 2023-09-06 03:06:31.038 [cb-io-4-1] Node - [10.8.16.192]: Connected (DEGRADED) to Node
[DEBUG] 2023-09-06 03:06:31.038 [cb-io-1-3] Node - [10.8.16.192]: Connected (DEGRADED) to Node

6

t= 75000000 is the timeout specified in the call (the default, 75000000 microseconds. i.e. 75 seconds).

Normally the DEBUG messages can be disregarded. Stale/unused connections are closed and re-opened all the time, and is not an error condition (hence the logging at DEBUG instead of WARNING or ERROR).

To troubleshoot, you should identify which query is timing out, and why it is taking longer than 75 seconds to complete. It may be that the query is inefficient, or even if it is efficient, what it does requires a long time, or the server is overloadeded.

7

Just to add to Mike’s reply - while there are many potential reasons for a server to disconnect, one common cause is that the server added protection against slowloris attacks by disconnecting idle connections automatically and on a short threshold (5 seconds by default). If you upgrade to a recent SDK version this will disappear, as the SDK will preemptively close the idle connection before the server does. But either way, if this is the cause of the server disconnect, it is safe to ignore.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.