Hi,
I’m trying to pick the proper maven artefact to work with Couchbase using JVM-based client. There are two of those both claiming to be an official ones that use the same maven groupId: com.couchbase.client. The official Couchbase SDK site refers to the “couchbase-client” while some other sources refer to “java-client”.
Could someone please give me a clue to disambiguate? Is there any comparison of those two clients?
Thanks in advance!
Seems this page gives a good answer.
v 1.4.7 : API compatible with memcache API.
v 2.x : API use RxJava API (reactive programming but a little more verbose if you are not using jdk8)
But you can use both to any couchbase server version.
checking the documentation first is always a good idea! Glad you found it right away.
From 1.* to 2.* we changed the artifact name to 1) allow people to use it side by side 2) open the door for more language bindings (scala-client,…)
Thanks for your responses, gentlemen!
I’ve got another question comparing couchbase-client to java-client: in my case java-client is much more desirable since it relies on rx-java, but I find CouchbaseEnvironment settings list is poorer then CouchbaseConnectionFactoryBuilder from couchbase-client.
Is this for a purpose or am I missing something again?
Thank you!
@Alex_Lomov well since 2.0 is a complete rewrite compared to 1.x, the environment is different (names, meaning,…).
What are you missing on 2.x that you have configured on 1.x? There is either a replacement to configure or it does not need to be configured at all.
@daschl I’m missing opTimeout + timeoutExceptionThreshold combination.
I haven’t configured anything yet but the aforementioned parameter combination seems to make sense.
Again, I’m new to Couchbase so thanks for your help!
Okay first, you can find great env param documentation now in our docs: http://docs.couchbase.com/developer/java-2.1/env-config.html
The opTimeout equivalent for the default blocking timeout is: kvTimeout, viewTimeout and queryTimeout, depending on which service you are using. The timeoutExceptionThreshold is currently not configurable, but we have other things in place that will trigger explicit node reconnects (including the heartbeat). Also, the underlying netty codebase is much better in connecting broken connections than the older code in spy was (which in partly was the motivation for timeoutExceptionThreshold).
What are you trying to solve with those config params?
Yeah, thank you! Found it 15 minutes ago. It really rocks 
I have a requirement to treat a cluster node as failed in a time frame that is shorter that the cluster autofailiver minimal value. It seems that could work.