Any help on this would be helpful to me.
@gadipati link https://gist.github.com/bcaramu/cd03717109dfb8493f3d
still does not work.
I get a gist.github error message : Whoops. We seem to have missed the gist of that gist you were looking for.
(also if the problem arises as well with something like LIMIT 10
in your query, please use it, this will limit the amount of âdomain noiseâ in your log, like the 1127 horse entries in your first log)
HI Simon,
Iâm trying to get just 2 columns from the bucket. The query working good in cbq but not with java SDk.
I tried in all 2.1.xx versions.
05:03:15,362 ERROR [com.couchbase.client.deps.io.netty.util.ResourceLeakDetector] (cb-io-5-2) LEAK: ByteBuf.release() was not called before itâs garbage-collected.
Recent access records: 0
Created at:
com.couchbase.client.deps.io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:259)
com.couchbase.client.deps.io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155)
com.couchbase.client.deps.io.netty.buffer.PooledUnsafeDirectByteBuf.copy(PooledUnsafeDirectByteBuf.java:320)
com.couchbase.client.deps.io.netty.buffer.SlicedByteBuf.copy(SlicedByteBuf.java:150)
com.couchbase.client.deps.io.netty.buffer.AbstractByteBuf.copy(AbstractByteBuf.java:919)
com.couchbase.client.core.endpoint.query.QueryHandler.parseQueryRows(QueryHandler.java:419)
com.couchbase.client.core.endpoint.query.QueryHandler.parseQueryResponse(QueryHandler.java:328)
com.couchbase.client.core.endpoint.query.QueryHandler.decodeResponse(QueryHandler.java:190)
com.couchbase.client.core.endpoint.query.QueryHandler.decodeResponse(QueryHandler.java:62)
com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:161)
com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageCodec.java:81)
com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:182)
com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
com.couchbase.client.deps.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130)
com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
com.couchbase.client.deps.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
java.lang.Thread.run(Thread.java:745)
05:03:37,551 ERROR [stderr] (httpâ0.0.0.0-8080-1) com.couchbase.client.core.CouchbaseException: java.lang.IllegalStateException: Error parsing query response (in TRANSITION) at
05:03:37,553 ERROR [stderr] (httpâ0.0.0.0-8080-1) at com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:168)
@gadipati this looks like you were using developer preview 2 (java-client-2.1.0-dp2.jar
) when you obtained this error.
You should definitely not use 2.1.0-dp nor 2.1.0-dp2, since itâs been established youâre impacted by a bug in both these versions. Furthermore, the first time you shared a log was just after final release of 2.1.0, so itâs established as well that this version doesnât work for you.
What I advised you to do is build and use a version of the SDK from git master branch, thatâd be 2.1.1-SNAPSHOT
.
Can you confirm that you followed these steps in order to depend on the latest code on master, then encountered some issues?
Here are the steps (in windows console, cd first to a relevant root directory where the SDK sources will be pulled):
git clone https://github.com/couchbase/couchbase-jvm-core.git
cd couchbase-jvm-core
gradlew clean publishToMavenLocal
Gradle should output a SUCCESS
cd ..
git clone https://github.com/couchbase/couchbase-java-client.git
cd couchbase-java-client
gradlew clean publishToMavenLocal
Once again Gradle should output a SUCCESS and store the build SDK in your local maven repository as java-client-2.1.1-SNAPSHOT
.
Then change the java-client dependency version in your pom.xml (or build.gradle if you use Gradle) to 2.1.1-SNAPSHOT
instead of 2.1.0something.
Please then report your findings here in a gist if you still see parsing/querying problems.
Ideally try to come up with a smallest reproducible example. eg. does it still happen in a brand new maven project with java-client 2.1.1-SNAPSHOT and log4j dependency, just calling a query on the beer-sample bucket, with a LIMIT 10 at the end of the query?
This is so that we can try to reproduce on common grounds or more easily investigate the logs and make progress.
Thanks!
Simon
(note that the ResourceLeakDetector log shouldnât be fatal, yet shouldnât happen with QueryHandler.parseQueryRows
in its stacktrace if you use the blocking API)
Ok @gadipati, figured it out: thereâs now a bug tied to keepalive⌠The parsing of query response itself was fine in your logs (but it was not chunked anyway, so it was maybe too simple a case).
Iâll commit a fix in the next few hours (tracked in issue JVMCBC-151), but in the meantime or if you donât want to rebuild the jar from sources yet, you can try to disable keepalive:
in the CouchbaseEnvironment
, disable it by calling keepAliveInterval(0L)
.
Then run your full query (SELECT *
instead of SELECT COUNT(*)
) and check again that everything works fine with big chunked responses (fingers crossed).
Hi Simon,
I have used keepALiveInterval(0L)
. Even though I see TimeOutException.
Here is Log
Thanks,
Note: the fix for the keepAlive problem has been committed to couchbase-jvm-core
â s master.
The extract of log you last provided doesnât give much context unfortunately
Everything up to receiving the response seem to go smoothly⌠Then a timeout.
You confirm queryTimeout is still set to 60000L (IIRC from another thread of yours)? Also could you please add timestamps into your logging pattern? (eg. using the pattern from log4j.properties content I included earlier in this thread)?
I was able to reproduce your previous timeout issue (due to keepAlive) in an isolated project. Just a maven project with a Main class
- configuring a
CouchbaseEnvironment
with queryEnabled(true)
-
keepAliveInterval(10000L)
-> 10 seconds -
queryTimeout(2000L)
-> 2 seconds - connecting to the local cluster (with
queryEnabled(true)
andkeepAliveInterval(10000L)
) - opening default bucket
- sleeping for 10s
- querying with a â
Query.simple("SELECT COUNT(*) FROM `beer-sample`")
â
The project has a pom referencing log4j and java-client 2.1.1-SNAPSHOT, and log4j.properties
with content in earlier post as a resource, and thatâs all.
This would exhibit the timeout while keepAlive is activated and fired at least once, but not with keepAlive deactivated
The error disappeared completely once the JVMCBC-151 fix was appliedâŚ
H Simon,
I have pulled latest code and tried. 1st time request query execution is going very smoothly but TimeOutException is again raising from 2nd time onward. Please have a look on below logs.
System.setProperty(âcom.couchbase.queryEnabledâ, âtrueâ);
System.setProperty(âcom.couchbase.client.deps.io.netty.leakDetectionLevelâ, âadvancedâ);
CouchbaseEnvironment env = DefaultCouchbaseEnvironment.builder().keepAliveInterval(0L).connectTimeout(60000).queryTimeout(60000).queryEnabled(true).build();
cluster = CouchbaseCluster.create(env, host);
bucket = cluster.openBucket(databaseName, ââ);
Success Request Log
Failed Request Log
Thanks,
I have been opened a new bucket once and re-using that again and again for further requests.
Thanks