[JCBC-612] Disable Checkstyle in gradle build until we have a checkstyle configuration Created: 31/Oct/14  Updated: 31/Oct/14  Resolved: 31/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-start
has to be started together with JVMCBC-53 Disable checkstyle in gradle build pe... Resolved
Relates to
relates to JCBC-613 Choose and verify against a coding st... New

 Description   
At the moment no checkstyle configuration has been put in place, but checkstyle plugin is activated in gradle build. This causes the build to fail, most notably in Jenkins.
Disable the checkstyle plugin until a coding style has been decided upon and enforced through checkstyle (see linked issues).

 Comments   
Comment by Simon Baslé [ 31/Oct/14 ]
https://github.com/couchbase/couchbase-java-client/commit/1fa75eb3a927facbfbef3ef4650d31767fbee052




[JCBC-614] Add List and Map factory methods to JsonArray and JsonObject Created: 31/Oct/14  Updated: 31/Oct/14

Status: New
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1, 2.1.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
A handy addition to the APIs would be to create JsonObjects and JsonArrays from Maps and Lists.

We need to make sure that the content though is supported and if not throw an exception.

 Comments   
Comment by Michael Nitschinger [ 31/Oct/14 ]
Further remarks from talking with Simon:

- We will throw a NPE if null is passed in
- We will throw a IllegalArgumentException if the values are not compatible with JSON.

The generics accepted will be:

Map<String, ?>
and
List<?>




[JCBC-611] Improve readability of flags related elements in TranscoderUtils Created: 30/Oct/14  Updated: 31/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Dealing with flags, bit shift operators and legacy flag vs common flag specification is a non-trivial brain gymnastic. Improve readability of code related to that in TranscoderUtils to make the spec more visible and the different parts more explicit.




[JCBC-613] Choose and verify against a coding standard with Checkstyle Created: 31/Oct/14  Updated: 31/Oct/14

Status: New
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0.0, 2.0.1
Fix Version/s: 2.0.2
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Simon Baslé Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-start
has to be started together with JVMCBC-54 Choose and verify against a coding st... Open
Relates to
relates to JCBC-612 Disable Checkstyle in gradle build un... Resolved

 Description   
Choose a coding style and let the build check code conforms to it through Checkstyle plugin.

Proposed coding standard: Google Java Style (https://google-styleguide.googlecode.com/svn/trunk/javaguide.html), available as a Checkstyle configuration as summed up here: http://checkstyle.sourceforge.net/google_style.html




[JCBC-598] Auth failure using carrier protocol is too subtle Created: 21/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: 2.0.1, 1.4.6
Security Level: Public

Type: Bug Priority: Minor
Reporter: Dan Douglas Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: connection
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File aero-ebay.log    

 Description   
We just ran into a problem with a misconfigured datasource. We traced it to a bad password, but we had to enable DEBUG logging on the client to get that indication.

Without DEBUG logging turned on, this shows up as

com.couchbase.client.vbucket.ConfigurationException: Could not fetch a valid Bucket configuration.

but once we enable DEBUG logging, we get the following in the log

2014-10-21 18:32:49,760 DEBUG [Memcached IO over {CouchbaseConfigConnection to oauthcbdb05.db.stratus.ebay.com/10.66.100.13:11210}] Reconnection due to exception handling a memcached operation on {QA sa=oauthcbdb05.db.stratus.ebay.com/10.66.100.13:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=1}. This may be due to an authentication failure.
net.spy.memcached.ops.OperationException: Auth failure
at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:192) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.OperationImpl.finishedPayload(OperationImpl.java:204) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.SASLBaseOperationImpl.finishedPayload(SASLBaseOperationImpl.java:98) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.OperationImpl.readPayloadFromBuffer(OperationImpl.java:196) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl.java:139) ~[spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.readBufferAndLogMetrics(MemcachedConnection.java:861) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:840) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleReadsAndWrites(MemcachedConnection.java:720) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:683) [spymemcached-2.11.4.jar:2.11.4]
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:436) [spymemcached-2.11.4.jar:2.11.4]
at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:325) [couchbase-client-1.4.4-JCBC-566-3.jar:1.4.4-JCBC-566-3]

Bad passwords used to get and exception referencing a 401 status code when the map was read via HTTP.

Now using the carrier protocol, there isn't a good way to tell the difference between a bad password and the bucket not existing.

I know it sounds trivial, but tracking down the difference in our production environment just ate up a few hours of engineer time -- time that would have been saved if the exception message indicated that it had been caused by an Auth Failure.... the spymemcached exception did, but somewhere along the way that got swallowed and all we got was "Could not fetch a valid Bucket configuration."

I've attached the log with DEBUG turned on.

 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
Well, I think we need to make sure its good in both 1.4.x and 2.0.x.

I'll put this on the list of both the next bugfix releases and see what we can do to improve that.

Dan, thanks for raising this.




[JCBC-603] Java SDK 2.0 Docs: add brief paragraph on new style bulk get Created: 22/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Tom Green Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In the 1.4.x series SDK's we had support for 'bulk get' operations as part of the API.

These bulk specific APIs are no longer necessary in the 2.0 SDK as it's very straightforward to achieve the same results in other ways.

Having said that, for customers who are familiar with our 1.4.x SDK, it's a little confusing as there is no reference to bulk get in the new docs. There is a very good example of how to do it a 'bulk get', but it took me about 15-20minutes to find it as I spent a lot of time searching through the API refs looking for bulk get, then looking in the docs for similar things.

In the section where the mechanism is described in the docs, could we just add one sentence which actually uses the words 'bulk get' or "getBulk" so that people trying to migrate from old APIs to the new will pick up the right place to look very quickly when searching?

This is the relevant page in the new docs:
http://docs.couchbase.com/developer/java-2.0/observables.html

And this is the Java 8 code example showing how it works:

// Loads 3 documents in parallel
Observable
    .just("doc1", "doc2", "doc3")
    .flatMap(bucket::get)
    .subscribe(document -> System.out.println("Got: " + document));


Perhaps we could just add a sentence in the pre-amble before example saying something like:
"Where as previously a specialist getBulk API was required, this is no long necessary as it can be seen that it's straight forward to implement as seen in the example".

I'm sure there are better ways of saying it, but hopefully it's sufficient to understand the intention.




[JCBC-605] document the supported JVMs Created: 23/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Todd Greenstein
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
At the moment, we compile for JDK 1.6 and later and test with a certain number of JDKs. We should determine what the team is comfortable listing as supported given this as there are some JVM environments we would have difficulty listing official support for.

Things to consider:
- OpenJDK versions
- JRockit
- IBM JVM

For instance, is JRockit on Linux supported? Is IBM JVM on Windows supported?

 Comments   
Comment by Matt Ingenthron [ 23/Oct/14 ]
todd: assigned this to you as it's something to work with engineering leads and QE. we should support what we test.
Comment by Michael Nitschinger [ 30/Oct/14 ]
Another one to consider is Azul's Zing

http://www.azulsystems.com/products/zing/whatisit




[JCBC-599] Handle CAS in remove operation Created: 22/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Sergey Avseyev Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JVMCBC-49 Check CAS from RemoveRequest Resolved
depends on JVMCBC-48 Populate CAS with RemoveResponse Resolved

 Description   
The CAS value should be exposed in operation response, and also checked in request for integrity

 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
JCBC-602




[JCBC-609] Fix Maven Tags on 2.0 Client, remove "beta" from package tags. Created: 28/Oct/14  Updated: 30/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0.0
Fix Version/s: None
Security Level: Public

Type: Task Priority: Critical
Reporter: Todd Greenstein Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Maven tags still list "beta" in 2.0 GA release.

http://mvnrepository.com/artifact/com.couchbase.client/java-client/2.0.0



 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
This is not possible anymore and has been an oversight. Action is taken to avoid this for subsequent releases.




[JCBC-596] Default and Maximum Lock Time needs clarifying Created: 19/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.4, 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Chris Malarky Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to
relates to MB-12379 Default and Maximum lock time describ... Open

 Description   
The maximum lock in 2.5.1 and 3.0.0 is 30 secs, the default is 15 seconds. Any attempt to set a lock higher than the maximum results in the default being used. The Java Developer Guide and API docs need updating to reflect this behaviour.



 Comments   
Comment by Michael Nitschinger [ 20/Oct/14 ]
Since you filed this for java, can you refer which page you want updating? The page you linked here states:

Note:
You can only write lock a document for a maximum of 30 seconds.

and
30 seconds are over and the server unlocks it for you.

and what do you mean by default lock time? There is no such thing in the SDK, the developer always needs to provide a lock time.
Comment by Chris Malarky [ 20/Oct/14 ]
There are two values in the server - ep_getl_max_timeout and ep_getl_default_timeout - not sure if they are configurable yet. If you don't specify a value, or specifiy greater than the max, then the default is used (which is 15 seconds).
Comment by Michael Nitschinger [ 20/Oct/14 ]
I'm not sure when the default ever applies - the binary protocol requires you to transmit the expiration time explicitly - so a default expiration time - other than 0 so do not expire - doesn't make much sense in an SDK context
Comment by Chris Malarky [ 20/Oct/14 ]
The default (15 seconds) does apply if you set an invalid lock time (less than zero, greater than 30).
Comment by Michael Nitschinger [ 20/Oct/14 ]
Ha! good to know that this exists, didn't know that. I was already thinking about disallowing an invalid time at all, but then if someone changes the 30 sec limit on the server it falls short.
Comment by Chris Malarky [ 20/Oct/14 ]
Exactly. Still not found for sure if these are configurable. If they are then you need to query the two values to check what they are.




[JCBC-595] names of jars is weird Created: 17/Oct/14  Updated: 30/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Dependencies
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
core-io-1.0.0 and java-client-2.0.0?

Shouldn't those have couchbase in them?

When they come from the zipfile, it could be really confusing.

 Comments   
Comment by Michael Nitschinger [ 30/Oct/14 ]
Hm, that's a good question. It makes total sense when you retrieve it from a package manager (since you have the group id in there), but I agree that in the zipfile it's different.

Now the question is

- should we rename the jars in the zipfile?
- can we do that without breaking anything? I don't know if the name of the jar makes a difference at all.

If it doesn't break anything, what about prefixing in the zip files with couchbase- ?




[JCBC-610] TranscoderUtils doesn't recognize BINARY_COMPAT_FLAGS as binary Created: 30/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The TranscoderUtils.hasBinaryFlags() method doesn't return true when testing against BINARY_COMPAT_FLAGS.

 Comments   
Comment by Simon Baslé [ 30/Oct/14 ]
https://github.com/couchbase/couchbase-java-client/commit/784a5b0870ba4f11c1130dcc48c775bac4543b2e




[JCBC-594] code doc sections are labeled incorrectly Created: 17/Oct/14  Updated: 30/Oct/14  Resolved: 30/Oct/14

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Matt Ingenthron Assignee: Amy Kurtzman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
XML docs are labeled and syntax highlighted as Java:
http://www.couchbase.com/developer/java-2.0/logging.html



 Comments   
Comment by Amy Kurtzman [ 30/Oct/14 ]
Fixed language tagging on the page.




[JCBC-593] Getting com.couchbase.client.vbucket.BucketUpdateResponseHandler exceptionCaught exception Created: 15/Oct/14  Updated: 29/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.0, 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Rukmini Nagarajaiah Assignee: Simon Baslé
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Also Im trying a standalone java code to start couchbase client. Below is the code referred from http://www.couchbase.com/develop/java/previous


This is the code
public class HelloWorld {
public static final int EXP_TIME = 20;
public static final String KEY = "spoon";
public static final String VALUE = "Hello World!";

public static void main(String args[]) {
// Set the URIs and get a client
List<URI> uris = new LinkedList<URI>();
    Boolean do_delete = false; //

    // Connect to localhost or to the appropriate URI
    uris.add(URI.create("http://127.0.0.1:8091/pools"));

    CouchbaseClient client = null;
    try {
      client = new CouchbaseClient(uris, "default", "");
    } catch (Exception e) {
      System.err.println("Error connecting to Couchbase: "
        + e.getMessage());
      System.exit(0);
    }

}
}

Im getting the below exception.. May I know reason for this. ? Im like stuck with this. Please help

Oct 14, 2014 11:06:26 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler exceptionCaught
WARNING: Exception occurred: Operation timed out

Oct 14, 2014 11:06:26 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler exceptionCaught
WARNING: sun.nio.ch.FileDispatcherImpl.read0(Native Method)
sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
sun.nio.ch.IOUtil.read(IOUtil.java:192)
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:375)
org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:69)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:390)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:261)
org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)


dependency

       <dependency>

<groupId>com.couchbase.client</groupId>

<artifactId>couchbase-client</artifactId>

<version>1.3.0</version>

  </dependency>

        <dependency>

        <groupId>commons-codec</groupId>

        <artifactId>commons-codec</artifactId>

        <version>1.7</version>

      </dependency>

      <dependency>

        <groupId>org.codehaus.jettison</groupId>

        <artifactId>jettison</artifactId>

        <version>1.3</version>

       

      </dependency>

           <dependency>

        <groupId>net.spy</groupId>

        <artifactId>spymemcached</artifactId>

        <version>2.11.4</version>

      </dependency>

      <dependency>

<groupId>org.jboss.netty</groupId>

<artifactId>netty</artifactId>

<version>3.2.0.Final</version>

</dependency>

 Comments   
Comment by Simon Baslé [ 29/Oct/14 ]
Hi Rukmini, sorry for the delay in responding.
This seems to be a warning that happens when there is a connection loss with the node, but the client should automatically reconnect.

Did you try the complete code sample from documentation? As is, this code does in fact nothing, it just wait there with a connection open (and it appears that there's a disconnect at some point, which is logged as WARNING, but as I said this should reconnect).

Also could you confirm the version of the couchbase server you use on your machine to run the test, and that the warning arises at each run?

One other thing: you mention this affects version 1.4.0 and 1.4.4, but the pom.xml extract you give at the end depends on 1.3.0 client, does that mean you've reproduced the issue in each of these client versions?




[JCBC-608] Document version compatibility Created: 27/Oct/14  Updated: 28/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.5, 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Task Priority: Major
Reporter: Brent Woodruff Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
It is unclear from the existing documentation which SDK should be used when using a certain version of Couchbase. There is a feature matrix for the SDK features, but this is not a compatibility matrix. It is not clear if Couchbase Server 3.0+ is required for Couchbase Java SDK 2.0 usage, or if Couchbase Java SDK 2.0 is compatible with Couchbase Server 2.x.

Please add a compatibility matrix or some statements in the affirmative for compatibility between SDK and Server versions.




[JCBC-607] Links in tutorial missing or incorrect Created: 27/Oct/14  Updated: 28/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Task Priority: Major
Reporter: Brent Woodruff Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
On this page:

http://docs.couchbase.com/developer/java-2.0/tutorial.html

I see these two issues:

"Download the JAR archive and run it using the command java -jar couchbaseBeersampleExample.jar." - there is no link to any JAR file.

"The framework for the tutorial can be downloaded from here." -> here is a link to www.example.org




[JCBC-606] Improve the way transcoders deal with ByteBuf on decode Created: 27/Oct/14  Updated: 27/Oct/14  Resolved: 27/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Simon Baslé Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In the java client, transcoders deal with ByteBuf passed by the core. It is the responsibility of the code that last uses ByteBuf to release it, which is not consistently done by some transcoders.

In order to reduce surface for leak problems, we need to facilitate correct release of buffers in transcoders decode operation, with maximum mutualization of code. This can be done by giving AbstractTranscoder the default behavior of release the buffer upon decoding and also if errors are detected.

In edge cases, ByteBuf may be needed down the road (BinaryDocument). For these cases, buffer release shouldn't be implicitly performed by the Transcoder.




[JCBC-604] Push Observe implementation to core-io library Created: 22/Oct/14  Updated: 27/Oct/14  Resolved: 27/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Sergey Avseyev Assignee: Sergey Avseyev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JVMCBC-51 Pull Observe utility class from java ... Resolved

 Description   
To reduce code duplication and improve maintainability




[JCBC-589] Java 2.0 SDK get "Unknown" version number Created: 14/Oct/14  Updated: 24/Oct/14  Resolved: 24/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Task Priority: Major
Reporter: Wei-Li Liu Assignee: Simon Baslé
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to

 Description   
New API should expose sdk version info
https://github.com/couchbase/couchbase-java-client/commit/6be5a7348f6eb01bcdb475c7057a6c4d05d5a194

I am getting "unknown" for the default value of git version and couchbase-client version

=========================================================================
            Package pkg = Package.getPackage("com.couchbase.client.java");
            String version = pkg.getSpecificationVersion();
            String gitVersion = pkg.getImplementationVersion();
            PACKAGE_NAME_AND_VERSION = String.format("couchbase-java-client/%s (git: %s)",
                version == null ? "unknown" : version, gitVersion == null ? "unknown" : gitVersion);
=========================================================================


 [1.66 DEBUG] (Handle receiveMessage:158) < INFO@0.0 => {"COMPONENTS":{"USER_AGENT":"couchbase-java-client/unknown (git: unknown) (Mac OS X/10.9.4 x86_64; Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13)","SDK_VERSION":"couchbase-java-client/unknown (git: unknown)"},"CAPS":{"VIEWS":true,"OBS":true,"DS_SHARED":true,"CANCEL":true,"CONTINUOUS":true,"TTL":true,"PREAMBLE":false}}

 Comments   
Comment by Simon Baslé [ 20/Oct/14 ]
hi wei-li,
could you please clarify how you built the sdk jar and how you used it to get the user_agent?

the gitversion is initialized by the gradle build system, and stored in the java sdk jar's manifest. usages outside of this packaged form will return unknown (as gradle won't correctly have initialized the manifest).

the version of the sdk on Maven Central (http://search.maven.org/#browse%7C650548152) exhibits correct behavior, as a simple test with maven dependency would show. Something like :
System.out.println(DefaultCouchbaseEnvironment.PACKAGE_NAME_AND_VERSION);
Comment by Wei-Li Liu [ 20/Oct/14 ]
Both Michael and Sergey verify that because sdkd repackage jars, so the java sdk jar's manifest might be lost or not found.
I think the propsed solution is to have a new snapshots and sdkd can grab the version from there.
Comment by Michael Nitschinger [ 22/Oct/14 ]
The fix has been merged into master. Please work with Simon on the actual build script follow up and then close/report here if it works now.
Comment by Michael Nitschinger [ 22/Oct/14 ]
https://github.com/couchbase/couchbase-java-client/commit/44e5e590b14634d7ffbbddaf69dd05f19b59f08a
Comment by Wei-Li Liu [ 22/Oct/14 ]
@Simon
I do get the sdk version number after pull the master, but I can't seem to get the core version right
The code to access the version number for both env
==================================
CouchbaseEnvironment Couchenv = DefaultCouchbaseEnvironment.builder().build();
CoreEnvironment Coreenv = DefaultCoreEnvironment.create();
String sdk_version = Couchenv.userAgent();
String core_version = Coreenv.userAgent();

sdkComponents.put("Core_VERSION", core_version);
sdkComponents.put("SDK_VERSION", sdk_version);
==================================


I get the sdk version when I try to print core version( should've been 1.0.1 instead of 2.0.1)
==================================
{"COMPONENTS":{"Core_VERSION":"couchbase-java-client/2.0.1-SNAPSHOT (git: 2.0.0-23-g44e5e59) (Mac OS X/10.9.4 x86_64; Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13)","SDK_VERSION":"couchbase-java-client/2.0.1-SNAPSHOT (git: 2.0.0-23-g44e5e59) (Mac OS X/10.9.4 x86_64; Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13)"}
=================================

Anywhere I need to make the change?
Comment by Wei-Li Liu [ 22/Oct/14 ]
I extract the packaged jar and it contains both properties file

core.properties file version number has not been changed
======================
version information injected by the build
implementationVersion=@implVersion@
specificationVersion=@specVersion@
=====================

java.properties version number does change
===========================
#version information injected by the build
implementationVersion=2.0.0-23-g44e5e59
specificationVersion=2.0.1-SNAPSHOT
===========================

if I extract core-io jar I can see the correct version number
=========================
#version information injected by the build
implementationVersion=1.0.0-13-g410cf30
specificationVersion=1.0.1-SNAPSHOT
=========================

I did clean before I build.
build.xml to create the jar
https://gist.github.com/weilliu/24976cb18fea141643be
Comment by Simon Baslé [ 23/Oct/14 ]
as seen with wei-li, we cleaned-up sdkd build scripts

found out that depending on the method called to get version number (in sdkd's ControlServer), we get different result :
 - if calling userAgent(), both core and java sdk report that they are "couchbase-java-client/2.0.1..."
 - if calling packageNameAndVersion() instead, both core and java sdk report their versions correclty (respectively "couchbase-jvm-core/1.0.1..." and "couchbase-java-client/2.0.1..."

after investigation this is due to the fact that the USER_AGENT static variable initialized by DefaultCouchbaseEnvironment is the one of its parent, DefaultCoreEnvironment (thus making core and java share same user_agent).
Comment by Simon Baslé [ 24/Oct/14 ]
userAgent() returning same info on core classes and java sdk classes is on purpose, so that to the external world we always identify as a java sdk.

packageNameAndVersion() can be used to distinguish between core's version and sdk's version (but in production we should always know which version of the core ships with a java sdk version anyway).

Core version is always accessible on calling DefaultCoreEnvironment.PACKAGE_NAME_AND_VERSION (or the corresponding method on a DefaultCoreEnvironment instance, but this is discouraged when using java sdk as you probably already have a DefaultCouchbaseEnvironment).
Comment by Wei-Li Liu [ 24/Oct/14 ]
I have merged the fix.




[JCBC-546] Expected Behavior of FailureMode.Cancel Created: 08/Sep/14  Updated: 23/Oct/14

Status: Reopened
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Jeff Dillon Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 0
Labels: 1.4.4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File App.java    
Issue Links:
Duplicate

 Description   
A few questions on the behavior of FailureMode.Cancel:

1) Is TimeoutExceptionThreshold irrelevant when using FailureMode.Redistribute ? The node is not deemed down even when the number of consecutive failures exceed the threshold.
2) In what scenarios is it advisable to use Redistribute ?
3) Whats the .NET equivalent.

 Comments   
Comment by Jeff Dillon [ 22/Sep/14 ]
Just checking, any updates on this? thx
Comment by Matt Ingenthron [ 08/Oct/14 ]
1) It is still relevant. Are you indicating there's a bug you've seen?
2) When using Couchbase buckets, Redistribute should always be used. The fact that there are options is more related to the way we extended the caching interface. There's no scenario where I'd recommend using Cancel.
3) There isn't a .NET equivalent at this point in time.

