I am getting below runtime exception when I repeatedly call a Java Spring boot api invoking a N1QL parameterized query. Some calls go through, but when the call is made immediately following a successful call, the timeout exception occurs.
Using Couchbase 6.0.1, Java SDK 2.7.7.
The N1qlParams are as follows:
N1qlParams.build().pretty(false).readonly(true).disableMetrics(true).maxParallelism(3);
java.lang.RuntimeException: java.util.concurrent.TimeoutException: {“b”:“mybucket”,“r”:“XXXX”,“s”:“n1ql”,“c”:“XXX”,“t”:10000000,“i”:"",“l”:""}
at rx.exceptions.Exceptions.propagate(Exceptions.java:57)
at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:463)
at rx.observables.BlockingObservable.single(BlockingObservable.java:340)
at com.couchbase.client.java.CouchbaseBucket.query(CouchbaseBucket.java:650)
at com.couchbase.client.java.CouchbaseBucket.query(CouchbaseBucket.java:564)
Can someone please advise when this exception is usually encountered? Is this timing out when Query node is performing a Keyscan access from the data node? The underlying query which is causing this exception has USE KEYS clause in it. Also, what does the letters ‘r’, ‘t’, ‘s’, ‘l’ mean in the exception below and where is port 52654 used?
I have been struggling to find an answer, but I am not sure where the root cause it at. The api & couchbase servers are in different containerized environments.
java.lang.RuntimeException: java.util.concurrent.TimeoutException:
{“b”:“csdqm”,“r”:“1.2.3.100:8093”,“s”:“n1ql”,“c”:“AAAAAAAAAAAAAAAA/000000009999900”,“t”:100000000,“i”:“CONTEXTID”,“l”:“1.2.5.24:52654”}
at rx.exceptions.Exceptions.propagate(Exceptions.java:57)
at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:463)
at rx.observables.BlockingObservable.single(BlockingObservable.java:340)
at com.couchbase.client.java.CouchbaseBucket.query(CouchbaseBucket.java:650)
at com.couchbase.client.java.CouchbaseBucket.query(CouchbaseBucket.java:564)
As to the cause of the timeout, it’ll probably require some looking at the logs for the query service. Most commonly it’s not using an optimal index or another issue with index scan, but it can also be something sub-optimal in the query.
One thing you can do is turn the query timeout higher with a ‘canary’ of sorts, and add the option for query profiling.