JOIN or NEST on same bucket

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)

Note @gadipati @geraldss moved this to the Java SDK section of the forums…

Hi,

I have followed your suggestions. Getting TimeoutException

Log File

Thanks,
Gadipati

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).

1 Like

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 :confused:
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) and keepAliveInterval(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 :confused:
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