Is there a desired behavior? What's the scenario?




[JCBC-583] Netty reported memleak with view row buffers Created: 13/Oct/14  Updated: 22/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Simon Baslé
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This comes up when you do longer running view tests:

15:17:00.383 [cb-io-1-3] ERROR c.c.c.d.i.n.u.ResourceLeakDetector - 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.view.ViewHandler.parseViewRows(ViewHandler.java:380)
com.couchbase.client.core.endpoint.view.ViewHandler.parseQueryResponse(ViewHandler.java:264)
com.couchbase.client.core.endpoint.view.ViewHandler.decodeResponse(ViewHandler.java:189)
com.couchbase.client.core.endpoint.view.ViewHandler.decodeResponse(ViewHandler.java:66)
com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:152)
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:333)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)
com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:147)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
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)




[JCBC-602] Correctly handle CAS mismatches when remove with CAS is called. Created: 22/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Michael Nitschinger [ 22/Oct/14 ]
http://review.couchbase.org/#/c/42347/




[JCBC-601] Expose returned CAS value on remove() responses Created: 22/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Michael Nitschinger [ 22/Oct/14 ]
http://review.couchbase.org/#/c/42346/




[JCBC-600] Append/Prepend operations should return null for content in result Created: 22/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Sergey Avseyev Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Because we actually do not know the new value of the document, it must be completely clear for users that they should not utilize the content attribute from Response

Currently it returns new document with content from request

 Comments   
Comment by Michael Nitschinger [ 22/Oct/14 ]
http://review.couchbase.org/#/c/42348/




[JCBC-597] Refactor view mapping for better testability. Created: 21/Oct/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-539] Consider a way to expose target key nodes for user-level circuit breakers Created: 01/Sep/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File HelloWorld.java     Java Source File NodeLocator.java    
Issue Links:
Relates to
relates to CCBC-505 Allow user-side modification of node'... Open

 Comments   
Comment by Dan Douglas [ 02/Sep/14 ]
Attached hacked/reflected workaround I used to get locator information and simple HelloWorld showing usage.

As indicated, real usage is for creating Hystrix command wrappers around CB functions to do circuit breakers for resiliancy in the face of failing (but not yet failed over) nodes.
Comment by Matt Ingenthron [ 02/Sep/14 ]
Thanks Dan! This is something we've been discussing a bit and I really wonder if in general we want a "fast-fail" behavior to be defined. Maybe we need another word. Basic idea is that there are some use cases where people don't want to wait for the timeout value while the connection is known to be down. They want to fast-fail while that connection is attempted to be rebuilt. I didn't read all the code, but is this the kind of behavior you were going for by checking node status?
Comment by Dan Douglas [ 03/Sep/14 ]
Fail fast is one aspect.

However, our plan also calls for a policy driven fallback

- readFromReplica
- read/write to secondary cluster
- user supplied fallback

What I want is access to the locator data so I can associate a key with a node (both primary and replicas).

I don't intend to check the client's status of the node through any CB API. I'll identify the iffy nodes using the outcome of operations associated with them by wrapping them in Hystrix commands. The locator info is just to creat the name of the command.

For even more context, here’s a small deck describing the work I’m doing to add more resiliency to the DUKES wrapper we use for configuration and application monitoring of Couchbase. It includes a short six-minute embedded video demonstrating how the proposed implementation shields applications from badness when a CB node is failing, but has not yet failed over.
https://www.dropbox.com/s/8hue2za1kjje7zu/DUKESv2-Resiliant-Hystrix-Commands.pptx?dl=0 (156 MB)

Some folks have said that they’ve had trouble running the embedded video from the PPT. Here’s a direct link to the .mp4
https://www.dropbox.com/s/zaek5042bk3rhl0/DukesV2Demo.mp4?dl=0 (153 MB)

The NodeLocator implementation attached is what I’ll need to do in order to implement DUKESv2 onto of Couchbase SDK 2.0. I’m not really looking forward to maintaining the hack. I’m hoping to convince you to add back some sort of locator information to the SDK so that I won’t need to.
Comment by Mark Nunberg [ 03/Sep/14 ]
If I may chime in here a bit. The same feature has been requested for the C client library. I'd also say that rather than stuffing all the logic into the client library, providing the facilities and tools for a user to manage such a "circuit breaker" functionality.
Comment by Michael Nitschinger [ 20/Oct/14 ]
I've moved it to the next minor so we have time to revisit this in a good way, and not just patching it - this also requires a larger change in the core package, but we'll get there eventually.

Dan, I know you are doing through reflection right now is that good enough for you until we ship a solid solution with 2.1?
Comment by Dan Douglas [ 20/Oct/14 ]
sure... do it the right way. I can hack it through reflection until a supported way is avaiable. thanks




[JCBC-576] Add support for geo queries (combined with 3.0.1) Created: 07/Oct/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
provided should be: stale, limit, skip, range start, range end, debug on the DSL ranges need to be lists of numbers or null which indicates no start/end.

 Comments   
Comment by Michael Nitschinger [ 20/Oct/14 ]
Note that I expect official support in 2.1, the plan is that we'll develop a separate code/module for now to test it properly. Anyone interested please comment here and we'll also link it.




[JCBC-555] Add support for JsonValue.NULL on the transcoders and documents Created: 15/Sep/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-483] Add INFO level log of client version to startup Created: 27/Jun/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.2
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In CouchbaseClient <init> we log details from the CouchbaseConnectionFactory. It would also be useful to INFO level log the client version and the spymemcached version.

 Comments   
Comment by Matt Ingenthron [ 27/Jun/14 ]
Since it's such a minor change, setting it to 1.4.3. I'll defer to you on whether it should be pushed back or not.
Comment by Michael Nitschinger [ 30/Jun/14 ]
It's a little harder to do because there is the BuildInfo, but we need to make sure its properly in path and distributed with our jars. I'm not sure this is done right now but I could be wrong.

If we could defer it to 1.4.4 then it would be better to release 1.4.3 tomorrow.




[JCBC-504] Couchbase hangs during tomcat shutdown Created: 30/Jul/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.2, 1.4.3
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Major
Reporter: Benoit Beaudet Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Tomcat 7.0.45.


 Description   
Using couchbase lib inside a WAR. All clients connections are stopped by the application but Tomcat can't stop.
Tomcat stop process is blocked by a CouchbaseConfigConnection thread (deamon=false)

{code}
  java.lang.Thread.State: RUNNABLE
    at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
    at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
    at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
    at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
    - locked <0x0000000795b80af0> (a sun.nio.ch.Util$2)
    - locked <0x0000000795b80b00> (a java.util.Collections$UnmodifiableSet)
    - locked <0x0000000795b80aa8> (a sun.nio.ch.EPollSelectorImpl)
    at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
    at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:420)
    at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:321)
{code}


Looking a the bootstrap code from com.couchbase.client.vbucket.provider.BucketConfigurationProvider class.
A CouchbaseConfigConnection is created but not closed if everything is working fine.
{code}
private boolean tryBinaryBootstrapForNode(InetSocketAddress node)
    throws Exception

  connection = new CouchbaseConfigConnection(
        cf.getReadBufSize(), fact, Collections.singletonList(node),
        initialObservers, cf.getFailureMode(),
        cf.getOperationFactory()
      );

{code}



Hack to resolve the issue.
{code}
  private void killConfigConnection(){
        ThreadGroup rootGroup = Thread.currentThread( ).getThreadGroup( );
        ThreadGroup parentGroup;
        while ( ( parentGroup = rootGroup.getParent() ) != null ) {
            rootGroup = parentGroup;
        }

        Thread[] threads = new Thread[ rootGroup.activeCount() ];
        while ( rootGroup.enumerate( threads, true ) == threads.length ) {
            threads = new Thread[ threads.length * 2 ];
        }

        for (int i = 0; i < threads.length; i++){
            final Thread thread = threads[i];
            if(thread instanceof CouchbaseConfigConnection){
                final CouchbaseConfigConnection configConn = (CouchbaseConfigConnection) thread;
                try {
                    configConn.shutdown();
                } catch (final IOException e) {
                   //
                }
            }

        }
   
{code}

 Comments   
Comment by Michael Nitschinger [ 04/Aug/14 ]
Is that a duplicate of 503?
Comment by Benoit Beaudet [ 04/Aug/14 ]
This issue isn't a duplicate. A non deamon thread is still active in Tomcat. The CouchbaseConfigConnection used at boostrap should be shutdown.
Comment by Michael Nitschinger [ 05/Aug/14 ]
Hmm maybe I don't understand it. Do you call client.shutdown() or just shutdown tomcat? Because they are by intention non-daemon threads and you need to shutdown the client manually. or do you shut it down but some resources are not freed?
Comment by Benoit Beaudet [ 05/Aug/14 ]
I call client.shutdown in web context destroy event, but the CouchbaseConfigConnection isn't under my control and not freed.




[JCBC-478] Docs: Deferred view deployment instruction does not work Created: 17/Feb/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.0
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Minor
Reporter: Don Stacy Assignee: Amy Kurtzman
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Section: http://docs.couchbase.com/couchbase-sdk-java-1.3/#preview-the-application
Area: Text under step 2
Issues: We say that we will deploy the views to production later. However, the app will not work unless the views are in production. We should include the steps here or at least tell the reader to publish while pointing them to the View documentation.




[JCBC-507] Provide compatibility with 3.0 spatial views Created: 11/Aug/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In 3.0, the returned result doesn't contain a "bbox" property anymore. It was renamed to "key" to be more along the lines of the mapreduce views. The structure also changes a bit. The "bbox" was an array with 4 elements, with [min_x, min_y, max_x, max_y]. The key is an array containing the bounds of the dimensions, so it is: [[min_x, max_x], [min_x, max_y]].




[JCBC-508] PersistTo.TWO doesn't fail with single node cluster. Created: 11/Aug/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
In the observe poll part, the persist counter gets decremented which leads to a non-failing op on a single node cluster with PersistTo.TWO




[JCBC-510] Allow optional non-persistent view connections Created: 18/Aug/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-566] CouchbaseConnectionFactory cannot schedule configuration update Created: 23/Sep/14  Updated: 20/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.0-dp1, 1.4.0-dp2, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Major
Reporter: Sergey Avseyev Assignee: Sergey Avseyev
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File Hello.java    

 Description   
client is working with a cluster
network from client to cluster is disrupted (sudo service couchbase-server stop)
network from client to cluster is later restored (sudo service couchbase-server start)

expected behavior:
  client recovers and traffic proceeds a short time after the network is back to working
observed behavior:
  client does not recover

 Comments   
Comment by Sergey Avseyev [ 23/Sep/14 ]
http://review.couchbase.org/41585
Comment by Sergey Avseyev [ 23/Sep/14 ]
I've written that it affects versions since 1.4.0-dp1 because http://review.couchbase.org/32589 was relesed in 1.4.0-dp1 first time. I haven't verified all these releases, just 1.4.4.
Comment by Sergey Avseyev [ 26/Sep/14 ]
the real fix is here: http://review.couchbase.org/41674




[JCBC-567] The client might still use HTTP configuration provider to fetch JSON config Created: 28/Sep/14  Updated: 20/Oct/14

Status: New
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.4
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Major
Reporter: Sergey Avseyev Assignee: Sergey Avseyev
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Seems like the client forgets that it was using CCCP initially

For example in case of network failure, after restoring connectivity it skips CCCP and bootstraps using HTTP




[JCBC-588] Support TTL in Append & Prepend Operations Created: 14/Oct/14  Updated: 20/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Ian McCloy Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
Relates to
relates to PYCBC-261 Append and Prepend with TTL not suppo... Resolved

 Description   
The 1.4.4 Java SDK doesn't allow for updating the TTL in an Append operation, requiring 2 separate SDK calls, other couchbase SDKs such as the python client do support this. Please add this functionality.

 Comments   
Comment by Michael Nitschinger [ 15/Oct/14 ]
Investigating for 2.1
Comment by Michael Nitschinger [ 20/Oct/14 ]
Closing this because it is not available in the protocol and on the server side. Feel free to reopen when we add such functionality and need to bring it into the clients.




[JCBC-543] IllegalStateException: Node not found for requestcom.couchbase.client.core.message.binary.UpsertRequest Created: 05/Sep/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core, Infrastructure
Affects Version/s: 2.0-beta
Fix Version/s: 2.0.0
Security Level: Public

Type: Task Priority: Major
Reporter: Jeff Morris Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This could be user error, but when trying the couchbae hellworld tutorial: http://docs.couchbase.com/prebuilt/java-sdk-2.0-beta/topics/hello-couchbase.html, I receive the following exception:

Sep 05, 2014 10:30:02 AM com.couchbase.client.core.node.CouchbaseNode$5 call
INFO: Connected to Node 127.0.0.1
Sep 05, 2014 10:30:07 AM com.couchbase.client.core.node.CouchbaseNode$5 call
INFO: Disconnected from Node 127.0.0.1
Sep 05, 2014 10:30:07 AM com.couchbase.client.core.node.CouchbaseNode$5 call
INFO: Connected to Node jmorris-pc
Sep 05, 2014 10:30:07 AM com.couchbase.client.deps.com.lmax.disruptor.FatalExceptionHandler handleEventException
SEVERE: Exception processing: 2 com.couchbase.client.core.RequestEvent@7bcfceb7
java.lang.IllegalStateException: Node not found for requestcom.couchbase.client.core.message.binary.UpsertRequest@9c94115
at com.couchbase.client.core.node.locate.BinaryLocator.locateForCouchbaseBucket(BinaryLocator.java:126)
at com.couchbase.client.core.node.locate.BinaryLocator.locate(BinaryLocator.java:63)
at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:148)
at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:68)
at com.couchbase.client.deps.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

Exception in thread "pool-1-thread-2" java.lang.RuntimeException: java.lang.IllegalStateException: Node not found for requestcom.couchbase.client.core.message.binary.UpsertRequest@9c94115
at com.couchbase.client.deps.com.lmax.disruptor.FatalExceptionHandler.handleEventException(FatalExceptionHandler.java:45)
at com.couchbase.client.deps.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.IllegalStateException: Node not found for requestcom.couchbase.client.core.message.binary.UpsertRequest@9c94115
at com.couchbase.client.core.node.locate.BinaryLocator.locateForCouchbaseBucket(BinaryLocator.java:126)
at com.couchbase.client.core.node.locate.BinaryLocator.locate(BinaryLocator.java:63)
at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:148)
at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:68)
at com.couchbase.client.deps.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
... 3 more

Additional logging included. I am connecting to localhost CB server 2.5.




[JCBC-592] Documentation: Installation instructions for Java SDK incorrectly indicates 2.0 is in beta Created: 15/Oct/14  Updated: 16/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Task Priority: Minor
Reporter: Ian McCloy Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: doc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
http://docs.couchbase.com/developer/java-2.0/download-install.html
"Currently, the Java SDK is in a beta release state", 2.0 Java SDK isn't in Beta




[JCBC-590] Properly wire up the RawJsonTranscoder on bootstrap Created: 14/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-587] StartKeyDocID and EndKeyDocID should never be quoted Created: 14/Oct/14  Updated: 15/Oct/14  Resolved: 15/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-573] Sell role went down after 24 to 32 hours with Illegal state exception :Timed out waiting to add Cmd Created: 02/Oct/14  Updated: 15/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Rukmini Nagarajaiah Assignee: James Mauss
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Current release, we had enabled write to couchbase turned ON. Couchbase regression was fine in QA and PE env. It was fine even in Production intially, but after 24 to 30 hours of deployemnt, we started seeing below exceptions and blade went down. Sell flow was redirecting to error page.
Need to know why is this happening. Once we restart the application server exception doesnt show up.
But we are sure, it will start happening soon

2014-10-02 00:26:34,000 [c49a#1061c/https:///sell/] priority=ERROR app_name=stubhubSLXRole thread=ajp-0.0.0.0-8009-41 location=NewAccessControlHandler line=175 Exception
java.lang.IllegalStateException: Timed out waiting to add Cmd: 1 Opaque: 1147840 Key: com.stubhub.user.business.entity.UserSession|63C21A07311389A1EC361D834BF46E72 Cas: 0 Exp: 7200 Flags: 1 Data Length: 1748(max wait=10000ms)
at net.spy.memcached.protocol.TCPMemcachedNodeImpl.addOp(TCPMemcachedNodeImpl.java:362)
at net.spy.memcached.MemcachedConnection.addOperation(MemcachedConnection.java:1267)
at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:277)
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:1185)
at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:328)
at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:929)
at com.stubhub.common.cache.store.couchbase.CouchbaseStore.put(CouchbaseStore.java:148)
at com.stubhub.common.cache.store.CompositeCacheStore.put(CompositeCacheStore.java:69)
at com.stubhub.common.session.impl.UserSessionCacheManagerImpl.putCrossModuleValue(UserSessionCacheManagerImpl.java:48)
at com.stubhub.user.business.manager.impl.UserSessionCacheMgrImpl.putUserSessionToStore(UserSessionCacheMgrImpl.java:269)
at com.stubhub.user.business.manager.impl.UserSessionCacheMgrImpl.createUserSession(UserSessionCacheMgrImpl.java:806)
at sun.reflect.GeneratedMethodAccessor1305.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at com.stubhub.common.util.StubHubPerformanceMonitorInterceptor.invoke(StubHubPerformanceMonitorInterceptor.java:28)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy725.createUserSession(Unknown Source)
at com.stubhub.user.business.facade.impl.UserSessionFacadeImpl.createUnidentifiedSession(UserSessionFacadeImpl.java:564)
at com.stubhub.user.business.facade.impl.UserSessionFacadeImpl.createUnidentifiedSession(UserSessionFacadeImpl.java:94)
at sun.reflect.GeneratedMethodAccessor1297.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

 Comments   
Comment by Mike Wiederhold [ 02/Oct/14 ]
Note that this happened on Couchbase 2.5.1, but the reporter did not include the sdk version.
Comment by Rukmini Nagarajaiah [ 02/Oct/14 ]
Yes.. We are using couchbase-server-2.5.1-1083.x86_64 version
Below are the client and spymemcached version
<dependency>
<groupId>com.couchbase.client</groupId>
<artifactId>couchbase-client</artifactId>
<version>1.4.4</version>
</dependency>

<dependency>
<groupId>net.spy</groupId>
<artifactId>spymemcached</artifactId>
<version>2.11.4</version>
</dependency>
Comment by Rukmini Nagarajaiah [ 15/Oct/14 ]
any updated on this?




[JCBC-317] Implement a multi delete operation Created: 11/Jun/13  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.7
Fix Version/s: 2.1.0
Security Level: Public

Type: New Feature Priority: Minor
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JCBC-538 Consider adding bulk APIs Open

 Description   
It would be useful to provide a multi delete operation in the Couchbase Java API (and other SDK) this has been done inthe Python SDK:
https://github.com/couchbase/couchbase-python-client/blob/master/tests/test_delete.py#L73






[JCBC-538] Consider adding bulk APIs Created: 01/Sep/14  Updated: 14/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JCBC-317 Implement a multi delete operation Resolved




[JCBC-586] Provide more descriptive exceptions for invalid bucket names and auth failures Created: 14/Oct/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-585] Poll for all node "healthy" on bucket creation before reporting success Created: 14/Oct/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-584] Correctly forward ConfigurationException (do not encapsulate with Composite) Created: 14/Oct/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-581] Add think time to integration tests to avoid bucket failures Created: 13/Oct/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-582] Bucket details loading fails if bucket > 2gb Created: 13/Oct/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-580] Custom equals for documents and JsonObject/JsonArray Created: 13/Oct/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-531] Expose Diagnostics and debug dump them on startup Created: 26/Aug/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.5
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-579] Custom equals for design document and views for easier comparability. Created: 09/Oct/14  Updated: 13/Oct/14  Resolved: 13/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-542] Handle TMPFAIL and expose it Created: 04/Sep/14  Updated: 13/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-518] no intro page on the javadoc Created: 18/Aug/14  Updated: 13/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 2.0-dp3
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Sergey Avseyev
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Goal is to have the index page for the javadoc give an introductory overview so a developer knows which class to begin with. The 1.4 javadoc does this already, but the 2.0 doesn't have introductory HTML getting built in to the project. At a minimum, it should describe accessing a cluster and a bucket with a code sample that can be cut and paste into a working program.

 Comments   
Comment by Matt Ingenthron [ 13/Sep/14 ]
Sergey: This should be an easy one. There is a similar change on the release14 branch.




[JCBC-533] Add documentation for 1.x migration Created: 28/Aug/14  Updated: 13/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 13/Sep/14 ]
disregard my earlier comment on this sergey.




[JCBC-535] Add documentation on different document types Created: 28/Aug/14  Updated: 13/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-578] Correctly validate bucket name before connecting. Created: 09/Oct/14  Updated: 09/Oct/14  Resolved: 09/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-577] Couchbase Java client 1.4.4 leaks in netty IO threads Created: 08/Oct/14  Updated: 08/Oct/14

Status: New
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: talkganga Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: performance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: production


 Description   
