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