I have been experiencing similar issues with 1.4.4 where netty IO threads are in WAIT state. Its frustrating that we cannot reproduce this issue in LnP but in production during heavy traffic hours we are experiencing this issue. When this issue occurs the application server will no longer be taking any traffic and just restarting app server won't help instead we had to reboot the VM to kill those dangling connections.
Here is the stack from the thread dump we took when this issue happened.

Thread Name
Couchbase View Thread for node cbnibslc02-289848/10.120.159.104:8092
State
Waiting on condition
Java Stack
at sun/nio/ch/EPollArrayWrapper.epollWait(Native Method)
at sun/nio/ch/EPollArrayWrapper.poll(EPollArrayWrapper.java:228(Compiled Code))
at sun/nio/ch/EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81(Compiled Code))
at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:87(Compiled Code))
at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:98(Compiled Code))
at org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:305)
at com/couchbase/client/http/AsyncConnectionManager.execute(AsyncConnectionManager.java:89)
at com/couchbase/client/ViewNode$1.run(ViewNode.java:89)
at java/lang/Thread.run(Thread.java:780)
Native Stack
(0x00007F0D06106052 [libj9prt26.so+0x13052])
(0x00007F0D061136CF [libj9prt26.so+0x206cf])
(0x00007F0D06105D9B [libj9prt26.so+0x12d9b])
(0x00007F0D06105E97 [libj9prt26.so+0x12e97])
(0x00007F0D061136CF [libj9prt26.so+0x206cf])
(0x00007F0D061059BB [libj9prt26.so+0x129bb])
(0x00007F0D060FF812 [libj9prt26.so+0xc812])
(0x00007F0D07252B40 [libpthread.so.0+0xfb40])
pthread_cond_wait+0xca (0x00007F0D0724EA9A [libpthread.so.0+0xba9a])
(0x00007F0D0634D0CF [libj9thr26.so+0x80cf])
(0x00007F0D064BA859 [libj9vm26.so+0x63859])
(0x00007F0D052DE6D9 [libj9jit26.so+0x5b96d9])

thanks




[JCBC-550] Java 2.0 SDK Test Shows High Latency and Error on Timeouts Created: 11/Sep/14  Updated: 08/Oct/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Critical
Reporter: Wei-Li Liu Assignee: Sergey Avseyev
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
This is a known issue and a fix is coming soon.
I work around the issue by waiting a bit longer between ops. It does reduces the number of backpressue exceptions.

Will run the test again after the fix is pushed.


 Comments   
Comment by Michael Nitschinger [ 19/Sep/14 ]
Moving this to 2.0.1 and non blocker because it seems to be a bug in the user code.
Comment by Matt Ingenthron [ 23/Sep/14 ]
Sergey: While Michael is out, can you look at this with Wei-Li?




[JCBC-575] Add Document for Raw JSON content (supporting custom JSON libs) Created: 07/Oct/14  Updated: 08/Oct/14  Resolved: 08/Oct/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-569] The latest Java API points to 1.4.3 and not 1.4.4. Created: 29/Sep/14  Updated: 29/Sep/14  Resolved: 29/Sep/14

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Patrick Varley Assignee: Amy Kurtzman
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/autodocs/couchbase-java-client-latest/index.html


 Description   
The link from the documentation menu is:

http://www.couchbase.com/autodocs/couchbase-java-client-latest/index.html

Which brings you to:

http://www.couchbase.com/autodocs/couchbase-java-client-1.4.3/index.html

When I tried to go to 1.4.4 by hand I got redirect back to the home page:

http://www.couchbase.com/autodocs/couchbase-java-client-1.4.4/index.html





[JCBC-571] View query with a lot of keys in the parameter does not use POST method Created: 29/Sep/14  Updated: 29/Sep/14

Status: New
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Subhashni Balakrishnan Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
2.0 java client fails this test http://review.couchbase.org/#/c/41725/




[JCBC-570] set(key, exp, value, ReplicateTo.ONE, ReplicateTo.ZERO) does not seem to provide sufficient detail for robust error handling Created: 29/Sep/14  Updated: 29/Sep/14

Status: New
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: m0thra Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
It looks like that call leads to asyncObserveStore(key, setOp, req, rep, "Set", false) in CouchbaseClient.

Then if an exception is thrown from the observePoll at line 1443, it is handled and an OperationStatus object is made for the caller. But there is no status code set up. So the only way for the caller to tell what happened it to interrogate the message. Having my calling code looking for specific messages does not feel robust. Can we get some kind of fixed set of codes (perhaps new StatusCode values) to look for?

{code}
1442 try {
1443 observePoll(key, future.getCas(), req, rep, delete);
1444 observeFuture.set(true, future.getStatus());
1445 } catch (ObservedException e) {
1446 observeFuture.set(false, new OperationStatus(false, e.getMessage()));
1447 } catch (ObservedTimeoutException e) {
1448 observeFuture.set(false, new OperationStatus(false, e.getMessage()));
1449 } catch (ObservedModifiedException e) {
1450 observeFuture.set(false, new OperationStatus(false, e.getMessage()));
1451 }
{code}

 Comments   
Comment by m0thra [ 29/Sep/14 ]
The reason this is causing me problems is that I want to code specific handling for "ObserveModifiedException". It is correct to assume that in this case the write succeeded?




[JCBC-568] Client hanged at shutdown Created: 29/Sep/14  Updated: 29/Sep/14

Status: New
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.3
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: Alexander Paschenko Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
This issue is marked as minor because it's been observed only once and we haven't been able to reproduce it since then.
The component using couchbase failed to shut down gracefully, and, after analyzing stacktrace, following two blocked couchbase threads were noticed - their stack traces follow:

First:

"New I/O worker #14" prio=10 tid=0x00007fcdfc159000 nid=0x409 waiting for monitor entry [0x00007fcddb6f5000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucket(ConfigurationProviderHTTP.java:125)
- waiting to lock <0x0000000745f9d2a8> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP)
at com.couchbase.client.vbucket.BucketMonitor.notifyDisconnected(BucketMonitor.java:118)
at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:187)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(ReplayingDecoder.java:573)
at org.jboss.netty.handler.codec.frame.FrameDecoder.channelDisconnected(FrameDecoder.java:366)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:107)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.Channels.fireChannelDisconnected(Channels.java:399)
at org.jboss.netty.channel.Channels$4.run(Channels.java:389)
at org.jboss.netty.channel.socket.ChannelRunnableWrapper.run(ChannelRunnableWrapper.java:41)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processEventQueue(AbstractNioWorker.java:378)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:259)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662) Locked ownable synchronizers: - <0x0000000745dca468> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)


Second:

"HttpConfigurationProvider Reloader" prio=10 tid=0x00007fcde406d800 nid=0x406 waiting on condition [0x00007fcddb8f7000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000745d30978> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getReceivedFuture(BucketUpdateResponseHandler.java:149)
at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getLastResponse(BucketUpdateResponseHandler.java:129)
at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:219)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:339)
- locked <0x0000000745f9d2a8> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP)
at com.couchbase.client.vbucket.provider.BucketConfigurationProvider.monitorBucket(BucketConfigurationProvider.java:361)
at com.couchbase.client.vbucket.provider.BucketConfigurationProvider.access$900(BucketConfigurationProvider.java:65)
at com.couchbase.client.vbucket.provider.BucketConfigurationProvider$HttpProviderRefresher.run(BucketConfigurationProvider.java:610)
at java.lang.Thread.run(Thread.java:662) Locked ownable synchronizers: - None

Hope some light can be shed on this strange behavior.
Thank you very much in advance!




[JCBC-501] Implement Support for DCP Created: 29/Jul/14  Updated: 26/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: New Feature Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Implement support for 3.0+ DCP as a replacement for the TAP protocol and TAP Client.

To be a suitable replacement, this has a few additional requirements to meet current TAP features:
* It must be able to use buckets with authentication/passwords in addition to the default bucket
* It must be able to target active data only, rather than active and replica data
* We must be able to split/filter to individual nodes from the client interface. It may also be useful for this to be at the vbucket level.

The use case for the latter is that in some cases, such a job may be split across many client nodes reading data from a cluster with many nodes. By allowing the application code using this client library for DCP to split along these lines, it can manage how the job is run for maximum parallelism.




[JCBC-502] Sometimes couchbase client stuck Created: 29/Jul/14  Updated: 21/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Infrastructure
Affects Version/s: 2.0-dp2
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Oded Hassidi Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Mac OSX as client


 Description   
Sometimes I run the client like in the examples in the community blog and the client stuck and Doesn't return. To validate that I run the client several times one after the the other and sometimes it get stuck and some don't

 Comments   
Comment by Michael Nitschinger [ 11/Aug/14 ]
Can you provide logging with level set to FINEST? that would be of great help, thanks.
Comment by Oded Hassidi [ 12/Aug/14 ]
I am running my test in a main, and I have debug level entries. Is that enough?
Comment by Michael Nitschinger [ 12/Aug/14 ]
Yes send over whatever you have, and the code would also be good.
Comment by Oded Hassidi [ 12/Aug/14 ]
Code:


public class Main {
public static void main(String[] args) throws IOException {
      
        System.setProperty("com.couchbase.client.queryEnabled", "true");

        CouchbaseCluster cc = new CouchbaseCluster("obbe-centos3.tlv.lpnet.com", "obbe-centos1.tlv.lpnet.com", "obbe-centos2.tlv.lpnet.com");

        final Bucket[] bucket = new CouchbaseBucket[1];
        System.out.println("******** Opening the Bucket");
        cc.openBucket("visitors-odedh").subscribe(b -> {
            System.out.println("################### Bucket is opened: ");
                System.out.println(b.toString());
                bucket[0] = b;
        });


        System.out.println("enter something: ");
        System.in.read();
    }
}



log:

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java -Didea.launcher.port=7534 "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA 14 EAP.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath "/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/htmlconverter.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Users/odedh/Projects/visitorfeed/branches/n1ql/dal/target/classes:/Users/odedh/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar:/Users/odedh/.m2/repository/ch/qos/logback/logback-core/1.1.2/logback-core-1.1.2.jar:/Users/odedh/.m2/repository/org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar:/Users/odedh/Projects/visitorfeed/branches/n1ql/dao/target/classes:/Users/odedh/.m2/repository/com/liveperson/framework/rest-api-data-objects/2.0.2.11/rest-api-data-objects-2.0.2.11.jar:/Users/odedh/.m2/repository/com/liveperson/RestApiCommon/1.0.2-6/RestApiCommon-1.0.2-6.jar:/Users/odedh/.m2/repository/com/sun/jersey/jersey-core/1.9.1/jersey-core-1.9.1.jar:/Users/odedh/.m2/repository/com/sun/jersey/jersey-client/1.9.1/jersey-client-1.9.1.jar:/Users/odedh/.m2/repository/com/sun/jersey/jersey-server/1.9.1/jersey-server-1.9.1.jar:/Users/odedh/.m2/repository/asm/asm/3.1/asm-3.1.jar:/Users/odedh/.m2/repository/com/sun/jersey/jersey-json/1.9.1/jersey-json-1.9.1.jar:/Users/odedh/.m2/repository/org/codehaus/jettison/jettison/1.1/jettison-1.1.jar:/Users/odedh/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar:/Users/odedh/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.3-1/jaxb-impl-2.2.3-1.jar:/Users/odedh/.m2/repository/javax/xml/bind/jaxb-api/2.2.2/jaxb-api-2.2.2.jar:/Users/odedh/.m2/repository/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar:/Users/odedh/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:/Users/odedh/.m2/repository/org/codehaus/jackson/jackson-core-asl/1.8.3/jackson-core-asl-1.8.3.jar:/Users/odedh/.m2/repository/org/codehaus/jackson/jackson-mapper-asl/1.8.3/jackson-mapper-asl-1.8.3.jar:/Users/odedh/.m2/repository/org/codehaus/jackson/jackson-jaxrs/1.8.3/jackson-jaxrs-1.8.3.jar:/Users/odedh/.m2/repository/org/codehaus/jackson/jackson-xc/1.8.3/jackson-xc-1.8.3.jar:/Users/odedh/.m2/repository/org/apache/commons/commons-lang3/3.1/commons-lang3-3.1.jar:/Users/odedh/.m2/repository/org/springframework/spring-context/4.0.6.RELEASE/spring-context-4.0.6.RELEASE.jar:/Users/odedh/.m2/repository/org/springframework/spring-aop/4.0.6.RELEASE/spring-aop-4.0.6.RELEASE.jar:/Users/odedh/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/odedh/.m2/repository/org/springframework/spring-beans/4.0.6.RELEASE/spring-beans-4.0.6.RELEASE.jar:/Users/odedh/.m2/repository/org/springframework/spring-core/4.0.6.RELEASE/spring-core-4.0.6.RELEASE.jar:/Users/odedh/.m2/repository/org/springframework/spring-expression/4.0.6.RELEASE/spring-expression-4.0.6.RELEASE.jar:/Users/odedh/.m2/repository/com/couchbase/client/couchbase-client/2.0.0-dp2/couchbase-client-2.0.0-dp2.jar:/Users/odedh/.m2/repository/com/couchbase/client/core-io/0.2/core-io-0.2.jar:/Users/odedh/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.4.0/jackson-databind-2.4.0.jar:/Users/odedh/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.4.0/jackson-annotations-2.4.0.jar:/Users/odedh/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.4.0/jackson-core-2.4.0.jar:/Users/odedh/.m2/repository/com/lmax/disruptor/3.2.1/disruptor-3.2.1.jar:/Users/odedh/.m2/repository/com/netflix/rxjava/rxjava-core/0.19.2/rxjava-core-0.19.2.jar:/Users/odedh/.m2/repository/com/typesafe/config/1.2.1/config-1.2.1.jar:/Users/odedh/.m2/repository/io/netty/netty-all/4.0.21.Final/netty-all-4.0.21.Final.jar:/Users/odedh/.m2/repository/com/google/code/gson/gson/2.2.4/gson-2.2.4.jar:/Users/odedh/.m2/repository/org/springframework/spring-test/4.0.6.RELEASE/spring-test-4.0.6.RELEASE.jar:/Users/odedh/.m2/repository/com/liveperson/SnmpMonitoring/4.0.0.1/SnmpMonitoring-4.0.0.1.jar:/Users/odedh/.m2/repository/com/liveperson/SnmpMonitoring-api/4.0.0.1/SnmpMonitoring-api-4.0.0.1.jar:/Users/odedh/.m2/repository/org/apache/xmlbeans/xmlbeans/2.4.0/xmlbeans-2.4.0.jar:/Users/odedh/.m2/repository/com/liveperson/ServiceStatus/3.0.0.2/ServiceStatus-3.0.0.2.jar:/Users/odedh/.m2/repository/com/liveperson/ServiceStatus-API/3.0.0.2/ServiceStatus-API-3.0.0.2.jar:/Applications/IntelliJ IDEA 14 EAP.app/Contents/lib/idea_rt.jar" com.intellij.rt.execution.application.AppMain com.liveperson.visitorfeed.dal.couchbase.CouchbaseVisitorDao
15:55:05.598 [main] DEBUG i.n.u.i.l.InternalLoggerFactory - Using SLF4J as the default logging framework
15:55:05.604 [main] DEBUG i.n.c.MultithreadEventLoopGroup - -Dio.netty.eventLoopThreads: 16
15:55:05.616 [main] DEBUG i.n.util.internal.PlatformDependent0 - java.nio.Buffer.address: available
15:55:05.616 [main] DEBUG i.n.util.internal.PlatformDependent0 - sun.misc.Unsafe.theUnsafe: available
15:55:05.617 [main] DEBUG i.n.util.internal.PlatformDependent0 - sun.misc.Unsafe.copyMemory: available
15:55:05.617 [main] DEBUG i.n.util.internal.PlatformDependent0 - java.nio.Bits.unaligned: true
15:55:05.624 [main] DEBUG i.n.util.internal.PlatformDependent - UID: 733553586
15:55:05.624 [main] DEBUG i.n.util.internal.PlatformDependent - Java version: 8
15:55:05.625 [main] DEBUG i.n.util.internal.PlatformDependent - -Dio.netty.noUnsafe: false
15:55:05.625 [main] DEBUG i.n.util.internal.PlatformDependent - sun.misc.Unsafe: available
15:55:05.625 [main] DEBUG i.n.util.internal.PlatformDependent - -Dio.netty.noJavassist: false
15:55:05.625 [main] DEBUG i.n.util.internal.PlatformDependent - Javassist: unavailable
15:55:05.626 [main] DEBUG i.n.util.internal.PlatformDependent - You don't have Javassist in your class path or you don't have enough permission to load dynamically generated classes. Please check the configuration for better performance.
15:55:05.626 [main] DEBUG i.n.util.internal.PlatformDependent - -Dio.netty.tmpdir: /var/folders/5f/wk7ckrbx1f30521n8rtxndzwnvk8xk/T (java.io.tmpdir)
15:55:05.626 [main] DEBUG i.n.util.internal.PlatformDependent - -Dio.netty.bitMode: 64 (sun.arch.data.model)
15:55:05.626 [main] DEBUG i.n.util.internal.PlatformDependent - -Dio.netty.noPreferDirect: false
15:55:05.640 [main] DEBUG io.netty.channel.nio.NioEventLoop - -Dio.netty.noKeySetOptimization: false
15:55:05.640 [main] DEBUG io.netty.channel.nio.NioEventLoop - -Dio.netty.selectorAutoRebuildThreshold: 512
15:55:05.712 [main] DEBUG c.c.c.c.config.ConfigurationProvider - Setting seed hosts to [obbe-centos1.tlv.lpnet.com/192.168.15.120, obbe-centos3.tlv.lpnet.com/192.168.15.190, obbe-centos2.tlv.lpnet.com/192.168.15.2]
******** Opening the Bucket
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.numHeapArenas: 8
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.numDirectArenas: 8
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.pageSize: 8192
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.maxOrder: 11
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.chunkSize: 16777216
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.tinyCacheSize: 512
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.smallCacheSize: 256
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.normalCacheSize: 64
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.maxCachedBufferCapacity: 32768
15:55:05.754 [RxComputationThreadPool-1] DEBUG i.n.buffer.PooledByteBufAllocator - -Dio.netty.allocator.cacheTrimInterval: 8192
enter something:
15:55:05.780 [RxComputationThreadPool-1] DEBUG i.n.util.internal.ThreadLocalRandom - -Dio.netty.initialSeedUniquifier: 0x9729d41313197dd7
15:55:05.785 [RxComputationThreadPool-1] DEBUG i.n.channel.ChannelOutboundBuffer - -Dio.netty.threadLocalDirectBufferSize: 65536
15:55:05.786 [RxComputationThreadPool-1] DEBUG io.netty.util.Recycler - -Dio.netty.recycler.maxCapacity.default: 262144
15:55:05.795 [RxComputationThreadPool-1] DEBUG io.netty.buffer.ByteBufUtil - -Dio.netty.allocator.type: unpooled
15:55:05.880 [nioEventLoopGroup-2-2] DEBUG io.netty.util.ResourceLeakDetector - -Dio.netty.leakDetectionLevel: simple
15:55:05.981 [nioEventLoopGroup-2-2] DEBUG io.netty.util.internal.Cleaner0 - java.nio.ByteBuffer.cleaner(): available
15:55:05.983 [nioEventLoopGroup-2-2] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos1.tlv.lpnet.com/192.168.15.120:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-1] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos1.tlv.lpnet.com/192.168.15.120:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-8] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos2.tlv.lpnet.com/192.168.15.2:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-7] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos2.tlv.lpnet.com/192.168.15.2:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-5] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos3.tlv.lpnet.com/192.168.15.190:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-4] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos3.tlv.lpnet.com/192.168.15.190:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-6] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos3.tlv.lpnet.com/192.168.15.190:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-3] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos1.tlv.lpnet.com/192.168.15.120:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.983 [nioEventLoopGroup-2-8] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos2.tlv.lpnet.com/192.168.15.2:11210
15:55:05.983 [nioEventLoopGroup-2-2] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos1.tlv.lpnet.com/192.168.15.120:11210
15:55:05.983 [nioEventLoopGroup-2-1] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos1.tlv.lpnet.com/192.168.15.120:11210
15:55:05.983 [nioEventLoopGroup-2-7] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos2.tlv.lpnet.com/192.168.15.2:11210
15:55:05.983 [nioEventLoopGroup-2-5] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos3.tlv.lpnet.com/192.168.15.190:11210
15:55:05.983 [nioEventLoopGroup-2-4] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos3.tlv.lpnet.com/192.168.15.190:11210
15:55:05.984 [nioEventLoopGroup-2-6] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos3.tlv.lpnet.com/192.168.15.190:11210
15:55:05.984 [nioEventLoopGroup-2-3] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos1.tlv.lpnet.com/192.168.15.120:11210
15:55:05.984 [nioEventLoopGroup-2-2] INFO com.couchbase.client.core.node.Node - Disconnected from Node obbe-centos1.tlv.lpnet.com/192.168.15.120
15:55:05.984 [nioEventLoopGroup-2-8] INFO com.couchbase.client.core.node.Node - Disconnected from Node obbe-centos2.tlv.lpnet.com/192.168.15.2
15:55:05.984 [nioEventLoopGroup-2-5] INFO com.couchbase.client.core.node.Node - Disconnected from Node obbe-centos3.tlv.lpnet.com/192.168.15.190
15:55:05.984 [nioEventLoopGroup-2-2] DEBUG com.couchbase.client.core.node.Node - Disconnected (CONNECTING) from Node obbe-centos1.tlv.lpnet.com/192.168.15.120
15:55:05.984 [nioEventLoopGroup-2-8] DEBUG com.couchbase.client.core.node.Node - Disconnected (CONNECTING) from Node obbe-centos2.tlv.lpnet.com/192.168.15.2
15:55:05.985 [nioEventLoopGroup-2-5] DEBUG com.couchbase.client.core.node.Node - Disconnected (CONNECTING) from Node obbe-centos3.tlv.lpnet.com/192.168.15.190
15:55:05.985 [nioEventLoopGroup-2-2] DEBUG c.c.client.core.service.Service - Connected (DEGRADED) to BinaryService obbe-centos1.tlv.lpnet.com
15:55:05.985 [nioEventLoopGroup-2-1] DEBUG c.c.c.c.e.binary.BinaryHelloClient - obbe-centos2.tlv.lpnet.com/192.168.15.2:11210 Hello not successful (Response Status: 129), falling back to no datatype.
15:55:05.985 [nioEventLoopGroup-2-5] DEBUG c.c.client.core.service.Service - Connected (DEGRADED) to BinaryService obbe-centos3.tlv.lpnet.com
15:55:05.985 [nioEventLoopGroup-2-2] INFO com.couchbase.client.core.node.Node - Connected to Node obbe-centos1.tlv.lpnet.com/192.168.15.120
15:55:05.985 [nioEventLoopGroup-2-1] DEBUG c.c.client.core.endpoint.Endpoint - Connected to BinaryEndpoint obbe-centos2.tlv.lpnet.com/192.168.15.2:11210
15:55:05.985 [nioEventLoopGroup-2-5] INFO com.couchbase.client.core.node.Node - Connected to Node obbe-centos3.tlv.lpnet.com/192.168.15.190
15:55:05.985 [nioEventLoopGroup-2-2] DEBUG com.couchbase.client.core.node.Node - Connected (DISCONNECTED) to Node obbe-centos1.tlv.lpnet.com/192.168.15.120
15:55:05.985 [nioEventLoopGroup-2-1] DEBUG c.c.client.core.service.Service - Connected (DEGRADED) to BinaryService obbe-centos2.tlv.lpnet.com
15:55:05.985 [nioEventLoopGroup-2-5] DEBUG com.couchbase.client.core.node.Node - Connected (DISCONNECTED) to Node obbe-centos3.tlv.lpnet.com/192.168.15.190
15:55:05.985 [nioEventLoopGroup-2-1] INFO com.couchbase.client.core.node.Node - Connected to Node obbe-centos2.tlv.lpnet.com/192.168.15.2
15:55:05.985 [nioEventLoopGroup-2-1] DEBUG com.couchbase.client.core.node.Node - Connected (DISCONNECTED) to Node obbe-centos2.tlv.lpnet.com/192.168.15.2
15:55:05.994 [pool-1-thread-1] DEBUG c.c.c.c.config.loader.CarrierLoader - Successfully loaded config through carrier.
15:55:05.996 [pool-1-thread-1] DEBUG c.c.c.c.config.loader.CarrierLoader - Successfully loaded config through carrier.
15:55:06.238 [RxComputationThreadPool-2] DEBUG c.c.c.c.config.ConfigurationProvider - Applying new configuration DefaultCouchbaseBucketConfig{name='visitors-odedh', locator=null, uri='/pools/default/buckets/visitors-odedh?bucket_uuid=b496dc8a7cbae31046c914fff06dea2f', streamingUri='/pools/default/bucketsStreaming/visitors-odedh?bucket_uuid=b496dc8a7cbae31046c914fff06dea2f', nodeInfo=[NodeInfo{viewUri='http://obbe-centos1.tlv.lpnet.com:8092/visitors-odedh&#39;, hostname=obbe-centos1.tlv.lpnet.com/192.168.15.120, configPort=8091, directServices={VIEW=8092, CONFIG=8091, BINARY=11210}, sslServices={}}, NodeInfo{viewUri='http://obbe-centos2.tlv.lpnet.com:8092/visitors-odedh&#39;, hostname=obbe-centos2.tlv.lpnet.com/192.168.15.2, configPort=8091, directServices={VIEW=8092, CONFIG=8091, BINARY=11210}, sslServices={}}, NodeInfo{viewUri='http://obbe-centos3.tlv.lpnet.com:8092/visitors-odedh&#39;, hostname=obbe-centos3.tlv.lpnet.com/192.168.15.190, configPort=8091, directServices={VIEW=8092, CONFIG=8091, BINARY=11210}, sslServices={}}], partitionInfo=PartitionInfo{numberOfReplicas=1, partitionHosts=[obbe-centos1.tlv.lpnet.com, obbe-centos2.tlv.lpnet.com, obbe-centos3.tlv.lpnet.com], partitions=[[m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [1]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 0, r: [2]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [0]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 1, r: [2]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [0]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]], [m: 2, r: [1]]], forwardPartitions=[]}, tainted=false, rev=2070}
15:55:06.256 [nioEventLoopGroup-2-7] DEBUG c.c.client.core.endpoint.Endpoint - Connected to ConfigEndpoint obbe-centos2.tlv.lpnet.com/192.168.15.2:8091
15:55:06.257 [nioEventLoopGroup-2-7] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to ConfigService obbe-centos2.tlv.lpnet.com
15:55:06.257 [nioEventLoopGroup-2-4] DEBUG c.c.client.core.endpoint.Endpoint - Connected to ConfigEndpoint obbe-centos1.tlv.lpnet.com/192.168.15.120:8091
15:55:06.257 [nioEventLoopGroup-2-4] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to ConfigService obbe-centos1.tlv.lpnet.com
15:55:06.257 [nioEventLoopGroup-2-6] DEBUG c.c.client.core.endpoint.Endpoint - Connected to ViewEndpoint obbe-centos2.tlv.lpnet.com/192.168.15.2:8092
15:55:06.257 [nioEventLoopGroup-2-6] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to ViewService obbe-centos2.tlv.lpnet.com
15:55:06.258 [nioEventLoopGroup-2-1] DEBUG c.c.client.core.endpoint.Endpoint - Connected to ViewEndpoint obbe-centos3.tlv.lpnet.com/192.168.15.190:8092
15:55:06.258 [nioEventLoopGroup-2-1] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to ViewService obbe-centos3.tlv.lpnet.com
15:55:06.258 [nioEventLoopGroup-2-3] DEBUG c.c.client.core.endpoint.Endpoint - Connected to ViewEndpoint obbe-centos1.tlv.lpnet.com/192.168.15.120:8092
15:55:06.259 [nioEventLoopGroup-2-3] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to ViewService obbe-centos1.tlv.lpnet.com
15:55:06.266 [nioEventLoopGroup-2-2] DEBUG c.c.client.core.endpoint.Endpoint - Connected to QueryEndpoint obbe-centos1.tlv.lpnet.com/192.168.15.120:8093
15:55:06.266 [nioEventLoopGroup-2-5] DEBUG c.c.client.core.endpoint.Endpoint - Connected to QueryEndpoint obbe-centos2.tlv.lpnet.com/192.168.15.2:8093
15:55:06.266 [nioEventLoopGroup-2-2] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to QueryService obbe-centos1.tlv.lpnet.com
15:55:06.266 [nioEventLoopGroup-2-5] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to QueryService obbe-centos2.tlv.lpnet.com
15:55:06.266 [nioEventLoopGroup-2-8] DEBUG c.c.client.core.endpoint.Endpoint - Connected to QueryEndpoint obbe-centos3.tlv.lpnet.com/192.168.15.190:8093
15:55:06.266 [nioEventLoopGroup-2-2] INFO com.couchbase.client.core.node.Node - Connected to Node obbe-centos1.tlv.lpnet.com/192.168.15.120
15:55:06.266 [nioEventLoopGroup-2-5] INFO com.couchbase.client.core.node.Node - Connected to Node obbe-centos2.tlv.lpnet.com/192.168.15.2
15:55:06.266 [nioEventLoopGroup-2-8] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to QueryService obbe-centos3.tlv.lpnet.com
15:55:06.266 [nioEventLoopGroup-2-2] DEBUG com.couchbase.client.core.node.Node - Connected (DEGRADED) to Node obbe-centos1.tlv.lpnet.com/192.168.15.120
15:55:06.266 [nioEventLoopGroup-2-5] DEBUG com.couchbase.client.core.node.Node - Connected (DEGRADED) to Node obbe-centos2.tlv.lpnet.com/192.168.15.2
15:55:06.266 [nioEventLoopGroup-2-2] DEBUG c.c.client.core.endpoint.Endpoint - Connected to ConfigEndpoint obbe-centos3.tlv.lpnet.com/192.168.15.190:8091
15:55:06.266 [nioEventLoopGroup-2-2] DEBUG c.c.client.core.service.Service - Connected (CONNECTING) to ConfigService obbe-centos3.tlv.lpnet.com
15:55:06.266 [nioEventLoopGroup-2-2] INFO com.couchbase.client.core.node.Node - Connected to Node obbe-centos3.tlv.lpnet.com/192.168.15.190
15:55:06.266 [nioEventLoopGroup-2-2] DEBUG com.couchbase.client.core.node.Node - Connected (DEGRADED) to Node obbe-centos3.tlv.lpnet.com/192.168.15.190
Comment by Michael Nitschinger [ 21/Aug/14 ]
Hi,

can you please retry with dp3 and see if the issue still persists? If so, please also provide the debug logs - thanks! Also, can you specify what "hangs" means? Your println does never show?
Comment by Oded Hassidi [ 24/Aug/14 ]
Thanks, yes my println doesn't ever show!
Will check it with the beta, sorry for the delay I was OOO couple of days :)
Comment by Michael Nitschinger [ 04/Sep/14 ]
Hey, any update on this?
Comment by Michael Nitschinger [ 15/Sep/14 ]
I've removed the fix version since it's not clear if its a bug or not anymore. Please provide any details if you can as soon as possible so we can fix it if needed thanks!
Comment by Oded Hassidi [ 21/Sep/14 ]
Hi Michael and thanks
Sorry for not being responsive in the last few weeks

I will try to check this and respond with latest findings in the next couple of days

Thanks again




[JCBC-564] Add release notes for 2.0 GA Created: 19/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: Task Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-565] Adapt README with new location and getting started Created: 19/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-558] Improve Javadoc for (Async)Bucket Created: 15/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-557] Improve Javadoc for the .document package Created: 15/Sep/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-534] Enhance documentation how JSON is handled Created: 28/Aug/14  Updated: 19/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-405] Allow custom server ports in the test suite (was: apache http library throws 'badurl' error while running Java SDK ant test against cluster on non-default port.) Created: 23/Jan/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Venu Uppalapati Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: CentOS 6.4 64-bit
RAM:256GB
Dual 2.9GHz 8-core Xeon E5-2690 for 32 total cores (16 + hyperthreading)


 Description   
This is part of multi-instance testing for customer 'A'.

Steps to reproduce:
1)Setup a 3 instances per physical machine. configure a cluster of 5 such instances. The instances are modified to run on non-default ports by modifying static config file. for example:
{rest_port,9000}.
{mccouch_port,9001}.
{memcached_port,12000}.
{memcached_dedicated_port,12001}.
{moxi_port,12002}.
{short_name,"ns11"}.
{ssl_rest_port,11000}.
{ssl_capi_port,11001}.
{ssl_proxy_downstream_port,11002}.
{ssl_proxy_upstream_port,11003}.

2)clone java SDK project. change the server ip address and server port number(internal memcached port) in the build.xml file to reflect the server address and non-default internal memcached port (12001 in this case).
example:sysproperty key="server.address_v6" value="${server.address_v6}"/>
            <sysproperty key="server.port_number" value="12001"/>

3) the junit tests in the Java SDK contain hardcoded REST port, so modify all of them to non-default REST port:
find . -name "*.java" -print0 | xargs -0 sed -i '' -e 's/8091/9000/g'

4)Run 'ant test'. the ClusterManager tests fail with following apache http library error. the library methods are called from ClusterManager.java

2014-01-23 16:35:03.786 WARN com.couchbase.client.ClusterManager: Cluster Response failed with:
    [junit] java.net.UnknownHostException: badurl
    [junit] at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.validateAddress(DefaultConnectingIOReactor.java:245)
    [junit] at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processSessionRequests(DefaultConnectingIOReactor.java:265)
    [junit] at org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processEvents(DefaultConnectingIOReactor.java:141)
    [junit] at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
    [junit] at com.couchbase.client.ClusterManager$2.run(ClusterManager.java:589)
    [junit] at java.lang.Thread.run(Thread.java:695)


 Comments   
Comment by Michael Nitschinger [ 23/Jan/14 ]
Alright, this will need some larger changes in the test suite, we didn't anticipate this back in the days.

Which ports do you need to have changed?
Comment by Venu Uppalapati [ 23/Jan/14 ]
All of the ports listed in step 1 of description need to be changed per instance.




[JCBC-407] Add Utility to load bootstrap URIs from DNS SRV Created: 29/Jan/14  Updated: 19/Sep/14

Status: In Progress
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: New Feature Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-520] Running SSL Test on 2.0 Client hangs when certificate is not valid Created: 20/Aug/14  Updated: 19/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0-dp3
Fix Version/s: 2.0.1
Security Level: Public

Type: Bug Priority: Major
Reporter: Wei-Li Liu Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The SSL test I make can be seen from
https://github.com/weilliu/couchbase-java-client/commit/97c3144692627d6e657a0cc157f5f9aa644de0f2
http://review.couchbase.org/#/c/40763/

Currently if we enable ssl, and when it hits a certificate which is not valid/not exist, the test would hang


11:38:16.868 [DEBUG] [TestEventLogger] com.couchbase.client.java.SSLTest > ClientCertificateRefresh STARTED
11:38:17.843 [DEBUG] [TestEventLogger]
11:38:17.843 [DEBUG] [TestEventLogger] com.couchbase.client.java.SSLTest > ClientCertificateRefresh STANDARD_OUT
11:38:17.843 [DEBUG] [TestEventLogger] File copied!
11:38:17.844 [DEBUG] [TestEventLogger] Reconnect with the Server
> 11:39:06.2 [ DEB] [org.gradle.process.internal.ExecHandleRunner] Abort requested. Destroying process: Gradle Worker 1.
> Building 85% > :integrationTest > 29 tests completed, 29 skippedWei-Lis-MacBook-Pro:couchbase-java-client wei-li$






[JCBC-385] Configurable number of threads for client Created: 02/Dec/13  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: Task Priority: Minor
Reporter: James Mauss Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Often the Client will create a number of threads for some features that the client does not plan on using, like views. This causes some extra overhead that is not needed.

It would be nice if the total number of threads that a client object creates is configurable.

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
note that this will e fully fixed in 2.0, but in 1.3 we will be much better with that on views.




[JCBC-441] add SSL support in support of Couchbase Server 3.0 Created: 27/Mar/14  Updated: 19/Sep/14  Resolved: 19/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 2.0.0
Security Level: Public

Type: New Feature Priority: Critical
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks MB-10084 Sub-Task: Changes required for Data E... Closed

 Description   
Add support to the client library in support of SSL. Behavior should be that the client will try SSL first, unless otherwise specified.

See other specifications and details on CCBC-344

 Comments   
Comment by Matt Ingenthron [ 11/Sep/14 ]
What's left on this? Done?




[JCBC-562] Java 2.0 client feature test shows timeout exception on design document test Created: 17/Sep/14  Updated: 17/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Wei-Li Liu Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to

 Description   
This is the only failed integration test from beta2

Class com.couchbase.client.java.DesignDocumentTest

java.lang.RuntimeException: java.util.concurrent.TimeoutException
at rx.observables.BlockingObservable.blockForSingle(BlockingObservable.java:481)
at rx.observables.BlockingObservable.single(BlockingObservable.java:348)
at com.couchbase.client.java.bucket.DefaultBucketManager.flush(DefaultBucketManager.java:138)
at com.couchbase.client.java.bucket.DefaultBucketManager.flush(DefaultBucketManager.java:60)
at com.couchbase.client.java.util.ClusterDependentTest.connect(ClusterDependentTest.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:69)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException
at rx.internal.operators.OperatorTimeoutBase$TimeoutSubscriber.onTimeout(OperatorTimeoutBase.java:169)
at rx.internal.operators.OperatorTimeout$1$1.call(OperatorTimeout.java:42)
at rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:43)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
... 3 more




[JCBC-536] Interpretation and Performance Impact of Client Profiling Created: 29/Aug/14  Updated: 17/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: Jeff Dillon Assignee: Sergey Avseyev
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates to

 Description   
Customer is using client side profiling as suggested in:

http://blog.couchbase.com/whats-new-couchbase-java-sdk-12

Do we have documentation on the Meters, Counters and Histogram output? What would the performance impact be, if any? Can this be safely left in place in a Production environment, for example?

 Comments   
Comment by Jeff Dillon [ 02/Sep/14 ]
Here are specific asks:

1) We need documentation on counters, meters and histogram output.
2) Can we run clients with MetricType = PERFORMANCE for extended duration? What's the overhead?
3) Can we change the net.spy.metrics.reporter.type to hook it up to Graphite? The metrics-core library does offer support for a GraphiteReporter. Reference: http://metrics.dropwizard.io/manual/graphite/#manual-graphite
4) Is it possible to add custom metrics over and above what's being gathered by the Couchbase java client? If so, how?
Comment by Deepu Bhatia [ 09/Sep/14 ]
Hi Michael, Matt,
Can we please get an update on this?

Thanks,
-Deepu
Comment by Michael Nitschinger [ 10/Sep/14 ]
Hi,

sorry, I've been quite busy lately...

Currently there is not much more documentation available, and metrics can be used in production environments. That said, while the metrics library is designed to be used in production it is not "zero overhead" and should be used with care. PERFORMANCE just logs less information, only those needed to find performance infos.

wrt to graphite: yes this should be possible to do, but I've never tried graphite on my own together with metrics.

You can use the MetricCollector provided on the Factory and use the methods like add counter with a name and then you can increment the counter as well. This API is used in the core, but to my knowledge is not (widely) used out there in general, but it should definitely work. If it does not, its a bug.
Comment by Deepu Bhatia [ 11/Sep/14 ]
Hi Michael,
At the bare minimum, I'd at least like to get the definitions for each of the metrics so that there's no misunderstanding. Here's a list of files being created when we use CSV logging.

[MEM] Shutting Down Nodes (NodesToShutdown).csv
[MEM] Response Rate: Success.csv
[MEM] Response Rate: Retry.csv
[MEM] Response Rate: Failure.csv
[MEM] Response Rate: All (Failure + Success + Retry).csv
[MEM] Request Rate: All.csv
[MEM] Reconnecting Nodes (ReconnectQueue).csv
[MEM] Average Time on wire for operations (µs).csv
[MEM] Average Bytes written to OS per write.csv
[MEM] Average Bytes read from OS per read.csv

This is critical to understand to unblock us. I understand that it's not zero overhead. We'll benchmark the performance with PERFORMANCE mode enabled and decide accordingly.
Comment by Deepu Bhatia [ 12/Sep/14 ]
Michael, Matt,
This has become critical for us. We have client side profiling capability now but we don't have an exact definition of the metric. This is a show stopper for us.
Comment by Matt Ingenthron [ 13/Sep/14 ]
Depu: The ones mentioned as "rate" are counters, so you'll need to collect with regularity. The average time and byte counts are just that.

Is there a particular question you're trying to answer? Maybe with that we can give some more specific guidance. I understand it may have to do with latency and where it is? Does the average time on wire correlate to what you're seeing from cbstats timings would be the thing I would be checking for. I'd also be looking for reconnect to be non-zero and retry rate being non-zero.
Comment by Deepu Bhatia [ 16/Sep/14 ]
Hi Matt,
Here's what I am specifically looking for:

[MEM] Shutting Down Nodes (NodesToShutdown).csv - what does this mean?
[MEM] Response Rate: Success.csv - what does this mean?
[MEM] Response Rate: Retry.csv - What retries are this?
[MEM] Response Rate: Failure.csv - What failures does this cover? Is this tracking timeout exceptions?
[MEM] Response Rate: All (Failure + Success + Retry).csv
[MEM] Request Rate: All.csv
[MEM] Reconnecting Nodes (ReconnectQueue).cvs - What is this metric tracking?
[MEM] Average Time on wire for operations (µs).csv - Is this pure network time? Is it in microseconds?
[MEM] Average Bytes written to OS per write.csv
[MEM] Average Bytes read from OS per read.csv

Comment by Michael Nitschinger [ 17/Sep/14 ]
Hi Deepu,

here is more info on each specific metric:

[MEM] Shutting Down Nodes (NodesToShutdown).csv - what does this mean?

>> contains nodes which are currently pending shutdown in the IO client. This means that if a node is failovered or removed, at some point it needs to be shutdown. This mostly indicates that a cluster is currently undergoing some changes.

[MEM] Response Rate: Success.csv - what does this mean?

>> How many responses returned with a "success" state from the server. so no failures or retries.

[MEM] Response Rate: Retry.csv - What retries are this?

>> how many responses returned from the server which are to be retried. This is mostly covered by "not my vbucket" responses that are coming up during a rebalance operation. If such ops are to be seen, then the cluster is currently or recently undergoing a rebalance operation.

[MEM] Response Rate: Failure.csv - What failures does this cover? Is this tracking timeout exceptions?

>> Operations that had been failed from the server side. This should normally not be larger than 0, if so something is wrong. This can indicate all forms of errors and the logs need to be investigated further.

[MEM] Response Rate: All (Failure + Success + Retry).csv

>> the response rate for all those responses combined (to get an aggregated view on the response rate)

[MEM] Request Rate: All.csv

>> rate of outgoing requests

[MEM] Reconnecting Nodes (ReconnectQueue).cvs - What is this metric tracking?

>> the number of all nodes that are currently waiting to be reconnected. this could be due to too many failing/timing out ops (issuing a manual reconnect), or the socket is closed upon us. A reconnecting node is not able to process operations, so this is indicating some form of unstable/fluent state.

[MEM] Average Time on wire for operations (µs).csv - Is this pure network time? Is it in microseconds?

>> this is nearly network time, and yes in microseconds. It is measured once we put the op over to the JVM and the second time when we start reading it off the JVM NIO parts. So it does not include only networking time, but also OS and JVM socket processing. But it cuts out other parts like transcoding.

[MEM] Average Bytes written to OS per write.csv

>> this is an indication of how well the syscalls are used, the higher the batch size the better the utilization. Lower utilization means more overhead for packets and less efficient network handling.

[MEM] Average Bytes read from OS per read.csv

>> see above, just for reads.




[JCBC-544] Does not throw error when querying a non existent view/designdoc Created: 05/Sep/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Bug Priority: Major
Reporter: Subhashni Balakrishnan Assignee: Sergey Avseyev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Here is the code I used. This doesn't call onError.
 

ViewQuery queryTemplate = ViewQuery.from("test","dummy");
    queryTemplate.stale(Stale.FALSE);
    Observable<ViewRow> viewRowObservable = bucket.query(queryTemplate).flatMap(new Func1<ViewResult, Observable<ViewRow>>() {
      public Observable<ViewRow> call(ViewResult res) {
        return res.rows();
      }
    });

   viewRowObservable.subscribe(new Observer<ViewRow>() {
     @Override
     public void onCompleted() {
      System.out.println("Completed");
     }

     @Override
     public void onError(Throwable throwable) {
      System.out.println(throwable.getMessage());
     }

     @Override
     public void onNext(ViewRow viewRow) {
     }
   });

 Comments   
Comment by Matt Ingenthron [ 09/Sep/14 ]
Sergey: Can you see if this is reproducible off the current master and if so investigate?
Comment by Michael Nitschinger [ 09/Sep/14 ]
Hi,

some remarks: it's just not implemented. The core should send the response back as a failure (see the status). Chain in an onNext and check for the error. if it is, throw a ViewDoesNotExist execption. Put the exception in the error namespace, the others are also in there.
Comment by Sergey Avseyev [ 12/Sep/14 ]
http://review.couchbase.org/41369
Comment by Michael Nitschinger [ 16/Sep/14 ]
I've removed the blocker, because right now you can get access to the error on the observable.

We need to work through some more tricky semantics, but this will not break the API at this point. Sergey will update this ticket once there is more progress, but its not holding us back for the beta2.
Comment by Michael Nitschinger [ 16/Sep/14 ]
Okay one step back, we'll add an exception for this in beta2 (ViewDoesNotExistException) if 404 is returned. For more tricky cases we'll handle it in separate tickets.




[JCBC-560] Add jar info in line with core io Created: 16/Sep/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-561] Rename binary to kv for less ambiguity Created: 16/Sep/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-525] Add support for full JSON compat docs & common flags Created: 22/Aug/14  Updated: 16/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Improvement Priority: Blocker
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-545] Couchbase Connection leaks to a single node in the cluster Created: 05/Sep/14  Updated: 15/Sep/14  Due: 14/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.2
Fix Version/s: 1.4.5
Security Level: Public

Type: Bug Priority: Critical
Reporter: Justin Michaels Assignee: Michael Nitschinger
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We are observing 2x the number of connections open on a single node in a given Couchbase cluster. All connections are on port 11210.

The development team believes they have identified a bug that creates this behavor during a cluster change and a new map being distributed to the Couchbase clients. Below is their observation.
... there in the list to randomize the nodes, but there’s a bug in the constructor of Couchbase SDK class com.couchbase.client.vbucket.provider.BucketConfigurationProvider

Here’s the code:

  public BucketConfigurationProvider(final List<URI> seedNodes,
    final String bucket, final String password,
    final CouchbaseConnectionFactory connectionFactory) {
    config = new AtomicReference<Bucket>();
    configurationParser = new ConfigurationParserJSON();
    httpProvider = new AtomicReference<ConfigurationProviderHTTP>(
      new ConfigurationProviderHTTP(seedNodes, bucket, password)
    );
    refreshingHttp = new AtomicBoolean(false);
    pollingBinary = new AtomicBoolean(false);
    observers = Collections.synchronizedList(new ArrayList<Reconfigurable>());
    binaryConnection = new AtomicReference<CouchbaseConnection>();

    this.seedNodes = Collections.synchronizedList(new ArrayList<URI>(seedNodes));
    this.bucket = bucket;
    this.password = password;
    this.connectionFactory = connectionFactory;
    potentiallyRandomizeNodeList(seedNodes);

    disableCarrierBootstrap = Boolean.parseBoolean(
      CouchbaseProperties.getProperty("disableCarrierBootstrap", "false"));
    disableHttpBootstrap = Boolean.parseBoolean(
      CouchbaseProperties.getProperty("disableHttpBootstrap", "false"));
  }


The potentiallyRandomizeNodeList method will randomize the list passed to it and in fact, in our clients we ARE randomizing the two-element list we are passing.
Unfortunately, the wrong list is being passed to this method. The code should be randomizing the list stored as a member variable.
The line should read
potentiallyRandomizeNodeList(this.seedNodes);

because four lines above a completely new list is constructed by making a shallow copy of the input argument, seedNodes.

The list later used to get the configuration information is always used ordered and that’s why all our management connections are to the same node, the first one in our list.

I found this in v1.4.2 of the client, but v1.4.4 seems to have the same code so I don’t think it’s been fixed yet.

 Comments   
Comment by Dan Douglas [ 06/Sep/14 ]
I found this issue.

The symptom is that the configuration information is always obtained from the first node in seed list passed and the shuffle is not done.

The line that does the shuffle in the constructor needs to reference the seedNodes member variable, not the argument. Needs to add "this." like so

potentiallyRandomizeNodeList(this.seedNodes);






[JCBC-559] Retry view responses if possible Created: 15/Sep/14  Updated: 15/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JVMCBC-35 Expose View retry codes in response s... Resolved




[JCBC-556] Add support for optional decompression on legacy decodes Created: 15/Sep/14  Updated: 15/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.1
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-554] Provide backoff handling utility classes for the user Created: 15/Sep/14  Updated: 15/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.0
Security Level: Public

Type: New Feature Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-481] Integration Tests hang up after 85% progress Created: 25/Jun/14  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-dp3
Security Level: Public

Type: Bug Priority: Test Blocker
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
[root@pomelo-11017 couchbase-java-client]# ./gradlew integrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileIntegrationJava UP-TO-DATE
:processIntegrationResources UP-TO-DATE
:integrationClasses UP-TO-DATE
> Building 85% > :integrationTest

 Comments   
Comment by Wei-Li Liu [ 18/Aug/14 ]
The process hangs at 85% due to view query test.
Just runs 2.0.0-dp3 integration test against the new beta2 build, and all the tests completes.
Comment by Deepti Dawar [ 21/Aug/14 ]
Following error appears with latest DP3 -

[root@pomelo-11017 couchbase-java-client]# ./gradlew integrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileIntegrationJava
warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning
:processIntegrationResources
:integrationClasses
:integrationTest

com.couchbase.client.java.BinaryTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.BinaryTest > classMethod FAILED
    java.util.NoSuchElementException

com.couchbase.client.java.DesignDocumentTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.DesignDocumentTest > classMethod FAILED
    java.util.NoSuchElementException

4 tests completed, 4 failed
:integrationTest FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':integrationTest'.
> There were failing tests. See the report at: file:///root/couchbase/couchbase-java-client/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 22.09 secs
Comment by Michael Nitschinger [ 21/Aug/14 ]
Does it also happen on master?
Comment by Wei-Li Liu [ 21/Aug/14 ]
I test it on master and only see JCBC-479




[JCBC-551] Implement blocking API around async one Created: 11/Sep/14  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Task Priority: Blocker
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-523] Add support for memcached buckets Created: 22/Aug/14  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Sergey Avseyev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 13/Sep/14 ]
Sergey: I believe this is done. Can you verify?
Comment by Sergey Avseyev [ 15/Sep/14 ]
Verified, memcache buckets supported with exception of APIs which are not available there (like locking)




[JCBC-228] a no-args constructor and an init method are needed Created: 31/Jan/13  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0, 1.1.1
Fix Version/s: 2.0.0
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently, the CouchbaseClient does a number of things that are not so pretty, like spinning up a thread from it's ctor. It would be better to add an additional, optional no-args constructor which expects an init method to be called with the other params needed, start thread, etc.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Assigning towards 1.1.2 but we can defer it to 1.1.3 as well.
Comment by Michael Nitschinger [ 19/Dec/13 ]
We'll have something like this in 2.0
Comment by Matt Ingenthron [ 11/Sep/14 ]
Sergey, I think this is true now in 2.0, can you verify and close this if so?
Comment by Sergey Avseyev [ 12/Sep/14 ]
Yes, we have static method create() which does not have any arguments, but it is just provides defaults to full constructor, which does blocking connection anyway.

We might extract connect() method to the public interface, and modify static constructors somehow they will allow to do at least asynchronous connection. I did some sketch here (it just extracts connect() method, but still call it from constructor) http://review.couchbase.org/41397

The patch is not meant to merged, just demonstrate my question.

Matt, could you expand a little bit what we need to achieve?

Does it spawn thread in constructor? No
Does it do blocking connection? Yes
Comment by Matt Ingenthron [ 12/Sep/14 ]
Assigning this to Michael as he's the architecture owner here.

The reason I filed this way back at -228 was that in general, a recommendation with Java is to not do anything requiring IO or threads in the ctor and separate out the actions of setting things up in a separate method. This is often helpful in some frameworks with DI, etc. Imagine for a moment that you throw an IOException from the ctor(). Chances are whatever created that object inline isn't ready to handle that exception right there. However, calling .init() on it and seeing an explicit throws IOException gives the app developer a cleaner way of abstracting the set up of the things and the initializing of the things.

http://www.javapractices.com/topic/TopicAction.do?Id=254

All of these things change over time though, so I trust Michael to pick a solution he can live with.
Comment by Sergey Avseyev [ 12/Sep/14 ]
Michael, I also think that current implementation is good. Abandoned my patch. Please resolve the ticket, or reassign back to me
Comment by Michael Nitschinger [ 15/Sep/14 ]
Yes, we have static factory methods now and should be good on that.

This was actually a relict out of changing the 1.* SDK when we didn't know that 2.0 was a breaking change. So I'm going to close this out.
Comment by Michael Nitschinger [ 15/Sep/14 ]
Requirements have changed since 2.0 is a complete rewrite its not needed anymore




[JCBC-553] 2.0.0.beta hangs on 2nd query Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0-beta
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Sean Colonello Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Client is Windows 8.1, server is CentOS 6 running 3.0 beta.

Attachments: Text File two-queries-hang.log    
Issue Links:
Duplicate
is duplicated by JVMCBC-28 ViewHandler can end up not completing... Resolved

 Description   
The following code hangs on the 2nd query.

CouchbaseCluster cluster = CouchbaseCluster.fromConnectionString("couchbase://192.168.1.75");
Bucket bucket = cluster.openBucket("trade-unittest", "blah").toBlocking().first();
bucket
.query(ViewQuery.from("devOnly", "allDocs"))
.flatMap(result -> result.rows())
.toBlocking()
.forEach(row -> logger.log(Level.INFO, row.id()));
bucket
.query(ViewQuery.from("devOnly", "allDocs"))
.flatMap(result -> result.rows())
.toBlocking()
.forEach(row -> logger.log(Level.INFO, row.id()));
cluster.disconnect();





[JCBC-549] Implement setHashAlg() / Implement ability to change hashing algorithm Created: 11/Sep/14  Updated: 12/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: New Feature Priority: Major
Reporter: Mark Woosey Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt: start-finish
Relates to
relates to PYCBC-250 support for distributing data by hashkey Open

 Description   
CouchbaseConnectionFactoryBuilder.setHashAlg() is currently not operational.




[JCBC-552] Support other sources for key store Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0-beta
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Cihan Biyikoglu Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-532] Implement Common Flags Created: 27/Aug/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Task Priority: Major
Reporter: Brett Lawson Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Implement the Common Flags formatting as defined by the specification.

 Comments   
Comment by Michael Nitschinger [ 11/Sep/14 ]
dups 525




[JCBC-384] couchbase java libs should use log4j or slf4j not JUL Created: 11/Sep/13  Updated: 11/Sep/14  Resolved: 11/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Dependencies
Affects Version/s: 1.4.0
Fix Version/s: 2.0-dp3
Security Level: Public

Type: Bug Priority: Major
Reporter: Timothy Ehlers Assignee: Michael Nitschinger
Resolution: Fixed Votes: 2
Labels: usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
log4j has more appends and is widely used, it is also more enterprise friendly thanks to the SocketAppender.

 Comments   
Comment by Timothy Ehlers [ 11/Sep/13 ]
A dependency you pull in uses log4j

net/spy/memcached/compat/log/Log4JLogger.java:import org.apache.log4j.Logger;

Then the couchbase lib uses JUL, this seems counter production
com/couchbase/client/CouchbaseClient.java:import java.util.logging.Logger;
Comment by Matt Ingenthron [ 27/Nov/13 ]
Note that we manage/maintain the net.spy.memcached project as well.

We have support for SLF4J, Log4J, and JUL. Because of how things are packaged, all dependencies are described via maven, but they're not all pulled in.
Comment by Matt Ingenthron [ 27/Nov/13 ]
Michael: do you think we can make our packaging better in the 2.0 client?
Comment by Michael Nitschinger [ 28/Nov/13 ]
That's right since 1.2 you can use slf4j. 2.0 will be slf4j only like most other projects out there, only shipping with the binding and you plug in your own impl.
Comment by Matt Ingenthron [ 11/Sep/14 ]
Michael: I think this is a resolved as of 2.0, right?
Comment by Michael Nitschinger [ 11/Sep/14 ]
it is!




[JCBC-529] Add support for spatial Created: 22/Aug/14  Updated: 11/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-548] user agent string is incorrect and doesn't work with some older HTTP core Created: 10/Sep/14  Updated: 10/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I found that the current client can't be used in CDH5 because a JavaLangNoSuchMethodError will be thrown with org.apache.http.protocol.RequestUserAgent.<init>(Ljava/lang/String;)V since the older 4.2 Apache httpcore does not have that method of defining a string and it takes precedence in the classpath.

In the process, I found that this header wasn't being set correctly anyway.

Filing this issue to remove the header. If we get a chance, it should be fixed by re-adding with reflection or whatever method 4.2 provides.




[JCBC-547] Paginator hasNext() works incorrectly on small results Created: 09/Sep/14  Updated: 09/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Views
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: raycardillo Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: javaclient
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
While working with the Paginator in our QA system I traced down a bug that will only happen when the page size is greater than the number of items in the underlying view/query. We wanted to call hasNext() multiple times because one layer of code validates that it has a good Paginator (due to other problems we were having with our cluster). However, because the actual response is fetched during hasNext(), and because the FINISHED state is set as a result of that, only the first hasNext() will return true even though we have not retrieved the response with next() yet.

For example, we should be able to call, hasNext() multiple times, and then state is only changed to indicate FINISHED after we actually retrieve the response using next().

After tracing this bug down, I can see that hasNext() returns false right away if FINISHED is true, and I can see that the FINISHED state is set during the fetch that happens during hasNext(). So when there is less than one page of data available, the first hasNext() will return true, and the next hasNext() will return false, which is a problem if the consumer has not actually called next() to fetch the response.

I think the simple fix here is to only set the FINISHED state in next() so you know that the data has actually been retrieved by the consumer. That way the consumer is free to ask hasNext() as many times as required for their logic, and it will not effect internal state until next() is called.




[JCBC-540] Enable SDK 1.x & 2.x to be deployed side by side in a single JVM. Consider renaming couchbase-client to java-client Created: 01/Sep/14  Updated: 09/Sep/14  Resolved: 09/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Dan Douglas [ 02/Sep/14 ]
Thanks for considering this.

Renaming the artifact is a start. However, the package names should be different, too, to make sure that the class namespace has no clashes.

The goal should be coexistence of both 1.4 SDK and 2.0 SDK clients in the same JVM.

Motivation is Couchbase use by large, distributed teams that will not all migrate in lockstep, yet contribute code that runs in the same JVM.

Lack of separation at both Maven artifact AND class namespace level will impede migration to CB Java 2.0 SDK.
Comment by Michael Nitschinger [ 02/Sep/14 ]
Hm, they both have com.couchbase.client in common, but the new one is now under com.couchbase.client.java and the core is com.couchbase.client.core

Is that sufficient or would the new one be completely different and not under com.couchbase.client at all?
Comment by Michael Nitschinger [ 02/Sep/14 ]
I just tried adding both as dependencies (I locally renamed the new one to java-client and pushed a new artifact) and it seems to work nicely:

    public static void main(String... args) throws Exception {

        CouchbaseClient client = new CouchbaseClient(
            Arrays.asList(URI.create("http://127.0.0.1:8091/pools")),
            "default",
            ""
        );

        Cluster cluster = CouchbaseCluster.create();
        Bucket bucket = cluster.openBucket().toBlocking().single();

        client.set("id", "value1234").get();
        System.out.println(bucket.get("id", LegacyDocument.class).toBlocking().single());

    }
Comment by Dan Douglas [ 02/Sep/14 ]
Doesn't have to be completely different.... just as long as there are no clashes in ANY of the class names.

Different prefixes are ok.

So as long as the SDK 2.0 packages always start with

com.couchbase.client.java
com.couchbase.client.core
com.couchbase.client.deps

and the SDK 1.4 maintenance never adds those paractular packages, it should be ok.

So far, the 1.4 version uses these packages...

com.couchbase.client
com.couchbase.client.clustermanager
com.couchbase.client.http
com.couchbase.client.internal
com.couchbase.client.protocol
com.couchbase.client.vbucket

It seems a little ripe for error, however. Should someone maintaining 1.4 ever forget and slip in .java, .core or .deps ... but like you said, so far so good.

Taking a step back, though, since the 2.0 SDK doesn't actaully have a "client" class (uses Cluster and Bucket objects instead) and the use of "java" seems somewhat superfluous here, perhaps you'd consider dropping "java" and changing the 2.0 SDK packages to

com.couchbase.sdk

or

com.couchbase.jsdk

or

com.couchbase.jcbc

or

something else....



Just a thought. What you have works, although it seems a little subtle and open to creating confusion.

There's precedent for changing package/artifact names together, for example Apache Commons Lang 3 (http://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/)
Comment by Cihan Biyikoglu [ 02/Sep/14 ]
added the goal to the title for clarity: side by side deployment of 1.x and 2.x SDKs in a JVM.
Comment by Michael Nitschinger [ 04/Sep/14 ]
I'm actually very open to rename the artifact to java-client (http://review.couchbase.org/#/c/41194/), but I'm not sure its a good idea to rename the namespace. Btw "java" is in there to align with "core" for "core-io" and also in the future for other language bindings like "scala" and so forth.

Since the 1.* branch is mostly in bugfix mode right now, I don't think there will be much room for conflict, since all classes added by the new one are under one level deeper and the only thing we need to make sure is not add a "java" or "core" namespace in the current stable SDK.

Would that make sense?
Comment by Dan Douglas [ 04/Sep/14 ]
Michael, you're the man. If you think it's going to be ok to just rename the artifact, then I'll agree with you. If someone introduces a clash later in a "fix", it'll just be a bad fix that will need to be redone. Perhaps you can introduce something in your static analysis or automated test suite to catch that.
Comment by Michael Nitschinger [ 09/Sep/14 ]
Merged!




[JCBC-541] incr() returns -1 Created: 02/Sep/14  Updated: 09/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.2
Fix Version/s: None
Security Level: Public

Type: Task Priority: Major
Reporter: RICHARDS PETER Assignee: Matt Ingenthron
Resolution: Unresolved Votes: 0
Labels: info-request
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Hi,

I am using incr() of couchbase client to increase a counter key in a bucket. I found this method very useful in some of our usecases. Around 150 threads from four machines increments current value of counter by 10 and use the values for some internal logic. Initially everything worked as expected. However a few days back I realized that couchbase returns -1 for some of the incr() method calls. That is how I noticed that incr() in MemcachedClient could return -1 if there is a failure to update the counter:
http://www.couchbase.com/autodocs/couchbase-java-client-1.4.3/net/spy/memcached/MemcachedClient.html

I have a few queries about this return value:
1. Could you please tell me the cases in which incr() would return -1? I identified one case. If the RAM quota allocated to the bucket is exhausted, we are likely to get -1. During this time addition of key-value pairs into the same bucket using add() will return false through the OperationFuture object. What are the other cases that would return -1 in the incr()?

2. Could you please tell me how the following method call works?
http://www.couchbase.com/autodocs/couchbase-java-client-1.4.3/net/spy/memcached/MemcachedClient.html#incr%28java.lang.String,%20long,%20long,%20int%29

I would like to know when the default value would be returned and when -1 would be returned. I think the default value would be returned if it is possible to insert the value into couchbase and -1 would be returned if it is not possible to retrieve the counter and update it. Am I correct?

3. Till now my project did not have a use case to increment negative values. However if somebody wants to increment -2 by 1 then the result would be -1. How will the client call be able to distinguish failure and actual increment in this case? Wouldn't it be better to throw a checked exception from incr() than returning -1? I think with checked exception we can provide more information about the cause of failure.

Richards Peter.




[JCBC-537] Setting Reader/Writer Worker value on Server causes ParseException on Client Created: 29/Aug/14  Updated: 09/Sep/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.4
Fix Version/s: .future
Security Level: Public

Type: Bug Priority: Minor
Reporter: Jeff Dillon Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File output.log    
Issue Links:
Dependency
depends on MB-12104 Carrier Config missing after R/W Conc... Resolved
Duplicate

 Description   
When setting the "Number of suggested reader/writer workers" in the Admin UI to 8, the 1.4.4 client then begins to see ParseException errors during the bootstrap phase. The client appears to continue as expected after that, but the error is concerning. The exception does not occur in the .NET or C client libraries.

To repro:

* Set the worker value to 8 in the UI
* Run the HelloWorld example from:

http://www.couchbase.com/communities/java/getting-started

Relevant code is:

// (Subset) of nodes in the cluster to establish a connection
    List<URI> hosts = Arrays.asList(
      new URI("http://127.0.0.1:8091/pools")
    );
 
    // Name of the Bucket to connect to
    String bucket = "default";
 
    // Password of the bucket (empty) string if none
    String password = "";
 
    // Connect to the Cluster
    CouchbaseClient client = new CouchbaseClient(hosts, bucket, password); // <- exception here

When running the example, the response is consistently:

2014-08-29 15:36:21.979 INFO net.spy.memcached.auth.AuthThread: Authenticated to /<ip_address>:11210
2014-08-29 15:36:22.014 WARN com.couchbase.client.vbucket.provider.BucketConfigurationProvider: Could not parse config, retrying bootstrap.
java.text.ParseException: A JSONObject text must begin with '{' at character 0 of
at com.couchbase.client.vbucket.config.ConfigurationParserJSON.parseBucket(ConfigurationParserJSON.java:148)



 Comments   
Comment by Matt Ingenthron [ 29/Aug/14 ]
If you crank up the log level, it should print out what the cluster is returning. Maybe the .NET and C clients are probably seeing the same behavior but not logging the warning?
Comment by Jeff Dillon [ 29/Aug/14 ]
In .NET I used the following log settings, and didn't see the error:

      <priority value="ALL" />
      <level value="DEBUG" />
Comment by Matt Ingenthron [ 29/Aug/14 ]
Yep, might be a bug that .NET doesn't log a warning on bad response and goes on to the next node.

The parse error comes from Jettison. https://github.com/couchbase/couchbase-java-client/blob/669c9580674082b2acccd769d9da5e1b3bb3e417/src/main/java/com/couchbase/client/vbucket/config/ConfigurationParserJSON.java#L148

It'd be really helpful if you could get the log to tell us what the cluster is returning.
Comment by Jeff Dillon [ 29/Aug/14 ]
Attaching Java log using:

logging.properties
handlers = java.util.logging.FileHandler
java.util.logging.FileHandler.pattern=output.log
java.util.logging.FileHandler.level = ALL
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
com.couchbase.client.vbucket.level = FINEST
com.couchbase.client.vbucket.config.level = FINEST
com.couchbase.client.level = FINEST
Comment by Michael Nitschinger [ 01/Sep/14 ]
Interesting, it could also be causing a latent parsing bug in the handler which has not been uncovered yet. I'll try to reproduce it.
Comment by Michael Nitschinger [ 01/Sep/14 ]
Wow, this looks like a server issue!

When you change the number of r/w threads the binary get config for CCCP returns an empty response.
Comment by Michael Nitschinger [ 01/Sep/14 ]
Please see http://www.couchbase.com/issues/browse/MB-12104 for more info
Comment by Michael Nitschinger [ 01/Sep/14 ]
While this is a server bug, I think we can do better on the binary bootstrap in the SDK to not try to apply a config like this and keep moving on, falling back to http.




[JCBC-528] Add shortcut JsonObject and JsonArray factories Created: 22/Aug/14  Updated: 04/Sep/14  Resolved: 04/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta2
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-509] Client doesn't shut down Created: 17/Aug/14  Updated: 27/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0-dp3
Fix Version/s: 2.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Adam Honen Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Java 87 update 11.
Windows 7 Service Pack 1 & Linux.

Attachments: Text File disconnection.log    
Issue Links:
Dependency

 Description   
Despite calling cluster.disconnect(), there are remaining non daemon (netty) threads which prevent the JVM from shutting down.

A thread dump from my machine when the program should have terminated:

Full thread dump Java HotSpot(TM) Client VM (25.11-b03 mixed mode):

"DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x0016d800 nid=0x1f38 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"RxComputationThreadPool-4" #21 daemon prio=5 os_prio=0 tid=0x15255400 nid=0x17ac waiting on condition [0x18c7f000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0x0a02bd00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

"RxComputationThreadPool-3" #20 daemon prio=5 os_prio=0 tid=0x18390400 nid=0x7d0 waiting on condition [0x18d4f000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0x0a044918> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

"nioEventLoopGroup-2-3" #12 prio=10 os_prio=2 tid=0x154b4c00 nid=0x1ba0 runnable [0x1730f000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
        at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
        - locked <0x0a02e818> (a com.couchbase.client.deps.io.netty.channel.nio.SelectedSelectionKeySet)
        - locked <0x0a03b060> (a java.util.Collections$UnmodifiableSet)
        - locked <0x0a02e7a0> (a sun.nio.ch.WindowsSelectorImpl)
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
        at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:622)
        at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:310)
        at com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
        at com.couchbase.client.deps.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
        at java.lang.Thread.run(Thread.java:745)

"nioEventLoopGroup-2-2" #11 prio=10 os_prio=2 tid=0x154a4800 nid=0x1524 runnable [0x1735f000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
        at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
        - locked <0x0a02e400> (a com.couchbase.client.deps.io.netty.channel.nio.SelectedSelectionKeySet)
        - locked <0x0a038df8> (a java.util.Collections$UnmodifiableSet)
        - locked <0x0a02e388> (a sun.nio.ch.WindowsSelectorImpl)
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
        at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:622)
        at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:310)
        at com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
        at com.couchbase.client.deps.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
        at java.lang.Thread.run(Thread.java:745)

"RxComputationThreadPool-2" #19 daemon prio=5 os_prio=0 tid=0x15374000 nid=0x1748 waiting on condition [0x14f9f000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0x0a0447a8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

"threadDeathWatcher-3-1" #18 daemon prio=1 os_prio=-2 tid=0x15336c00 nid=0x1ffc waiting on condition [0x15dcf000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at com.couchbase.client.deps.io.netty.util.ThreadDeathWatcher$Watcher.run(ThreadDeathWatcher.java:137)
        at com.couchbase.client.deps.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
        at java.lang.Thread.run(Thread.java:745)

"nioEventLoopGroup-2-1" #10 prio=10 os_prio=2 tid=0x152f4400 nid=0x1934 runnable [0x15c3f000]
   java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
        at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
        at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
        - locked <0x0a02dfe8> (a com.couchbase.client.deps.io.netty.channel.nio.SelectedSelectionKeySet)
        - locked <0x0a036b90> (a java.util.Collections$UnmodifiableSet)
        - locked <0x0a02df70> (a sun.nio.ch.WindowsSelectorImpl)
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
        at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:622)
        at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:310)
        at com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
        at com.couchbase.client.deps.io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
        at java.lang.Thread.run(Thread.java:745)

"RxComputationThreadPool-1" #16 daemon prio=5 os_prio=0 tid=0x15284800 nid=0x180c waiting on condition [0x15adf000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0x0a044860> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00f74c00 nid=0xefc runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x00f65800 nid=0x1600 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x00f5f800 nid=0x1a78 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x00f5cc00 nid=0x1e54 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x00f20c00 nid=0x1e30 in Object.wait() [0x14cff000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x09de3798> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
        - locked <0x09de3798> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x00f1a800 nid=0x1154 in Object.wait() [0x047bf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x09de3938> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
        - locked <0x09de3938> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=2 tid=0x00f17400 nid=0x1d7c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x00f7e400 nid=0x1264 waiting on condition

JNI global references: 242


Code to reproduce:

    final ViewQuery view = ViewQuery
        .from("views", "myView")
        .startKey(JsonArray.from(5))
        .endKey(JsonArray.from(6))
        .reduce(false);

    logger.debug("view=" + view);

    final Observable<ViewResult> query = bucket.query(view);
    logger.debug("query=" + query);

    query
        .doOnNext(item -> logger.debug("item={}; item.success()={}", item, item.success()))
        .filter(item -> item.success())
        .doOnNext(item -> logger.debug("getting rows"))
        .flatMap(ViewResult::rows)
        .doOnNext(item -> logger.debug("view row={}", item))
        .filter(item -> choose(item))
        .take(howMany)
        .doOnNext(item -> log(item))
        .doOnError(e -> e.printStackTrace())
        .doOnTerminate(() -> {
          System.out.println("done");
          cluster.disconnect();
        })
        .subscribe();
    logger.debug("subscribed");

    Thread.sleep(1000);
    cluster.disconnect();

(This is called by the main thread after connecting to the cluster)

This will print done, but never terminate.

 Comments   
Comment by Michael Nitschinger [ 18/Aug/14 ]
thanks for reporting it, I'll look into it soon.
Comment by Michael Nitschinger [ 21/Aug/14 ]
Found the issue, from the client the stateful environment was not properly shutdown. Should be fixed on master and is in the beta release. Let me know if it still not works, thanks!
Comment by Adam Honen [ 24/Aug/14 ]
Actually it did not work.
I tried with the beta jar, but I still see those Netty IO (non daemon) threads hanging around.

I tried also adding a call to bucket.close(), but that didn't help either.

Comment by Adam Honen [ 24/Aug/14 ]
Attached is the TRACE log that is emitted after I call the following two lines of code:

bucket.close();
cluster.disconnect();
Comment by Michael Nitschinger [ 27/Aug/14 ]
Ah, are you passing in a custom environment? Your demo code doesn't show the init path. If so, you need to shutdown() it manually. We can't do that on cluster.disconnect() because it could be shared across more cluster objects.
Comment by Michael Nitschinger [ 27/Aug/14 ]
Note that I made a change for beta2 so that 1) the owned pools are properly named (prefixed with cb) and are all daemonized, so even if the user doesn't call shutdown as he should at least the JVM exits.




[JCBC-500] CouchbaseClient doesn't timeout, hangs forever Created: 27/Jul/14  Updated: 26/Aug/14  Resolved: 26/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.3
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Critical
Reporter: Milan Simonovic Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
On a single node cluster:

1. open CouchbaseClient with opTimeout = 10sec (on a different machine)
2. write 50 docs (works fine)
3. make the server drop packets for 15sec (iptables -A INPUT -p tcp --dport 200:65535 -j DROP)
4. try to write another doc -> blocks forever

I've tried different timeout values: opTimeout =2.5sec, dropping packets for 5sec, but it also never times-out.

The code to reproduce this issue is here: https://github.com/mbsimonovic/jepsen-couchbase.
A more detailed explanation in my blog post: http://milansimonovic.com/2014/07/22/smashing-couchbase/

 Comments   
Comment by Milan Simonovic [ 28/Jul/14 ]
tested with Java SDK v1.4.3
Comment by Michael Nitschinger [ 14/Aug/14 ]
Hey Milan,

I cloned your project and adjusted it to my 3 node cluster. What I got was:

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java -Didea.launcher.port=7540 "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA 13.app/bin" -Dfile.encoding=UTF-8 -classpath "/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/htmlconverter.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Users/michael/tmp/jepsen-couchbase/target/classes:/Users/michael/.m2/repository/com/couchbase/client/couchbase-client/1.4.3/couchbase-client-1.4.3.jar:/Users/michael/.m2/repository/io/netty/netty/3.5.5.Final/netty-3.5.5.Final.jar:/Users/michael/.m2/repository/org/codehaus/jettison/jettison/1.1/jettison-1.1.jar:/Users/michael/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar:/Users/michael/.m2/repository/commons-codec/commons-codec/1.5/commons-codec-1.5.jar:/Users/michael/.m2/repository/net/spy/spymemcached/2.11.4/spymemcached-2.11.4.jar:/Users/michael/.m2/repository/org/apache/httpcomponents/httpcore/4.3/httpcore-4.3.jar:/Users/michael/.m2/repository/org/apache/httpcomponents/httpcore-nio/4.3/httpcore-nio-4.3.jar:/Users/michael/.m2/repository/com/google/code/gson/gson/2.2.4/gson-2.2.4.jar:/Users/michael/.m2/repository/com/jcraft/jsch/0.1.51/jsch-0.1.51.jar:/Users/michael/.m2/repository/org/slf4j/slf4j-api/1.5.10/slf4j-api-1.5.10.jar:/Users/michael/.m2/repository/org/slf4j/slf4j-log4j12/1.5.10/slf4j-log4j12-1.5.10.jar:/Users/michael/.m2/repository/log4j/log4j/1.2.15/log4j-1.2.15.jar:/Users/michael/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar:/Users/michael/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:/Applications/IntelliJ IDEA 13.app/lib/idea_rt.jar" com.intellij.rt.execution.application.AppMain com.milansimonovic.jepsen.CouchTimeoutTest
2014-08-14 10:19:38,106 INFO [com.milansimonovic.jepsen.RemoteConnection] - 192.168.56.101
2014-08-14 10:19:38,636 INFO [com.milansimonovic.jepsen.CouchbaseClientFactory] - CouchbaseClientFactory{192.168.56.101, default, }
2014-08-14 10:19:38,783 INFO [com.couchbase.client.vbucket.provider.BucketConfigurationProvider] - Could bootstrap through carrier publication.
2014-08-14 10:19:38,800 INFO [com.couchbase.client.CouchbaseConnection] - Added {QA sa=/192.168.56.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2014-08-14 10:19:38,800 INFO [com.couchbase.client.CouchbaseConnection] - Added {QA sa=/192.168.56.102:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2014-08-14 10:19:38,801 INFO [com.couchbase.client.CouchbaseConnection] - Added {QA sa=/192.168.56.103:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2014-08-14 10:19:38,806 INFO [com.couchbase.client.CouchbaseClient] - CouchbaseConnectionFactory{bucket='default', nodes=[http://192.168.56.101:8091/pools], order=RANDOM, opTimeout=10000, opQueue=16384, opQueueBlockTime=10000, obsPollInt=10, obsPollMax=1000, obsTimeout=10000, viewConns=10, viewTimeout=75000, viewWorkers=1, configCheck=10, reconnectInt=1100, failureMode=Redistribute, hashAlgo=NATIVE_HASH, authWaitTime=2500}
2014-08-14 10:19:38,849 INFO [com.couchbase.client.CouchbaseClient] - viewmode property isn't defined. Setting viewmode to production mode
2014-08-14 10:19:38,849 INFO [com.milansimonovic.jepsen.Cluster] - healing partition
2014-08-14 10:19:39,869 DEBUG [com.milansimonovic.jepsen.RemoteConnection] - exit-status: 0
2014-08-14 10:19:39,870 INFO [com.milansimonovic.jepsen.Cluster] - healing partition - DONE
2014-08-14 10:19:39,919 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 1 in 43
2014-08-14 10:19:39,922 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 2 in 3
2014-08-14 10:19:39,923 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 3 in 1
2014-08-14 10:19:39,925 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 4 in 2
2014-08-14 10:19:39,927 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 5 in 2
2014-08-14 10:19:39,928 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 6 in 1
2014-08-14 10:19:39,930 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 7 in 2
2014-08-14 10:19:39,931 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 8 in 1
2014-08-14 10:19:39,933 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 9 in 2
2014-08-14 10:19:39,934 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 10 in 1
2014-08-14 10:19:39,936 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 11 in 2
2014-08-14 10:19:39,938 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 12 in 2
2014-08-14 10:19:39,939 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 13 in 1
2014-08-14 10:19:39,941 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 14 in 2
2014-08-14 10:19:39,943 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 15 in 2
2014-08-14 10:19:39,945 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 16 in 2
2014-08-14 10:19:39,946 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 17 in 1
2014-08-14 10:19:39,948 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 18 in 2
2014-08-14 10:19:39,949 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 19 in 1
2014-08-14 10:19:39,953 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 20 in 2
2014-08-14 10:19:39,955 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 21 in 2
2014-08-14 10:19:39,956 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 22 in 1
2014-08-14 10:19:39,958 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 23 in 2
2014-08-14 10:19:39,959 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 24 in 1
2014-08-14 10:19:39,961 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 25 in 2
2014-08-14 10:19:39,963 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 26 in 2
2014-08-14 10:19:39,964 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 27 in 1
2014-08-14 10:19:39,966 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 28 in 2
2014-08-14 10:19:39,968 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 29 in 2
2014-08-14 10:19:39,969 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 30 in 1
2014-08-14 10:19:39,971 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 31 in 2
2014-08-14 10:19:39,972 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 32 in 1
2014-08-14 10:19:39,974 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 33 in 2
2014-08-14 10:19:39,976 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 34 in 2
2014-08-14 10:19:39,977 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 35 in 1
2014-08-14 10:19:39,979 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 36 in 2
2014-08-14 10:19:39,981 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 37 in 2
2014-08-14 10:19:39,982 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 38 in 1
2014-08-14 10:19:39,984 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 39 in 2
2014-08-14 10:19:39,986 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 40 in 2
2014-08-14 10:19:39,988 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 41 in 1
2014-08-14 10:19:39,989 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 42 in 1
2014-08-14 10:19:39,991 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 43 in 1
2014-08-14 10:19:39,992 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 44 in 1
2014-08-14 10:19:39,993 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 45 in 1
2014-08-14 10:19:39,995 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 46 in 2
2014-08-14 10:19:39,996 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 47 in 1
2014-08-14 10:19:39,998 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 48 in 2
2014-08-14 10:19:39,999 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 49 in 1
2014-08-14 10:19:40,001 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 50 in 2
2014-08-14 10:19:40,001 INFO [com.milansimonovic.jepsen.Cluster] - creating 1 way partition
2014-08-14 10:19:41,003 DEBUG [com.milansimonovic.jepsen.RemoteConnection] - exit-status: 0
2014-08-14 10:19:41,003 INFO [com.milansimonovic.jepsen.Cluster] - creating partition DONE
2014-08-14 10:19:41,004 INFO [com.milansimonovic.jepsen.Cluster] - scheduled heal in 15 seconds
2014-08-14 10:19:56,005 INFO [com.milansimonovic.jepsen.Cluster] - healing partition
2014-08-14 10:19:57,007 DEBUG [com.milansimonovic.jepsen.RemoteConnection] - exit-status: 0
2014-08-14 10:19:57,008 INFO [com.milansimonovic.jepsen.Cluster] - healing partition - DONE
2014-08-14 10:19:57,008 INFO [com.milansimonovic.jepsen.Cluster] - closing connections

and the doc on the server looked like:

{
  "elements": [
    1,
    2,
    3,
    4,
    5,
    6,
    7,
    8,
    9,
    10,
    11,
    12,
    13,
    14,
    15,
    16,
    17,
    18,
    19,
    20,
    21,
    22,
    23,
    24,
    25,
    26,
    27,
    28,
    29,
    30,
    31,
    32,
    33,
    34,
    35,
    36,
    37,
    38,
    39,
    40,
    41,
    42,
    43,
    44,
    45,
    46,
    47,
    48,
    49,
    50
  ]
}

I wonder what I did different? Does it happen for you only in the single-node case? Or does running the test just not cover the bug?
Comment by Michael Nitschinger [ 14/Aug/14 ]
Ah now I get it, there should be much more appended than just 50.
Comment by Michael Nitschinger [ 14/Aug/14 ]
Ah I fixed your code. Let me do a PR for your github project.

You need to move the gets into the try/catch block as well since it can also throw a timeout (and will if there is a partition):

                CASValue<Object> casValue = client.gets(key);
                String updatedValue = appendElement(casValue.getValue().toString(), nextVal);

When I move it inside I get:

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:61775,suspend=y,server=n -Dfile.encoding=UTF-8 -classpath "/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/lib/tools.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/htmlconverter.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Users/michael/tmp/jepsen-couchbase/target/classes:/Users/michael/.m2/repository/com/couchbase/client/couchbase-client/1.4.3/couchbase-client-1.4.3.jar:/Users/michael/.m2/repository/io/netty/netty/3.5.5.Final/netty-3.5.5.Final.jar:/Users/michael/.m2/repository/org/codehaus/jettison/jettison/1.1/jettison-1.1.jar:/Users/michael/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar:/Users/michael/.m2/repository/commons-codec/commons-codec/1.5/commons-codec-1.5.jar:/Users/michael/.m2/repository/net/spy/spymemcached/2.11.4/spymemcached-2.11.4.jar:/Users/michael/.m2/repository/org/apache/httpcomponents/httpcore/4.3/httpcore-4.3.jar:/Users/michael/.m2/repository/org/apache/httpcomponents/httpcore-nio/4.3/httpcore-nio-4.3.jar:/Users/michael/.m2/repository/com/google/code/gson/gson/2.2.4/gson-2.2.4.jar:/Users/michael/.m2/repository/com/jcraft/jsch/0.1.51/jsch-0.1.51.jar:/Users/michael/.m2/repository/org/slf4j/slf4j-api/1.5.10/slf4j-api-1.5.10.jar:/Users/michael/.m2/repository/org/slf4j/slf4j-log4j12/1.5.10/slf4j-log4j12-1.5.10.jar:/Users/michael/.m2/repository/log4j/log4j/1.2.15/log4j-1.2.15.jar:/Users/michael/.m2/repository/javax/mail/mail/1.4/mail-1.4.jar:/Users/michael/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:/Applications/IntelliJ IDEA 13.app/lib/idea_rt.jar" com.milansimonovic.jepsen.CouchTimeoutTest
Connected to the target VM, address: '127.0.0.1:61775', transport: 'socket'
2014-08-14 11:02:47,408 INFO [com.milansimonovic.jepsen.RemoteConnection] - 192.168.56.101
2014-08-14 11:02:47,771 INFO [com.milansimonovic.jepsen.CouchbaseClientFactory] - CouchbaseClientFactory{192.168.56.101, default, }
2014-08-14 11:02:47,908 INFO [com.couchbase.client.vbucket.provider.BucketConfigurationProvider] - Could bootstrap through carrier publication.
2014-08-14 11:02:47,920 INFO [com.couchbase.client.CouchbaseConnection] - Added {QA sa=/192.168.56.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2014-08-14 11:02:47,923 INFO [com.couchbase.client.CouchbaseClient] - CouchbaseConnectionFactory{bucket='default', nodes=[http://192.168.56.101:8091/pools], order=RANDOM, opTimeout=10000, opQueue=16384, opQueueBlockTime=10000, obsPollInt=10, obsPollMax=1000, obsTimeout=10000, viewConns=10, viewTimeout=75000, viewWorkers=1, configCheck=10, reconnectInt=1100, failureMode=Redistribute, hashAlgo=NATIVE_HASH, authWaitTime=2500}
2014-08-14 11:02:47,956 INFO [com.couchbase.client.CouchbaseClient] - viewmode property isn't defined. Setting viewmode to production mode
2014-08-14 11:02:47,956 INFO [com.milansimonovic.jepsen.Cluster] - healing partition
2014-08-14 11:02:48,970 DEBUG [com.milansimonovic.jepsen.RemoteConnection] - exit-status: 0
2014-08-14 11:02:48,970 INFO [com.milansimonovic.jepsen.Cluster] - healing partition - DONE
counting down 943596453
counting down 99276090
2014-08-14 11:02:49,042 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 1 in 61
counting down 1076537872
2014-08-14 11:02:49,048 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 2 in 6
2014-08-14 11:02:49,054 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 3 in 6
counting down 1413217636
2014-08-14 11:02:49,060 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 4 in 6
counting down 491904845
2014-08-14 11:02:49,066 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 5 in 6
counting down 1312922328
2014-08-14 11:02:49,072 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 6 in 6
counting down 1529791274
2014-08-14 11:02:49,078 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 7 in 6
counting down 1349895670
2014-08-14 11:02:49,083 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 8 in 5
counting down 1129169666
2014-08-14 11:02:49,089 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 9 in 6
counting down 26740457
counting down 746758755
2014-08-14 11:02:49,094 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 10 in 5
counting down 1386645616
2014-08-14 11:02:49,100 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 11 in 5
2014-08-14 11:02:49,106 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 12 in 6
counting down 2145256693
2014-08-14 11:02:49,111 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 13 in 5
counting down 1051781801
2014-08-14 11:02:49,117 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 14 in 6
counting down 119068326
2014-08-14 11:02:49,123 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 15 in 6
counting down 1637559101
2014-08-14 11:02:49,128 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 16 in 5
counting down 1861050967
2014-08-14 11:02:49,134 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 17 in 6
counting down 1462839425
2014-08-14 11:02:49,140 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 18 in 6
counting down 383609127
2014-08-14 11:02:49,147 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 19 in 6
counting down 774334978
2014-08-14 11:02:49,156 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 20 in 8
counting down 735922763
2014-08-14 11:02:49,162 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 21 in 6
counting down 1970674321
2014-08-14 11:02:49,170 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 22 in 7
counting down 136298825
2014-08-14 11:02:49,177 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 23 in 7
counting down 494783794
2014-08-14 11:02:49,185 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 24 in 8
counting down 1546867652
2014-08-14 11:02:49,192 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 25 in 7
counting down 433354817
2014-08-14 11:02:49,199 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 26 in 7
counting down 1865938875
2014-08-14 11:02:49,207 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 27 in 8
counting down 483439410
2014-08-14 11:02:49,214 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 28 in 7
counting down 1513848351
2014-08-14 11:02:49,221 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 29 in 7
counting down 1612120937
2014-08-14 11:02:49,228 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 30 in 7
counting down 810400511
2014-08-14 11:02:49,235 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 31 in 7
counting down 689821415
2014-08-14 11:02:49,242 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 32 in 7
counting down 685219421
2014-08-14 11:02:49,248 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 33 in 6
counting down 1887689829
counting down 759433928
2014-08-14 11:02:49,254 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 34 in 6
2014-08-14 11:02:49,259 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 35 in 5
counting down 1781091177
2014-08-14 11:02:49,266 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 36 in 7
counting down 2123891975
2014-08-14 11:02:49,271 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 37 in 5
counting down 278306373
2014-08-14 11:02:49,278 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 38 in 6
counting down 495568085
2014-08-14 11:02:49,284 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 39 in 6
counting down 1029420558
2014-08-14 11:02:49,290 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 40 in 5
counting down 55913631
2014-08-14 11:02:49,296 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 41 in 6
counting down 664141318
2014-08-14 11:02:49,302 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 42 in 6
counting down 1953048909
2014-08-14 11:02:49,307 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 43 in 5
counting down 350362120
counting down 1048178143
2014-08-14 11:02:49,313 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 44 in 6
2014-08-14 11:02:49,318 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 45 in 5
counting down 907297240
2014-08-14 11:02:49,323 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 46 in 5
counting down 193602838
2014-08-14 11:02:49,329 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 47 in 6
counting down 255614005
2014-08-14 11:02:49,335 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 48 in 6
counting down 2128240408
2014-08-14 11:02:49,340 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 49 in 5
counting down 1783946138
2014-08-14 11:02:49,346 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 50 in 6
2014-08-14 11:02:49,347 INFO [com.milansimonovic.jepsen.Cluster] - creating 1 way partition
2014-08-14 11:02:50,348 DEBUG [com.milansimonovic.jepsen.RemoteConnection] - exit-status: 0
2014-08-14 11:02:50,348 INFO [com.milansimonovic.jepsen.Cluster] - creating partition DONE
2014-08-14 11:02:50,349 INFO [com.milansimonovic.jepsen.Cluster] - scheduled heal in 15 seconds
counting down 1330247343
2014-08-14 11:03:03,213 ERROR [com.milansimonovic.jepsen.CouchTimeoutTest] - timed out adding 51
2014-08-14 11:03:03,214 ERROR [com.milansimonovic.jepsen.CouchTimeoutTest] - error adding 51
net.spy.memcached.OperationTimeoutException: Timeout waiting for value
at net.spy.memcached.MemcachedClient.gets(MemcachedClient.java:1147)
at net.spy.memcached.MemcachedClient.gets(MemcachedClient.java:1211)
at com.milansimonovic.jepsen.CouchTimeoutTest.addElementToArray(CouchTimeoutTest.java:65)
at com.milansimonovic.jepsen.CouchTimeoutTest.appendToDocument(CouchTimeoutTest.java:102)
at com.milansimonovic.jepsen.CouchTimeoutTest.run(CouchTimeoutTest.java:49)
at com.milansimonovic.jepsen.CouchTimeoutTest.main(CouchTimeoutTest.java:39)
Caused by: net.spy.memcached.internal.CheckedOperationTimeoutException: Timed out waiting for operation - failing node: 192.168.56.101/192.168.56.101:11210
at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:167)
at net.spy.memcached.MemcachedClient.gets(MemcachedClient.java:1137)
... 5 more
2014-08-14 11:03:05,349 INFO [com.milansimonovic.jepsen.Cluster] - healing partition
2014-08-14 11:03:06,351 DEBUG [com.milansimonovic.jepsen.RemoteConnection] - exit-status: 0
2014-08-14 11:03:06,351 INFO [com.milansimonovic.jepsen.Cluster] - healing partition - DONE
2014-08-14 11:03:06,351 INFO [com.milansimonovic.jepsen.Cluster] - closing connections
counting down 1330247343
counting down 808247635
counting down 1562173079
2014-08-14 11:03:08,230 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 52 in 5014
counting down 1897031859
2014-08-14 11:03:08,236 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 53 in 6
2014-08-14 11:03:08,241 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 54 in 5
counting down 1029104896
2014-08-14 11:03:08,247 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 55 in 6
counting down 1789373824
2014-08-14 11:03:08,252 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 56 in 5
counting down 1374957093
2014-08-14 11:03:08,259 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 57 in 7
counting down 859935576
2014-08-14 11:03:08,265 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 58 in 5
counting down 959778517
2014-08-14 11:03:08,270 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 59 in 5
counting down 1856597982
2014-08-14 11:03:08,276 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 60 in 6
counting down 509403432
2014-08-14 11:03:08,283 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 61 in 7
counting down 565734120
2014-08-14 11:03:08,289 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 62 in 6
counting down 812288940
2014-08-14 11:03:08,295 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 63 in 6
counting down 362337760
2014-08-14 11:03:08,301 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 64 in 6
counting down 1815360474
counting down 238680990
2014-08-14 11:03:08,307 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 65 in 6
2014-08-14 11:03:08,312 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 66 in 5
counting down 1793734174
2014-08-14 11:03:08,318 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 67 in 6
counting down 965663094
2014-08-14 11:03:08,323 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 68 in 5
counting down 1961465726
2014-08-14 11:03:08,329 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 69 in 6
counting down 894265206
counting down 237825287
2014-08-14 11:03:08,334 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 70 in 5
2014-08-14 11:03:08,340 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 71 in 6
counting down 1093062877
2014-08-14 11:03:08,346 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 72 in 6
counting down 2043477472
2014-08-14 11:03:08,352 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 73 in 6
counting down 660886392
2014-08-14 11:03:08,358 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 74 in 6
counting down 1321850438
2014-08-14 11:03:08,363 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 75 in 5
counting down 966674298
2014-08-14 11:03:08,368 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 76 in 5
counting down 665030228
counting down 584709707
2014-08-14 11:03:08,373 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 77 in 5
2014-08-14 11:03:08,379 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 78 in 6
counting down 581070768
2014-08-14 11:03:08,384 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 79 in 5
counting down 1766611209
2014-08-14 11:03:08,390 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 80 in 6
counting down 1378265946
2014-08-14 11:03:08,395 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 81 in 5
counting down 1067480315
2014-08-14 11:03:08,400 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 82 in 5
counting down 240010064
2014-08-14 11:03:08,406 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 83 in 6
counting down 96589697
counting down 1650118680
2014-08-14 11:03:08,411 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 84 in 5
2014-08-14 11:03:08,417 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 85 in 6
counting down 1583441668
2014-08-14 11:03:08,422 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 86 in 5
counting down 575269723
2014-08-14 11:03:08,427 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 87 in 5
counting down 692018508
2014-08-14 11:03:08,434 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 88 in 6
counting down 500269667
2014-08-14 11:03:08,440 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 89 in 6
counting down 1214091162
2014-08-14 11:03:08,446 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 90 in 6
counting down 631482105
2014-08-14 11:03:08,452 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 91 in 6
counting down 1982159420
2014-08-14 11:03:08,458 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 92 in 6
counting down 1744182273
counting down 1131642426
2014-08-14 11:03:08,463 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 93 in 5
2014-08-14 11:03:08,469 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 94 in 6
counting down 2069859523
2014-08-14 11:03:08,475 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 95 in 6
counting down 662166830
2014-08-14 11:03:08,481 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 96 in 6
counting down 1882643413
2014-08-14 11:03:08,487 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 97 in 6
counting down 678230343
2014-08-14 11:03:08,493 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 98 in 6
counting down 793919773
2014-08-14 11:03:08,498 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 99 in 5
counting down 911566708
2014-08-14 11:03:08,505 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 100 in 7
counting down 1887173144
2014-08-14 11:03:08,510 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 101 in 5
counting down 1058177937
2014-08-14 11:03:08,516 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 102 in 6
counting down 41252807
2014-08-14 11:03:08,523 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 103 in 6
counting down 528932410
2014-08-14 11:03:08,531 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 104 in 8
counting down 805461224
2014-08-14 11:03:08,538 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 105 in 7
counting down 463949682
2014-08-14 11:03:08,546 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 106 in 8
counting down 851822734
2014-08-14 11:03:08,554 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 107 in 8
counting down 454797282
2014-08-14 11:03:08,561 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 108 in 7
counting down 962354549
2014-08-14 11:03:08,568 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 109 in 7
counting down 413223411
2014-08-14 11:03:08,574 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 110 in 6
counting down 79455185
2014-08-14 11:03:08,580 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 111 in 6
counting down 1113518099
2014-08-14 11:03:08,586 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 112 in 6
counting down 431139544
2014-08-14 11:03:08,592 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 113 in 6
counting down 198084300
2014-08-14 11:03:08,599 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 114 in 7
counting down 1821101711
2014-08-14 11:03:08,605 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 115 in 6
counting down 1499489637
2014-08-14 11:03:08,611 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 116 in 6
counting down 1435037947
2014-08-14 11:03:08,618 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 117 in 7
counting down 705688672
2014-08-14 11:03:08,624 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 118 in 6
counting down 407021592
2014-08-14 11:03:08,630 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 119 in 6
counting down 1121168696
2014-08-14 11:03:08,637 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 120 in 7
counting down 1347326641
counting down 87539756
2014-08-14 11:03:08,642 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 121 in 5
2014-08-14 11:03:08,647 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 122 in 5
counting down 137935610
2014-08-14 11:03:08,653 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 123 in 6
counting down 1474133160
2014-08-14 11:03:08,659 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 124 in 6
counting down 1931651064
2014-08-14 11:03:08,665 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 125 in 6
counting down 1211051792
2014-08-14 11:03:08,688 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 126 in 23
counting down 93172613
2014-08-14 11:03:08,693 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 127 in 5
counting down 965322656
2014-08-14 11:03:08,699 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 128 in 6
counting down 1601358350
2014-08-14 11:03:08,705 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 129 in 6
counting down 1855207775
2014-08-14 11:03:08,710 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 130 in 5
counting down 107851411
2014-08-14 11:03:08,716 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 131 in 6
counting down 1915600217
2014-08-14 11:03:08,721 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 132 in 5
counting down 1002847144
2014-08-14 11:03:08,727 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 133 in 6
counting down 1960289102
2014-08-14 11:03:08,732 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 134 in 5
counting down 530940529
2014-08-14 11:03:08,738 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 135 in 6
counting down 16593833
2014-08-14 11:03:08,744 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 136 in 6
counting down 183255909
2014-08-14 11:03:08,749 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 137 in 5
counting down 1139297445
counting down 1886255267
2014-08-14 11:03:08,755 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 138 in 5
2014-08-14 11:03:08,760 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 139 in 5
counting down 426044796
2014-08-14 11:03:08,765 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 140 in 5
counting down 1903915614
2014-08-14 11:03:08,770 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 141 in 5
counting down 1895269808
2014-08-14 11:03:08,776 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 142 in 6
counting down 1866519533
counting down 1366412404
2014-08-14 11:03:08,781 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 143 in 5
2014-08-14 11:03:08,786 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 144 in 5
counting down 2075311494
2014-08-14 11:03:08,792 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 145 in 6
counting down 925138245
2014-08-14 11:03:08,797 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 146 in 5
counting down 1578242039
2014-08-14 11:03:08,802 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 147 in 5
counting down 23034413
2014-08-14 11:03:08,808 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 148 in 6
counting down 1869588749
counting down 2067087344
2014-08-14 11:03:08,814 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 149 in 6
2014-08-14 11:03:08,820 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 150 in 6
counting down 899087062
2014-08-14 11:03:08,826 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 151 in 6
counting down 1340235867
2014-08-14 11:03:08,832 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 152 in 6
counting down 1574412139
2014-08-14 11:03:08,838 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 153 in 6
counting down 256897438
2014-08-14 11:03:08,844 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 154 in 6
counting down 227404523
2014-08-14 11:03:08,849 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 155 in 5
counting down 1370600377
2014-08-14 11:03:08,855 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 156 in 5
counting down 821838371
2014-08-14 11:03:08,861 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 157 in 6
counting down 1087346339
counting down 578287331
2014-08-14 11:03:08,866 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 158 in 5
2014-08-14 11:03:08,872 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 159 in 6
counting down 2114430319
2014-08-14 11:03:08,877 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 160 in 5
counting down 750263766
2014-08-14 11:03:08,883 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 161 in 6
counting down 285142124
2014-08-14 11:03:08,889 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 162 in 6
counting down 228835454
2014-08-14 11:03:08,895 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 163 in 6
counting down 1322000504
2014-08-14 11:03:08,900 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 164 in 5
counting down 578208474
2014-08-14 11:03:08,906 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 165 in 6
counting down 1158469492
counting down 1446993819
2014-08-14 11:03:08,911 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 166 in 5
2014-08-14 11:03:08,917 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 167 in 6
counting down 2036300484
2014-08-14 11:03:08,923 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 168 in 5
counting down 1839929127
2014-08-14 11:03:08,928 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 169 in 5
counting down 1321196177
2014-08-14 11:03:08,934 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 170 in 6
counting down 1657833306
2014-08-14 11:03:08,941 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 171 in 7
counting down 1616599198
2014-08-14 11:03:08,948 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 172 in 7
counting down 1434216861
2014-08-14 11:03:08,955 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 173 in 7
counting down 1697078001
2014-08-14 11:03:08,962 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 174 in 7
counting down 53209944
2014-08-14 11:03:08,969 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 175 in 7
counting down 957271051
2014-08-14 11:03:08,983 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 176 in 14
counting down 260602422
2014-08-14 11:03:08,991 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 177 in 8
counting down 1344752100
2014-08-14 11:03:08,996 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 178 in 5
counting down 210373011
2014-08-14 11:03:09,003 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 179 in 7
counting down 1135342237
counting down 255748372
2014-08-14 11:03:09,008 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 180 in 5
2014-08-14 11:03:09,013 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 181 in 5
counting down 1706850686
2014-08-14 11:03:09,018 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 182 in 5
counting down 958800587
2014-08-14 11:03:09,023 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 183 in 5
counting down 621084776
counting down 1494203157
2014-08-14 11:03:09,028 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 184 in 5
2014-08-14 11:03:09,034 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 185 in 6
counting down 1610501827
2014-08-14 11:03:09,039 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 186 in 5
counting down 1472601997
2014-08-14 11:03:09,046 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 187 in 6
counting down 1523401565
2014-08-14 11:03:09,052 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 188 in 6
counting down 2118032386
2014-08-14 11:03:09,058 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 189 in 6
counting down 1402690896
2014-08-14 11:03:09,063 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 190 in 5
counting down 877005529
counting down 69300391
2014-08-14 11:03:09,068 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 191 in 5
counting down 250950317
2014-08-14 11:03:09,074 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 192 in 6
2014-08-14 11:03:09,080 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 193 in 6
counting down 126717950
2014-08-14 11:03:09,086 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 194 in 6
counting down 60378388
2014-08-14 11:03:09,092 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 195 in 6
counting down 213037448
2014-08-14 11:03:09,098 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 196 in 6
counting down 737512169
2014-08-14 11:03:09,103 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 197 in 5
counting down 1089208854
2014-08-14 11:03:09,109 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 198 in 6
counting down 156501746
2014-08-14 11:03:09,115 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 199 in 6
counting down 284416161
2014-08-14 11:03:09,121 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - added 200 in 6
2014-08-14 11:03:09,123 INFO [com.couchbase.client.CouchbaseConnection] - Shut down Couchbase client
2014-08-14 11:03:09,125 INFO [com.couchbase.client.ViewConnection] - I/O reactor terminated
2014-08-14 11:03:09,125 INFO [com.milansimonovic.jepsen.CouchTimeoutTest] - DONE!
Disconnected from the target VM, address: '127.0.0.1:61775', transport: 'socket'

Process finished with exit code 0

Comment by Michael Nitschinger [ 14/Aug/14 ]
https://github.com/mbsimonovic/jepsen-couchbase/pull/2
Comment by Matt Ingenthron [ 18/Aug/14 ]
Milan: would be great if you could update your blog with a paragraph or so at the top clarifying that it did work so people don't have to read into the comments to find that it was a problem with the test.
Comment by Milan Simonovic [ 19/Aug/14 ]
Sure, as soon as I get back from holidays (next we latest). Ps the tracker is major pain in the a** to use on a smartphone..
Comment by Milan Simonovic [ 26/Aug/14 ]
updated, feel free to close the issue
Comment by Michael Nitschinger [ 26/Aug/14 ]
Not an issue.




[JCBC-521] VBucketNodeLocator.java getPrimary() and getReplica() log messages are homologous Created: 21/Aug/14  Updated: 25/Aug/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Minor
Reporter: Mark Woosey Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate

 Description   
VBucketNodeLocator.java has these two methods:
- getPrimary(String k)
- getReplica(String key, int index)

These two write almost the same warning log message when it can't access a node which holds the key.

getPrimary() logs: "for which no server is responsible in the cluster map (-1)."
while
getReplica() logs: "for which no server is responsible in the cluster map."
(without -1 in the message)

 Comments   
Comment by Koji Kawamura [ 21/Aug/14 ]
These two methods log almost the same warning messages, but since those two are indicating different level of severity, those better to be differentiated.
Comment by Michael Nitschinger [ 25/Aug/14 ]
I think it would be okay to push the replica one down to INFO level.Would that be sufficient? I'd rather not change the message itself in a bugfix release.
Comment by Koji Kawamura [ 25/Aug/14 ]
Changing log level of missing replica node to INFO sounds reasonable. Thank you!




[JCBC-530] Exception when using java client both in Spark and MapReduce Created: 25/Aug/14  Updated: 25/Aug/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Critical
Reporter: Sun Chen Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: Hadoop,Dependencies,HttpCore, Spark,
Remaining Estimate: 40h
Time Spent: Not Specified
Original Estimate: 40h
Environment: Haddop2.4.1,Spark0.13,Java1.7,Ubuntu12.04


 Description   
I am using Couchbase java client(version 1.4.4),I writed some simple mapreaduce job and spark job to write and read data from Couchbase.But I always got an exception.Here is the exception information

-------------------------------------------------------------------------------------------------------------------------------------------------
2014-08-25 13:12:56,048 FATAL [main] org.apache.hadoop.mapred.YarnChild: Error running child : java.lang.NoSuchMethodError: org.apache.http.protocol.RequestUserAgent.<init>(Ljava/lang/String;)V
at com.couchbase.client.ViewConnection.<init>(ViewConnection.java:156)
at com.couchbase.client.CouchbaseConnectionFactory.createViewConnection(CouchbaseConnectionFactory.java:254)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:266)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:194)
at com.eyespage.dc.etl.CouchbaseImportExtractor.extract(CouchbaseImportExtractor.java:31)
at com.eyespage.dc.etl.CouchbaseImportExtractor.extract(CouchbaseImportExtractor.java:20)
at org.apache.sqoop.job.mr.SqoopMapper.run(SqoopMapper.java:96)
at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:764)
at org.apache.hadoop.mapred.MapTask.run(MapTask.java:340)
at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:167)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1556)
at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:162)
-------------------------------------------------------------------------------------------------------------------------------------------

14/08/09 10:19:32 WARN Utils: Your hostname, precise64 resolves to a loopback address: 127.0.1.1; using 192.168.33.10 instead (on interface eth1) 14/08/09 10:19:32 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address 14/08/09 10:19:38 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable 2014-08-09 10:19:40.569 INFO net.spy.memcached.auth.AuthThread: Authenticated to /127.0.0.1:11210 2014-08-09 10:19:40.677 INFO com.couchbase.client.vbucket.provider.BucketConfigurationProvider: Could bootstrap through carrier publication. 2014-08-09 10:19:40.693 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=localhost/127.0.0.1:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2014-08-09 10:19:40.702 INFO com.couchbase.client.CouchbaseClient: CouchbaseConnectionFactory{bucket='Result', nodes=[http://127.0.0.1:8091/pools], order=RANDOM, opTimeout=2500, opQueue=16384, opQueueBlockTime=10000, obsPollInt=10, obsPollMax=500, obsTimeout=5000, viewConns=10, viewTimeout=75000, viewWorkers=1, configCheck=10, reconnectInt=1100, failureMode=Redistribute, hashAlgo=NATIVE_HASH, authWaitTime=2500} Exception in thread "main" java.lang.NoSuchMethodError: org.apache.http.protocol.RequestUserAgent.<init>(Ljava/lang/String;)V at com.couchbase.client.ViewConnection.<init>(ViewConnection.java:156) at com.couchbase.client.CouchbaseConnectionFactory.createViewConnection(CouchbaseConnectionFactory.java:254) at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:266) at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:194) at com.eyespage.dc.etl.c2s.Run$.main(main.scala:16) at com.eyespage.dc.etl.c2s.Run.main(main.scala) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.spark.deploy.SparkSubmit$.launch(SparkSubmit.scala:303) at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:55) at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala) 2014-08-09 10:19:40.836 INFO net.spy.memcached.auth.AuthThread: Authenticated to localhost/127.0.0.1:11210 - See more at: http://www.couchbase.com/communities/q-and-a/exception-when-using-scala-call-java-sdk%EF%BC%8Cand-run-spark#sthash.CmL5dcRz.dpuf








[JCBC-485] JsonObject and all its similars Created: 06/Jul/14  Updated: 24/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Oded Hassidi Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: json
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Why should I work with JsonObject, JsonArray and all of that? Why can't I just send a String and you guys do with it what ever you want? Or at least give us a utility to convert our Pojo to your JsonObject?

If there is such utility I take it back :)

 Comments   
Comment by Michael Nitschinger [ 07/Jul/14 ]
Hi,

yes you are right, and we will provide that functionality as well once we get to feature completeness on 2.0. There has already been a user contribution to a converter which will act like the one on 1.4 so you can then pass in a string and it will be stored. So you get the both of two worlds.

Does that work for you?
Comment by Michael Nitschinger [ 21/Aug/14 ]
We have implemented a LegacyDocument where you can pass in a string and it works like the old one. We probably add more documents (string,...) directly so you can have more fun with it.

I'll close this one for now since it works with beta/dp3 already using the legacy codec and open more issues for specific transcoders/documents.
Comment by Oded Hassidi [ 24/Aug/14 ]
Thanks




[JCBC-526] Add support for bucket management operations Created: 22/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: New Feature Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-527] Add cluster info Created: 22/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: New Feature Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-524] Add support for custom transcoders Created: 22/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-513] Implement bucket.close() Created: 18/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Critical
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-522] Implement bucket info. Created: 22/Aug/14  Updated: 22/Aug/14  Resolved: 22/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-479] ComparisonFailure in running unit tests for 2.0 client Created: 24/Jun/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Infrastructure
Affects Version/s: 2.0.0
Fix Version/s: 2.0-beta
Security Level: Public

Type: Bug Priority: Test Blocker
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
1 warning
:processTestResources UP-TO-DATE
:testClasses
:test

com.couchbase.client.java.document.json.JsonObjectTest > shouldExportMix FAILED
    org.junit.ComparisonFailure at JsonObjectTest.java:27

com.couchbase.client.java.query.ViewQueryTest > shouldHandleEndKey FAILED
    org.junit.ComparisonFailure at ViewQueryTest.java:178

77 tests completed, 2 failed
:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at: file:///root/couchbase/sdkd-2.0/couchbase-java-client/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED


 Comments   
Comment by Wei-Li Liu [ 15/Jul/14 ]
I am getting different failure running unit test

===================================================================================
1 warning
:processTestResources UP-TO-DATE
:testClasses
:test

com.couchbase.client.java.convert.JacksonJsonConverterTest > shouldEncodeSimpleJsonObject FAILED
    org.junit.ComparisonFailure at JacksonJsonConverterTest.java:70

com.couchbase.client.java.convert.JacksonJsonConverterTest > shouldEncodeMixedNestedJsonValues FAILED
    org.junit.ComparisonFailure at JacksonJsonConverterTest.java:177

77 tests completed, 2 failed
:test FAILED

FAILURE: Build failed with an exception.
Comment by Wei-Li Liu [ 15/Jul/14 ]
Failure running integration tests


============================================================================
wei-lis-mbp:couchbase-java-client wei-li$ ./gradlew integrationTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileIntegrationJava UP-TO-DATE
:processIntegrationResources UP-TO-DATE
:integrationClasses UP-TO-DATE
:integrationTest

com.couchbase.client.java.BinaryTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.BinaryTest > classMethod FAILED
    java.util.NoSuchElementException

com.couchbase.client.java.QueryTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.QueryTest > classMethod FAILED
    java.util.NoSuchElementException

com.couchbase.client.java.ViewTest > classMethod FAILED
    com.couchbase.client.core.config.ConfigurationException
        Caused by: java.lang.IllegalStateException
            Caused by: rx.exceptions.OnErrorThrowable$OnNextValue

com.couchbase.client.java.ViewTest > classMethod FAILED
    java.util.NoSuchElementException

6 tests completed, 6 failed
:integrationTest FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':integrationTest'.
> There were failing tests. See the report at: file:///Users/wei-li/repo/couchbase/sdkd-2.0/couchbase-java-client/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Comment by Wei-Li Liu [ 15/Jul/14 ]
Disregard the above integration test failure. It requires to create "default" bucket and set no password to run.
Comment by Wei-Li Liu [ 18/Aug/14 ]
Running 2.0-dp3 feature test against 1118 server, and all of the unit test and integration tests passed. I am resolving this ticket.
Comment by Deepti Dawar [ 19/Aug/14 ]
Hi Michael, Please close this when you push the fix for it.

Thanks !
Comment by Michael Nitschinger [ 19/Aug/14 ]
Should be fixed in master, please reopen if not.
Comment by Wei-Li Liu [ 20/Aug/14 ]
I run int test on master today and there is 1 failure on shouldUpsertLegacyObjectDocument

com.couchbase.client.java.BinaryTest STANDARD_ERROR
    log4j:WARN No appenders could be found for logger (com.couchbase.client.core.logging.CouchbaseLoggerFactory).
    log4j:WARN Please initialize the log4j system properly.
    log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.

com.couchbase.client.java.BinaryTest > shouldUpsertLegacyObjectDocument FAILED
    java.lang.NullPointerException
        at com.couchbase.client.java.BinaryTest.shouldUpsertLegacyObjectDocument(BinaryTest.java:295)
Gradle Worker 1 finished executing tests.

28 tests completed, 1 failed
Comment by Michael Nitschinger [ 21/Aug/14 ]
Hm there might be an issue with the new legacy document, a different test is failing for me.

Is there any other info in the logs what's going on?
Comment by Deepti Dawar [ 21/Aug/14 ]
The unit tests now run fine.
Tried with the latest of DP3.
Comment by Wei-Li Liu [ 21/Aug/14 ]
stacktrace for legacy document test

11:40:54.879 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldUpsertLegacyObjectDocument STARTED
11:40:54.918 [DEBUG] [TestEventLogger]
11:40:54.918 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldUpsertLegacyObjectDocument FAILED
11:40:54.918 [DEBUG] [TestEventLogger] java.lang.NullPointerException
11:40:54.918 [DEBUG] [TestEventLogger] at com.couchbase.client.java.BinaryTest.shouldUpsertLegacyObjectDocument(BinaryTest.java:295)
11:40:54.919 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:40:54.919 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:40:54.919 [DEBUG] [TestEventLogger] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:40:54.919 [DEBUG] [TestEventLogger] at java.lang.reflect.Method.invoke(Method.java:483)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
11:40:54.919 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
11:40:54.920 [DEBUG] [TestEventLogger] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
11:40:54.921 [DEBUG] [TestEventLogger] at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:69)
11:40:54.921 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
11:40:54.921 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:40:54.921 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:40:54.921 [DEBUG] [TestEventLogger] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:40:54.922 [DEBUG] [TestEventLogger] at java.lang.reflect.Method.invoke(Method.java:483)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
11:40:54.922 [DEBUG] [TestEventLogger] at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
11:40:54.922 [DEBUG] [TestEventLogger] at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:105)
11:40:54.922 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:40:54.922 [DEBUG] [TestEventLogger] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
11:40:54.922 [DEBUG] [TestEventLogger] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
11:40:54.923 [DEBUG] [TestEventLogger] at java.lang.reflect.Method.invoke(Method.java:483)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
11:40:54.923 [DEBUG] [TestEventLogger] at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
11:40:54.923 [DEBUG] [TestEventLogger] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
11:40:54.923 [DEBUG] [TestEventLogger] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
11:40:54.923 [DEBUG] [TestEventLogger] at java.lang.Thread.run(Thread.java:745)
11:40:54.925 [DEBUG] [TestEventLogger]
11:40:54.925 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldInsertAndGet STARTED
11:40:54.925 [DEBUG] [TestEventLogger]
11:40:54.925 [DEBUG] [TestEventLogger] com.couchbase.client.java.BinaryTest > shouldInsertAndGet PASSED
11:40:57.110 [QUIET] [system.out] 11:40:57.110 [
11:40:57.110 [DEBUG] [TestEventLogger]
11:40:57.110 [QUIET] [system.out] DEBUG] [org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor] Executing test class com.couchbase.client.java.DesignDocumentTest
Comment by Wei-Li Liu [ 21/Aug/14 ]
This exception is caused by integration test, which is somewhat a duplicate of JCBC-481.
unit test works fine for me too.




[JCBC-499] Test SSL Feature with Java 2.0 SDK Created: 28/Jul/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Closed
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 2.0-dp2
Fix Version/s: 2.0-beta
Security Level: Public

Type: Bug Priority: Test Blocker
Reporter: Wei-Li Liu Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ssl.pcapng    

 Description   
Michael, here is the SSL Feature Test I created
https://github.com/couchbase/couchbase-java-client/pull/6/files
I know there are suff should be in core, and we can move it later

There are a couple issues in this feature tests

1. view and query test hangs
2. the ssl test I created is not able to catch exceptions such as sun.security.validator.ValidatorException, javax.net.ssl.SSLHandshakeException. etc

We can’t disable SSL from the server side after starting the server. SSL certificate automatically generated and self signed, so we can’t modify expired date.

I also test 2.5 server connect with java client, which does not work with SSL.

Attached file is wireshark packet capture fro FeatureTest with SSL. If you decode it with SSL in Wireshark, you can see the data and TLS protocol.
  



 Comments   
Comment by Wei-Li Liu [ 30/Jul/14 ]
java sdk's commit on observe relies on core
https://github.com/weilliu/couchbase-java-client/commit/6f8d672ff9a600780fd5d7d47d5ba6ce52bd083d

import com.couchbase.client.core.message.binary.ObserveRequest;
import com.couchbase.client.core.message.binary.ObserveResponse;

Currently Core can't be built on master

====================================
[root@centos-64-x64 couchbase-jvm-core]# ./gradlew install
:compileJava
Note: /root/sdkd-2.0/couchbase-jvm-core/src/main/java/com/couchbase/client/core/CouchbaseCore.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:processResources
:classes
:jar
:javadoc
java.lang.UnsupportedClassVersionError: ch/raffael/doclets/pegdown/PegdownDoclet : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
at com.sun.tools.javadoc.DocletInvoker.<init>(DocletInvoker.java:96)
at com.sun.tools.javadoc.Start.setDocletInvoker(Start.java:414)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:213)
at com.sun.tools.javadoc.Start.begin(Start.java:162)
at com.sun.tools.javadoc.Main.execute(Main.java:59)
at com.sun.tools.javadoc.Main.main(Main.java:49)
javadoc: error - fatal error
1 error
:javadoc FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':javadoc'.
> Javadoc generation failed.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 24.87 secs
====================================================

Comment by Wei-Li Liu [ 04/Aug/14 ]
Please disregard my above error, which is triggered by inconsistent jdk version on run time and compile time.
Comment by Don Pinto [ 11/Aug/14 ]
Wei-li, can you update this ticket?
Comment by Wei-Li Liu [ 11/Aug/14 ]
@Michael looking at your most recent commit, I don't think the catching exception issue has been fixed yet. I believe you just changed the fix version to 2.0-beta.
I also have some issues build couchbase-java-client from master after I pull both sdk and the core. I knew Deepti has the same issue earlier, but not sure if it has been resolved yet.
Comment by Matt Ingenthron [ 18/Aug/14 ]
Michael: this is blocking completion of testing, can you aim to resolve it this week.
Comment by Wei-Li Liu [ 18/Aug/14 ]
After getting some help from Deepti, I am able to get dp3 build with ./gradlew publish and ./gradlew publishToMavenLocal
Integration test has been changed in dp3, so some modifications required for SSL feature tests on my end.
Comment by Wei-Li Liu [ 20/Aug/14 ]
Report bug JCBC-520
Comment by Michael Nitschinger [ 21/Aug/14 ]
So are we tracking it in JCBC-520 and closing this?
Comment by Wei-Li Liu [ 21/Aug/14 ]
okay




[JCBC-514] Only shutdown environment if not shared Created: 18/Aug/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-498] I can't connect to an authenticated bucket Created: 28/Jul/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 2.0-dp2
Fix Version/s: 2.0-beta
Security Level: Public

Type: Task Priority: Major
Reporter: Gareth Powell Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: MacOS X

Attachments: Text File trace.txt    

 Description   
I can't connect to a password-protected bucket with SDK 2-dp2.

"Similar" code can connect with SDK 1.4.

Here is my approximate code:

cluster = new CouchbaseCluster(couchConfig.fromHost);

Bucket bucket = cluster.openBucket(couchConfig.bucket, couchConfig.passwd).toBlocking().single();

if (couchConfig.clearDB)

bucket.flush().toBlocking().single();

where "fromHost" is set to "warburton", "bucket" is ziggrid-baseball and password is "". (Yes, that is the password on the bucket in development).

 Comments   
Comment by Michael Nitschinger [ 04/Aug/14 ]
thanks, I'll look into it soon. Let's see if I can fix that for dp3
Comment by Gareth Powell [ 20/Aug/14 ]
I just tried this and in dp3 I can "kind of" get it to work.

The thing is, I couldn't use the code above (presumably due to API changes) and that suggests the code above might always have been invalid.

I changed:

cluster = new CouchbaseCluster(couchConfig.fromHost);

to

cluster = CouchbaseCluster.create(couchConfig.fromHost);

and

bucket.flush().toBlocking().single();

to

bucket.bucketManager().toBlocking().single().flush().toBlocking().single();
Comment by Michael Nitschinger [ 20/Aug/14 ]
Yup, your changes look good. What do you mean by kind of? Does it work with the changes?
Comment by Gareth Powell [ 20/Aug/14 ]
Yes, it works now. At the time I made the comment, I was able to connect and clear out the bucket, but nothing else appeared to be working.

The problem I'm having is the usual migration one: I have so many errors in my code from the API changing that it's hard to tell what is going wrong. It turns out that my line of execution was being sabotaged by a broken dependency that wasn't getting caught. When I was able to fix that, I was able to get to the stage of loading a design document.

I now have design documents and regular documents loading.
Comment by Michael Nitschinger [ 21/Aug/14 ]
Perfect, thanks. Let me know if you run into more issues.




[JCBC-516] All internal code should use the provided scheduler from the environment Created: 18/Aug/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Michael Nitschinger [ 21/Aug/14 ]
fixed in the core.




[JCBC-497] reduce in ViewQuery doesn't work Created: 27/Jul/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Views
Affects Version/s: 2.0-dp2
Fix Version/s: 2.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Oded Hassidi Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When querying using views, setting the reduce(false) seems to have no influence on the query and always reduces the query.

Am I missing something?

 Comments   
Comment by Michael Nitschinger [ 28/Jul/14 ]
Thanks, I'll look into it.
Comment by Michael Nitschinger [ 21/Aug/14 ]
Works in dp3 and on master!

Make sure that if you have a view with a reduce function, set .reduce(false) on the DSL to disable it optionally.




[JCBC-512] $HOST in Refresher against localhost Created: 18/Aug/14  Updated: 21/Aug/14  Resolved: 21/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Bug Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
carrier (and maybe also http refresher) don't replace $HOST

 Comments   
Comment by Michael Nitschinger [ 21/Aug/14 ]
Done in core.




[JCBC-519] Timeout Not Honored on First Call to Java asyncGetBulk Created: 11/Aug/14  Updated: 20/Aug/14

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.4
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Jeff Dillon Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File App.java    
Issue Links:
Duplicate

 Description   
This was observed on Couchbase Server 2.2.0. The same behavior is not evident on Couchbase Server 2.5.1. It appears to be independent of any Java client version. The very first call of asyncGetBulk does not respect the timeout value, and continues to process and wait. Subsequent calls do properly respect the timeout value. One interesting note is that this only occurs when the timeout value is "close" to the actual execution time. That is, a very short timeout is indeed honored.

Steps to reproduce:

* Download a Java client, such as http://packages.couchbase.com/clients/java/1.4.3/Couchbase-Java-Client-1.4.3.zip

* Unzip

* Copy the attached App.java into the unzipped directory

* Compile and run:

javac -cp couchbase-client-1.4.3.jar:spymemcached-2.11.4.jar App.java

java -cp .:couchbase-client-1.4.3.jar:spymemcached-2.11.4.jar:jettison-1.1.jar:netty-3.5.5.Final.jar:commons-codec-1.5.jar:httpcore-4.3.jar:httpcore-nio-4.3.jar App > 143.txt

* Note the following output in the first group. It would be expected that the first call would timeout, but does not:

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=108ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=17ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=18ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=16ms


Exception:********************
Timeout future is: true
Operation timed out. - failing nodes: 10.4.2.107/10.4.2.107:11210, cbhost.domain/10.4.2.57:11210
Timeout set to:16
getMulti : Time taken=18ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=17ms


ASK - Determine why the first call does not honor the timeout, and ideally suggest a workaround for Couchbase Server 2.2.0, short of upgrading to Couchbase Server 2.5.1 (where the issue does not appear exist, and therefore looks to be a server-side issue)




 Comments   
Comment by Aleksey Kondratenko [ 11/Aug/14 ]
Not honoring timeouts cannot be server side issue. Passing to Michael who owns couchbase java sdk
Comment by Jeff Dillon [ 12/Aug/14 ]
Please disregard my previous comments with respect to being apparently fixed with Couchbase Server 2.5.1. This behavior evidences itself across all CB server versions, and also reproduces with CB Java client 1.4.4. In my latest 2.5.1 test, I set the timeout to 30 ms, and see the same incorrect behavior. So this is indeed a client issue (as noted), apologies on the initial misinformation.
Comment by Michael Nitschinger [ 14/Aug/14 ]
A few remarks:

- The simple benchmark also profiles logging and so forth.
- System.currentTimeMillis() precision is sometimes beyond all joke, always use nanotime.

So something like this is more accurate:

        while (low == 10) {
            try {
                startTime = System.nanoTime();
                future = client.asyncGetBulk(Main.getKeys());
                future.get(timeout, TimeUnit.MILLISECONDS);
                endTime = System.nanoTime();
                System.out.println("Timeout future is: " + future.isTimeout());
                System.out.println("Fetched " + Main.getKeys().size() + " keys");
            } catch (Exception e) {
                System.out.println("\nException:********************\nTimeout future is: " + future.isTimeout());
                System.out.println(e.getMessage());
            }
            operationTime = endTime - startTime;
            System.out.println("Timeout set to:" + timeout + "\ngetMulti : Time taken=" + TimeUnit.NANOSECONDS.toMillis(operationTime) + "ms\n");
        }

Now also note that profiling on the blocking .get() call not only waits on the latch where the timeout is applied, but it also puts all data together and so forth. So as far as I can see it the timeout is honored, its just not what you benchmark that close. Keep in mind that the first few calls are subject t JVM warmup, optimizations and so forth which can take some time. It's not a huge surprise that the first few calls are slightly slower, but I guess thats not what the JVM optimizes for compared to a long-running server.

Does that help?
Comment by Jeff Dillon [ 14/Aug/14 ]
I am seeing the same behavior when using nanoTime. And it's not slightly slower, it's an order of magnitude difference. And I don't think it's JVM warmup either, as different timeout values show consistent differences every time. Using a short time out value works as expected, but is not the timeout value they desire. When the timeout is "close" to the actual execution time, it experiences this behavior. This is what I'm seeing in my tests, and is what the customer is seeing also.
Comment by Matt Ingenthron [ 20/Aug/14 ]
Jeff Dillon: I understand from James this has been observed on 2.5.1 now as well. Can you confirm and update it appropriately? Also, I've moved it to JCBC, since the investigation has lead here.
Comment by Jeff Dillon [ 20/Aug/14 ]
Yes, please see my previous comment from 12/Aug/14 1:47 PM




[JCBC-517] Add overloads for Persist/Replicate only Created: 18/Aug/14  Updated: 18/Aug/14  Resolved: 18/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-515] Simplify environment and collapse properties Created: 18/Aug/14  Updated: 18/Aug/14  Resolved: 18/Aug/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-beta
Security Level: Public

Type: Improvement Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified