[JCBC-615] Java Client loses connection and it's never recovered Created: 31/Oct/14  Updated: 31/Oct/14

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

Type: Bug Priority: Major
Reporter: Facundo Farias Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: couchbase-server-community_x86_64_2.2.0 (AWS AMI) / java couchbase-client.version 1.4.4


 Description   
We are having an issue running only on production (we can't reproduce this issue on our local environments), and basically it is that, when because an external reason our backend loses connection with the couchbase cluster, then it never reconnects again.

The only way we found to reproduce this issue was:
1. Run the application, with the couchbase instance running as well,
2. When everything it's okay, then shutdown the couchbase process,
3. Try to perform some action on the system, which will fail, because the connection was lost,
4. Run again the couchbase server,
5. The expected behavior should be, to detect again the running instance and reconnect, however if we what this to happen, we have to restart our application server.

Questions:
- Should we implement some kind of mechanism to provide reconnection? How can we implement this? Do you have some kind of guide?
- We also know there was release a newer version of the java sdk (2.0), do you know if this issue was solved?

Appendix:
The exception we are receiving when we lost connection is:
{code}
» 05:08:22.090 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
» 05:08:22.090 at org.eclipse.jetty.server.Server.handle(Server.java:461)
» 05:08:22.090 at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
» 05:08:22.090 at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
» 05:08:22.090 at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
» 05:08:22.090 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
» 05:08:22.090 at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
» 05:08:22.090 at java.lang.Thread.run(Thread.java:745)
» 05:08:22.090 Caused by: net.spy.memcached.internal.CheckedOperationTimeoutException: Operation timed out. - failing nodes: [OUR_AWS_NODES] Exception
» 05:08:22.090 at net.spy.memcached.internal.BulkGetFuture.get(BulkGetFuture.java:127)
» 05:08:22.090 at net.spy.memcached.internal.BulkGetFuture.get(BulkGetFuture.java:52)
» 05:08:22.090 at com.couchbase.client.internal.ViewFuture.get(ViewFuture.java:72)
» 05:08:22.090 at com.couchbase.client.internal.ViewFuture.get(ViewFuture.java:50)
» 05:08:22.090 at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:72)
» 05:08:22.090 ... 63 more
» 05:08:22.291 2014-10-30 04:08:22 ERROR GeneralExceptionMapperProvider:22 - [OUR_AWS_IP] Timed out waiting for operation
{code}

Thanks

 Comments   
Comment by Michael Nitschinger [ 31/Oct/14 ]
Hi,

please try 1.4.5, we made fixes in that area and report back if it helps or not -thanks!
Comment by Facundo Farias [ 31/Oct/14 ]
Okay, so I've installed the new Client version (1.4.5) and then, I've performed the explained steps again.

So, for a few minutes I kept without connection, but then the client realized that the node was up, and reconnected automatically (something that wasn't doing before). So, we will try out this change on production, and I will let you know.
Just for the record, this is the stack-trace:

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
Caused by: net.spy.memcached.internal.CheckedOperationTimeoutException: Operation timed out. - failing node: localhost/127.0.0.1:11210
at net.spy.memcached.internal.BulkGetFuture.get(BulkGetFuture.java:127)
at net.spy.memcached.internal.BulkGetFuture.get(BulkGetFuture.java:52)
at com.couchbase.client.internal.ViewFuture.get(ViewFuture.java:72)
at com.couchbase.client.internal.ViewFuture.get(ViewFuture.java:50)
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:72)
... 69 more
2014-10-31 16:40:15.469 INFO com.couchbase.client.CouchbaseConnection: Reconnecting {QA sa=localhost/127.0.0.1:11210, #Rops=0, #Wops=5, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 19, toWrite=0, interested=0}

Thanks!




[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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-437] implement JSR-107 Java Temporary Caching API Created: 25/Mar/14  Updated: 31/Jul/14

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

Type: Task Priority: Critical
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   
As previously discussed, we should look to implement JSR-107 to meet the standards.




[JCBC-496] Add unit test for JCBC-488 Created: 22/Jul/14  Updated: 28/Jul/14

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

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


 Description   
We need to add a unit test for the fix in http://www.couchbase.com/issues/browse/JCBC-488 just to make sure it works as expected. The appropriate change ishttp://review.couchbase.org/#/c/39429/ and has been merged already.

I'd propose a unit test which mocks out the underlying stuff and just pushes a HttpOperation a few times through the ViewConnection#addOp which should add the headers only 1 times instead of N.

 Comments   
Comment by Wei-Li Liu [ 25/Jul/14 ]
I think we have something similar to JCBC-488 test case in the scenario test framework (Service Restart)

I pull in your fix http://review.couchbase.org/#/c/39429/ and reproduce the issue by switching thread # to 200 instead of 10 (default)
The report shows that if thread is 10 works for both mc (get,set) and ht, cb (view, query). If jumps thread # to 200, view and query workload would fail
https://docs.google.com/spreadsheets/d/1sjDpJL_xuVv3kDhbnJKn5qNLmvzCi80gbdq5FkOObzQ/edit#gid=1476387871

I can make a separate unit test to make sure when there are multiple http operations, there can only be 1 header.






[JCBC-440] Inconsistent result of paginated query. Created: 26/Mar/14  Updated: 09/Jul/14

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

Type: Bug Priority: Major
Reporter: Vladislav Koroteev Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
Java 7
Couchbase Server Community Edition 2.2.0


 Description   
I get a strange behavior with paginated query. While I paginate on the result set, I get duplicates of some documents. I'm doing the following in my code:

// force start indexing of view
query.setStale(Stale.FALSE);
query.setReduce(true);
ViewResponse respFromReduce = client.query(view, query);
String expectedCountFromScroll = null;
for (ViewRow viewRow : respFromReduce) {
    expectedCountFromScroll = viewRow.getValue();
}
query.setReduce(false);
query.setIncludeDocs(false);
//disable indexing of view from sdk
query.setStale(Stale.OK);
Paginator scroll = client.paginatedQuery(view, query, SCROLL_SIZE);
int docsFromScrollCnt = 0;
while (scroll.hasNext()) {
    ViewResponse response = scroll.next();
    docsFromScrollCnt += response.size();
}

And I see, that docsFromScrollCnt > expectedCountFromScroll.
I think, that while query Couchbase auto-indexing view, so I decide to disable auto-indexing by set viewUpdateDeamon's parameters. I set updateInterval to value, that greater then querying time, updateMinChanges and replicaUpdateMinChanges to zero.

It's not helped, but I noticed following interesting feature. Count of duplicate documents always equals n*SCROLL_SIZE.

How can I avoid duplicate of document from paginated query?

- See more at: http://www.couchbase.com/communities/q-and-a/strange-behavior-paginated-query#sthash.MLFf15Gx.dpuf

 Comments   
Comment by Michael Nitschinger [ 02/Jun/14 ]
Hi,

I need further clarification on the use case to triage this.

- Are you running workload while doing the request? That is, are you updating documents? Keep in mind that even with stale=false, the indexer on the server updates the view in the background and the results can change during the pagination.

- What reduce function do you use?

I'm pretty sure this is because the data is updated in between the calls, remember that your reduce call is more or less "atomic", but if you paginate on results there is no cursor, you are getting the batches with potential indexer updates in between.
Comment by Vladislav Koroteev [ 08/Jul/14 ]
- Are you running workload while doing the request?
Yes. When I get document from result set I change field on which I make view. For example, I have map-function {emit(doc.a, null)} and I changed field "a" of document. But I disable auto-indexing by set viewUpdateDeamon's parameters with REST-API. So I think, that indexing don't started. Also I use stale=OK while paginating result set of view. So, I don't understand why I have such result of view.

- What reduce function do you use?
I use built-in _count function.

-I'm pretty sure this is because the data is updated in between the calls, remember that your reduce call is more or less "atomic"
Before my test, database is not workload. I see, that process of auto-indexing is finished, because I call from web-interface reduce function with stale=FALSE. After that I disable auto-indexing, that's why result of view confused me.
Comment by Michael Nitschinger [ 09/Jul/14 ]
Normally there is an indexer running in the background, how did you disable auto-indexing? Also, if you want stale data you need to use stale=OK (since stale=false will update the index). If you on the other hand need 100% accurate results you need to do stale=false AND PersistTo.MASTER on the write side.
Comment by Vladislav Koroteev [ 09/Jul/14 ]
-how did you disable auto-indexing?

From documentation http://docs.couchbase.com/couchbase-manual-2.2/#automated-index-updates.
I make such http-request "POST http://nodename:8091/settings/viewUpdateDaemon updateInterval=10000000&updateMinChanges=0"

I request view reduce function with stale=FALSE. So I make index is fresh. Then I request view with stale=OK in order to avoid indexing of view, but still get duplicates documents in result set. Another strange feature, that count of duplicates always equals N*SCROLL_SIZE. N is variable in different requests.




[JCBC-447] add feature test ensuring that E2BIG is returned on append above 20MB Created: 07/Apr/14  Updated: 23/Jun/14

Status: In Progress
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.3.2, 1.4.0-dp1
Fix Version/s: .future
Security Level: Public

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

Issue Links:
Dependency
depends on MB-10778 Append do not return the correct erro... Closed

 Description   
When continuing to append beyond the maximum value of 20MByte, we should verify that applications receive the correct error response.

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
Do you want to take this on?
Comment by Deepti Dawar [ 23/Jun/14 ]
Up for review - http://review.couchbase.org/#/c/38675/1




[JCBC-467] Java client not aware of failed over node under certain circumstances Created: 10/Jun/14  Updated: 23/Jun/14

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

Type: Task Priority: Critical
Reporter: Robert Waite 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 anotherMultithreadTest.java     Java Source File CouchbaseClientTesterFastAndThreaded.java     Java Source File CouchbaseClientTester.java     Java Source File CouchbaseClientTesterNewer.java     Text File logAfterSeemingFreeze.txt     Text File threadDumpDuringFreezeSunJVM.txt     Text File threadDumpDuringFreeze.txt    

 Description   
This is similar to http://www.couchbase.com/communities/q-and-a/java-client-not-aware-about...

This is using the 1.4.2 java client.

If I failover from the admin console while the node is still up... it does not reproduce. I found the best way to simulate the node suddenly becoming unresponsive is to use IP tables to block all traffic except SSH on port 22 like so:

To block a node:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT; iptables -A INPUT -j DROP

To unblock a node:
iptables -F

It also seems to not reproduce if I remove the nested try/catch (i.e. don't try to read from the replica).

Failover seems to not be instantaneous... it takes 1-2 minutes with my hardware and setup. The following steps can be seen with the code below (might be reproducible with less steps but this seems consistent):

1) Create a two node cluster with 1 level of replication
2) Set the code below with the proper host names, bucket name and password
3) Run the code and you will see "Got From Master" 5 times
4) It will then pause and ask you to block traffic from the master node
5) Look at the admin console to see which node is the master for the key
6) Block the master node with iptables and then hit 'Enter'
7) Go back to the output and it will then output "Got From Replica" 10 times
8) It will then pause and ask for you to go to the admin console (on the replica node)
9) Wait until the master node is marked as "Down"
10) Once it is marked as "Down", fail over the master node
11) Go back to the console and hit 'Enter'

At this point the console should continue printing "Got From Replica". If you look at the admin console the replica node still has 0 items active and 1 item replicated. After 1-3 minutes it should suddenly say 1 item is active and 0 items are replicated (failover seems delayed). You will also notice at the same time that an exception started showing up in the console.

Expected: Once the node is fully failed over, it should no longer need to read from the replica and should read from the promoted master

Observed: It doesn't seem to be able to read from the master or the replica. It appears that the client is not marking the promoted replica as the new master.

Questions:

1) What is going on during the failover? I would have thought that failover would have been very fast and not take 1-5 minutes. Especially since I only have one item in the store
2) Anyone know of a workaround? If I catch the exception and rebuild the client... it works. But this would be horrible since the client is accessed by multiple threads.


 Comments   
Comment by Robert Waite [ 10/Jun/14 ]
Attached testing app. (CouchbaseClientTester.java)
Comment by Michael Nitschinger [ 10/Jun/14 ]
Thanks for the report, looking into it. Will provide an update as soon as I find something.
Comment by Michael Nitschinger [ 11/Jun/14 ]
Which server version are you using?
Comment by Michael Nitschinger [ 11/Jun/14 ]
If its 2.5.0 or 2.5.1, could you do me a favor and try setting "System.setProperty("cbclient.disableCarrierBootstrap", "true");" before the CouchbaseClient initialisation and report if it changes things? If its 2.2 nevermind.
Comment by Robert Waite [ 11/Jun/14 ]
It is 2.2.0. I can install 2.5.1 and give it a shot though. I had actually tried the disableCarrierBootstrap option but didn't realize that it wasn't available against the 2.2.0 server.
Comment by Robert Waite [ 11/Jun/14 ]
I upgraded the two nodes to 2.5.1 and added the disableCarrierBootstrap property before client creation. I was still able to repro the issue. There are some new details though:

1) The test will not always reproduce (even against the 2.2.0 server). Sometimes when you click failover from the admin console you will see the following message:

2014-06-11 10:01:35.889 INFO com.couchbase.client.CouchbaseConnectionFactory: Replacing current streaming node list [http://node1:8091/pools, http://node2:8091/pools] with [http://node1:8091/pools]
2014-06-11 10:01:35.894 INFO com.couchbase.client.CouchbaseConnection: Scheduling Node node3/10.1.1.10:11210for shutdown.

When this happens I normally see one more replica get, then it goes to the master and functions like I imagine it should. When testing against 2.5.1 this seems to happen 1 in 3 times. I think it was much less common with 2.2.0... maybe 1 in 8 times. My guess is that this could be related to how quickly failover seems to happen now in 2.5.1. Before... with 2.2.0 the pattern was wait about 1 minute to see the node marked as down, click failover and then see the active item show up on the other node after maybe 30 seconds at which point the error would show. With 2.5.1 the pattern is wait about 1 minute for the node to be marked as down, click failover and then immediately see the item show up on the other node as active and then the error will show.

2) Adding the disableCarrierBootstrap property did not seem to have any effect. I tried with and without maybe 5 times each. Both would show the error about 2 in 3 tests.

3) I altered the test to add the system property and to also continue trying replica gets continuously instead of pausing and waiting for the tester to click failover. Now steps 7+ from the original description are different. Once you complete 6 you should look at the admin console and wait for it to mark the node as down. Once it does, you click failover. If the error occurs then you will see exceptions. If the error does not happen you will see the INFO messages about replacing the current streaming node list and then it will start saying it is reading from the master instead of the replica (which is the desired behavior).
Comment by Robert Waite [ 11/Jun/14 ]
Attaching new version of testing app as CouchbaseClientTesterNewer.java
Comment by Michael Nitschinger [ 11/Jun/14 ]
Thanks very much for the additional info, I'll try to dig in this week and see what I can come up with. I'll let you know if I need anything else.

Again, very much appreciated!
Comment by Robert Waite [ 11/Jun/14 ]
Oh no! When I was testing the property change my POM was pointed at the 1.3.2 client instead of the 1.4.2 client. I have done three tests so far after adjusting the POM and now it seems to recover (I see the exception once but then it starts going to the master).

With this property change I see "Carrier config not available, bootstrapped through HTTP." in the log. Does this mean that the HTTP bootstrapping is not available from servers prior to 2.5.0?
Comment by Michael Nitschinger [ 11/Jun/14 ]
No thats good. It means that carrier config is not available prior to 2.5.0, so 2.2 will use HTTP. the 1.4 SDKs have a carrier -> http fallback, but with the sys property you could disable it on 2.5 as well.
Comment by Michael Nitschinger [ 11/Jun/14 ]
So with 1.4.2 it works?
Comment by Robert Waite [ 11/Jun/14 ]
1.4.2 client definitely failed against the 2.2.0 server. Maybe something about the faster failover in 2.5.1 changed what is happening? Let me reinstall 2.2.0 and confirm.
Comment by Robert Waite [ 11/Jun/14 ]
Confirmed that 1.4.2 client still fails against 2.2.0 server. When I click failover, instead of immediately seeing the data available on the promoted master... there is the 1-5 minute delay for the failover to actually complete. Then I see exceptions (not getting from replica or master).

However, with the disableCarrierBootstrap property set... after throwing the exception for 2-3 minutes it seems to recover. I am pretty sure it did not recover without that property set but I can validate that as well.

This likely is workable as a fix on my end. Do you know why failover is slow on 2.2.0 but seems to be so fast on 2.5.1?

Thanks again for your quick replies.
Comment by Robert Waite [ 11/Jun/14 ]
Hmm... even without the property set on 1.4.2 client against 2.2.0 server it seems to recover. I am wondering if this is related to queued up requests during the failover delaying or potentially blocking the client refreshing its node list.

For example... I get errors like this sometimes:

2014-06-11 11:48:53.284 WARN com.couchbase.client.CouchbaseConnection: Cancelling operation Cmd: 0 Opaque: 2682 Key: 27d528c1-0716-4f9d-98ef-ccfeaeee1b83because it has been retried (cloned) more than 100times.

I feel like the fullblown app I am testing with does not recover. Perhaps it is because it is more heavily threaded. I will try to work on a new testing app that 1) maybe reduces the timeout so that more failed requests can happen before failover is complete and maybe 2) try multiple threads all making requests against the client.

I am wondering if the problem is exacerbated in 2.2.0 because of the long failover and that perhaps there is a way to create it in 2.5.1. I am also wondering if there are cases that don't recover... because that is what originally made me dig into this.

I'll play with it some more and let you know.
Comment by Robert Waite [ 11/Jun/14 ]
Played with decreasing the timeout from the default of 2.5 seconds to 200 milliseconds. After maybe 3 or 4 runs it would always recover (after 1-3 minutes). I ran the gets with 6 threads and saw many new types of errors and it does not seem to recover (this is all against 2.2.0... I can try 2.5.1 a little later).

When I block traffic to the master node... it starts getting from replica... and then after a little while I see these sorts of errors:

Got From Replica
Got From Replica
2014-06-11 12:50:04.937 WARN com.couchbase.client.CouchbaseConnection: Node expected to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: 15b552fc-382c-410e-b0d4-d9408770089d.
2014-06-11 12:50:04.937 WARN com.couchbase.client.CouchbaseConnection: Node expected to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: 15b552fc-382c-410e-b0d4-d9408770089d.
2014-06-11 12:50:04.937 WARN com.couchbase.client.CouchbaseConnection: Node expected to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: 15b552fc-382c-410e-b0d4-d9408770089d.
Got From Replica
Got From Replica
Got From Replica
2014-06-11 12:50:04.942 WARN com.couchbase.client.CouchbaseConnection: Node expected to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: 15b552fc-382c-410e-b0d4-d9408770089d.
2014-06-11 12:50:04.942 WARN com.couchbase.client.CouchbaseConnection: Node expected to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: 15b552fc-382c-410e-b0d4-d9408770089d.

At this point it is still getting data from replicas... but the warning starts showing up.

Once I kick off the failover, I see the exception start showing up (not able to get from replica or master) and finally some log messages show up about having trouble connecting happens and everything halts. The application is still running but nothing is happening... no errors. I will leave it for the next hour to see if it does somehow recover... but it is odd that timeouts no longer are spewing to the screen.

I will attach the threaded testing app and the log output when everything seems to halt.
Comment by Robert Waite [ 11/Jun/14 ]
Attaching quick timeout and threaded version of testing app. (CouchbaseClientTesterFastAndThreaded.java)
Comment by Robert Waite [ 11/Jun/14 ]
Attaching log file showing what leads up to the client seeming to lock up and no longer function. The last line in there is all that is on the screen but the java process is still alive. (logAfterSeemingFreeze.txt)
Comment by Michael Nitschinger [ 13/Jun/14 ]
Thanks for the detailed infos, I have a few more questions:

- Are you using views? Could be related to http://www.couchbase.com/issues/browse/MB-11146
- Can you do a thread dump after the observed lockup? maybe we can look in there and see whats going on.

Also, when you do a failover and all that stuff, you can check on the server logs and observe the timings where it says it started failover and once its done. Maybe this correlates with the info on the client side, I saw some other tickets (some internal support) where there were also longer failover pauses reported against 2.2 (from the server side). Maybe this helps us triage it further.

Just to clarify, against 2.5.X it seems to work fine and the observed behavior is only agains 2.2.?
Comment by Robert Waite [ 13/Jun/14 ]
We are not using views... just plain key/value pair lookups (although we are letting the client be responsible for serializing the objects... not serializing ourselves and passing strings).

I can do a thread dump.

The long failover pause only happened with 2.2.0... not 2.5.1. My guess was that it was related to MB-8039. Our installation of 2.2.0 is pretty vanilla (512MB per node limit on bucket... 1 level of replication... 2 nodes). I am pretty sure you will see the same behavior with the test code.

2.5.1 seemed to recover very quickly with property file change. My guess was that this was because the failover did not take 1-5 minutes to happen so less operations were outstanding client-side. This was just the test for recovery after failover. The issue where things locked up with the multi-threaded test was completely different... I have not tested the multi-threaded test against 2.5.1 yet.
Comment by Robert Waite [ 13/Jun/14 ]
Attached thread dump output.
Comment by Robert Waite [ 13/Jun/14 ]
Sorry... realized there were some actual hostnames in the threaddump... reattaching. (threadDumpDuringFreeze.txt)
Comment by Robert Waite [ 13/Jun/14 ]
Also attaching from Sun JVM in case there was a question about the other one being run in OpenJDK. (threadDumpDuringFreezeSunJVM.txt)
Comment by Robert Waite [ 13/Jun/14 ]
I switched the server back to 2.5.1 and in a number of tests... it did not seem to get into the frozen behavior in the client. Typically with the single thread test.. when I would click failover in 2.5.1 it would be less than half a second until the client seemed to pick up on the fact that there was a failover. With 2.2.0... it seemed to take 1-3 minutes (sometimes 5 minutes) to realize... but it would indeed failover.

It seems that the property being set had nothing to do with the fix... the only reason I thought it did was because of the issue where my POM was actually pointed to the 1.3.2 client instead of the 1.4.2 client.

So... 2.2.0 seems to have a number of issues with the various tests I have run... 2.5.1 seems resilient. It is possible that the issue is still in there though and is just harder to hit. I think the main reason 2.2.0 sees the issue so much more easily is related to the slow failover. Also... I think a unique feature of this test is that I am using replica gets and not just plain gets. I think at some point I tested commenting out the replica get and did not see the issue (but of course had no availability during that time).
Comment by Robert Waite [ 18/Jun/14 ]
Has anyone had a chance to run this? Even with 2.5.1 server and 1.4.2 client I see some odd behavior. When I cut the connection to the master node and see the replica gets... I will see a new error after maybe 20-40 seconds:

2014-06-18 11:57:28.711 WARN com.couchbase.client.CouchbaseConnection: sun.nio.ch.SelectionKeyImpl@5328f6ee exceeded continuous timeout threshold

Once this happens the data is no longer pulled from the replica and I get exceptions about timing out from any replica. This only happens when fully loaded with the 6 threads. If I back it down to 1 thread it doesn't seem to happen and didn't seem to happen at least a few times with 2 threads.

Might not be as high priority with the 2+ client coming out but I think similar tests should be run against it.
Comment by Robert Waite [ 18/Jun/14 ]
Also... I just recreated the freezing behavior in 2.5.1 server against the 1.4.2 client. I blocked a node with iptables and then just unblocked it without failing over. The client code hung. I have the thread dump but it looks pretty much the same as the others. Let me know if you want that specific dump.
Comment by Robert Waite [ 18/Jun/14 ]
I realize at this point that this ticket has ballooned to too many potential individual issues. It probably should have some subtasks created.

This is with 2.5.1 server against 1.4.2 client.

I created a new test that immediately starts performing gets with 8 threads. I then cut off a node with iptables. After about 20-40 seconds it will throw errors. If I trim it down to 1 thread I only see one error pop occaisionally, but in general it starts getting from the replica. If I bring the node back (without failover) it will start pulling from the master again after 20-60 seconds.

With this case I also added the disableCarrierBootstrap property back in and instead of reading from replicas after cutting the node off, it immediately throws errors. If I bring the node back it seems to stop processing.
Comment by Robert Waite [ 18/Jun/14 ]
Attaching newest test that was run against 2.5.1 server with 1.4.2 client. (anotherMultithreadTest.java)
Comment by Michael Nitschinger [ 23/Jun/14 ]
Thanks for your efforts on this, I tracked down some other issues and maybe this fixes yours as well. I'll look into it soon and report progress, hopefully we can nail that for 1.4.3.




[JCBC-474] Should be able to specify Transcoder to use when querying a view Created: 10/Jun/14  Updated: 16/Jun/14

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

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


 Description   
All of the other methods in the interface support providing a Transcoder on each call and not necessarily relying on the default Transcoder configured in the connection builder. However, there is no way to do this when querying a view. This really only becomes an issue in combination with the "include documents" feature. When you're working with a document that has been Transcoded it will fail when you call getDocument() on the results unless you register a default Transcoder. It would be more consistent if we could pass a Transcoder to the getDocument() call (or configure it for the Query object)... and it would be even nicer if we could benefit from the duck typing logic to get the document as a JSON String if it's been identified by Couchbase as json.




[JCBC-466] Request full dataset when working with development views Created: 06/Jun/14  Updated: 10/Jun/14

Status: Open
Project: Couchbase Java Client
Component/s: Core, Views
Affects Version/s: 1.4.1
Fix Version/s: .next
Security Level: Public

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


 Description   
Currently there is no way to request a full dataset when working with development views from the Java Client, this is solvable by just using the Production view and changing the path as well as appending the needed query parameter, but it would be nice to have the option for development views.

This came up and was requested at the Training in NY after Couchbase Live.




[JCBC-465] Unexpected behaviour on increment / decrement when combining with lock Created: 06/Jun/14  Updated: 10/Jun/14

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

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


 Description   
When issuing an increment or decrement on a locked key (via getAndLock) the result is -1, which is according to documentation that the key hasn't been found. This is confusing when combining with default values. I created a gist for this to illustrate https://gist.github.com/sideshowcoder/8d3ae572bc8e0742ae64

I think a solution would be to add this to the documentation as expected.

This came up in the training in NY.




[JCBC-433] Java SDK Docs: comprehensive best practices example Created: 19/Mar/14  Updated: 02/Jun/14

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

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


 Description   
As a possible improvement to our existing docs, I was thinking that a comprehensive example of Java code showing the various components and strategies that an end-user would need to be aware of and how to handle those within our best practices would be helpful.

It's along the lines of the existing tutorial, but might actually be something separate since it's more about best practices rather than actually developing to Couchbase and can be used as a reference for seeing all those best practices come together.

We certainly have a lot of this existing already, I just haven't been able to see it all in one place to point a customer to.

From a format perspective, I think it would be helpful to have the full set of code on a page with various breakpoints/callouts/even inline comments that explain the various techniques and link further into the documentation for further reading. There can be commented-out sections for "other application logic <here>" as this really just needs to highlight the best practices of working with our Java library.

At least to include:
-Singleton creation and reuse of the client object across multiple threads. with error handling around if the connection can't be established
-Using set to overwrite some data and add() to enforce uniqueness, maybe even incr() and append() examples
-Using async operations with callbacks/listeners
-Using the "AtomicInteger" to track outstanding async operations before shutting down the object
-Proper exception catching and error handling around TMP_OOM, timeouts, failed add(), failed incr/decr, etc, possibly with some exponential back-off or other way of passing feedback up the stack
-Handling of "not found" from the get()
-Bulk gets
-Example of bulk set()s (different than a single async set, if the user knows that there are many items they want to set in bulk)
-Possibly putting some error handling code within the callbacks
-Turning on of our profiling feature
-Object->JSON encoding/decoding as well as handling of writing/reading non-JSON data to CB
-more?

Obviously there's a lot to put in here but I would also think that it doesn't need to be an all-or-nothing but can start with some simple pieces and be built upon. Certainly as we add more functionality or different ways of doing things this doc will have to be extended anyway.




[JCBC-401] Durability .get() with a custom Timeout higher than the default is ignored Created: 14/Jan/14  Updated: 02/Jun/14

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

Type: Bug 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


 Comments   
Comment by Michael Nitschinger [ 02/Jun/14 ]
This is not trivial to fix and there is a workaround by setting a higher default timeout and using then custom timeouts on the async variant. It's not pretty but it works and will be overhauled in 2.0.




[JCBC-404] Views created via with carriage returns are not executable via web admin Created: 23/Jan/14  Updated: 02/Jun/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: Brad Wood 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-11275 Views created over REST API with CRLF... Resolved

 Description   
When looking at a view created via the Java SDK in the web admin, the "Show Results" button is greyed out when the map or reduce function contain a carriage return. The view can be executed via the SDK as well as the REST interface, but the "Show Results" button is disabled.

This was reported in the forums over a year ago:
http://www.couchbase.com/forums/thread/design-docs-views-created-rest-api-dont-work-show-results-grayed-out-404-error-client

I can't find a ticket for it and it doesn't appear to be resolved.

As a work around, I am manually replacing carriage returns (CFML code)
{code}
/**
* Normalize view functions to not have any carridge returns.
* The presence of ASCII code 13 in map or reduce functions will prevent you from
* being able to execute them from the Couchbase web admin.
* @viewFunction.hint The function string to normalize
*/
string function normalizeViewFunction( required string viewFunction ) {
var CR = chr(13);
var LF = chr(10);
var CRLF = CR & LF;
var CRLFPlaceholder = '__CRLF__';

// I'm doing this in two steps since if I just remove CR's that have no LF, that would completely remove line breaks and cause syntax issues
// but if I just replaced all CR's with LF's that would double all line breaks. Therefore, all CR's and CRLF's will be converted to an LF.
// Standalone LF's won't be touched.

// Set CRLF's aside for a moment
arguments.viewFunction = replace(arguments.viewFunction,CRLF,CRLFPlaceholder,'all');
// Replace single CR's with LF's
arguments.viewFunction = replace(arguments.viewFunction,CR,LF,'all');
// Put the CRLF's back as just LF's
arguments.viewFunction = replace(arguments.viewFunction,CRLFPlaceholder,LF,'all');

return arguments.viewFunction;
}
{code}


 Comments   
Comment by Brad Wood [ 23/Jan/14 ]
Ugh, you don't have Wiki markup enabled in JIRA. Please do so, it makes things so much prettier. I can't edit my ticket either to remove the unused "code" markup.
Comment by Michael Nitschinger [ 23/Jan/14 ]
Hi Brad,

do you mean that when you create view through the java SDK which has a CR in its name (design doc, view name?) it can't be used from the web UI, but otherwise works fine?

Either this is not allowed then we should check it or it is a bug on the server side.
Comment by Brad Wood [ 23/Jan/14 ]
No, the carriage returns are not in the name of the view or the design document-- they are in the map or reduce functions.

For instance, I might create a view with the CFML SDK (which proxies to the Java SDK) with the following code:

couchbase.saveView(
'beer',
'listBeersByBrewery',
'function (doc, meta) {
if ( doc.type == ''beer'' ) {
emit(doc.brewery_id, null);
}
}',
'_count'
);

Since I am on Windows, each line ending in the map function is a carriage return followed by a line feed. The view will create and will be executable via the SDK and via the REST interface, but not via the web admin. After I modified the CFML SDK to strip out ASCII code 13 from the map and reduce functions, they work as expected.
Comment by Michael Nitschinger [ 02/Jun/14 ]
While I think we could implement that, it could also be a bug on the server side. Let me open a issue there and the we'll figure it out.
Comment by Michael Nitschinger [ 02/Jun/14 ]
I've passed this on to the UI folks so they can look into. Depending on what comes out in the MB ticket (http://www.couchbase.com/issues/browse/MB-11275) we'll see if there is action needed on the java side.




[JCBC-416] Client throws exception "Cannot cache data larger than 20971520 bytes" when receiving uncompressed document from server Created: 17/Feb/14  Updated: 01/Jun/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: Venu Uppalapati Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Steps to reproduce:
1) generate a 30MB document. compress the document, in my case the compressed size is ~15MB.
2) using a 3.0 client, send this compressed doc with datatype 0x02 to the server. server stores this as is.
3) using a 2.x client, request a GET for this document. The server uncompresses the doc since the request if from 2.x client that is not flex metadata aware and sends the raw doc to client.
4) client throws following exception and connection resets..java.lang.IllegalArgumentException: Cannot cache data larger than 20971520 bytes (you tried to cache a 31211520 byte object)
5) we should release appropriate hot patch or workaround information on how to handle this scenario from 2.x clients.




[JCBC-402] Do you plan to add the java bindings for incr multi ? Created: 15/Jan/14  Updated: 01/Jun/14

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

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


 Description   
I can't find any similar in the Java API to incrMulti() or incrBulk() or asyncIncrBulk() bindings!

We need this feature heavily and I sadly see the other drivers already have it ->

Perl: Multi version of "arithmetic"

incr_multi(@keys)
decr_multi(@keys)
incr_multi( [key, amount], ... )
decr_multi( [key, amount], ... )

JavaScript: Now changed to arithmeticMulti()

http://review.couchbase.org/#/c/30792/


Cheers,

--

​"No trees were destroyed in the sending of this message.
However, a large number of electrons were terribly inconvenienced."

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
This is not planned currently for the 1.* java SDK series, but we may consider it for 2.0. Let's see.




[JCBC-438] Add table for 1.8, 2.x and 3.x compatibility Created: 25/Mar/14  Updated: 01/Jun/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: .future
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

Issue Links:
Gantt: finish-start
has to be done before NCBC-423 Add couchbase cluster compatibility t... Open
has to be done before PYCBC-238 Add couchbase cluster compatibility t... Open
has to be done before RCBC-167 Add couchbase cluster compatibility t... Open
has to be done before CCBC-353 Add couchbase cluster compatibility t... Resolved
has to be done before JSCBC-102 Add couchbase cluster compatibility t... Resolved
has to be done before PCBC-270 Add couchbase cluster compatibility t... Resolved

 Description   
Please specify the info to go into the table and pass this to Amy who will add it to the SDK docs in appropirate formatting.

We should probably specify for this given major.minor of the SDK, one of three things for Couchbase Cluster releases:
- unsupported
- supported
- supports all features

These might be an 'x', '—' and "✓" in a table, or whatever Amy comes up with.

This is, in part, planning for 3.0 including beta.

 Comments   
Comment by Amy Kurtzman [ 01/May/14 ]
What's the difference between "supported" and "supports all features"?
Comment by Michael Nitschinger [ 05/May/14 ]
Amy, it could be that the SDK works against a server version, but does not support all of its features. For example the 1.* SDK will be supported against 3.0 Server, but does not support SSL.




[JCBC-432] Get a null value when the deserialization fails Created: 18/Mar/14  Updated: 01/Jun/14

Status: Open
Project: Couchbase Java Client
Component/s: Dependencies
Affects Version/s: 1.3.2, 1.4.0-dp1
Fix Version/s: .future
Security Level: Public

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


 Description   
CouchbaseClient.getBulk

 Comments   
Comment by syu.hsh [ 18/Mar/14 ]
 key-values returned by CouchbaseClient.getBulk contain null value
caused by net.spy.memcached.transcoders.BaseSerializingTranscoder
protected Object deserialize(byte[] in) {
    Object rv=null;
    ByteArrayInputStream bis = null;
    ObjectInputStream is = null;
    try {
      if(in != null) {
        bis=new ByteArrayInputStream(in);
        is=new ObjectInputStream(bis);
        rv=is.readObject();
        is.close();
        bis.close();
      }
    } catch (IOException e) {
      getLogger().warn("Caught IOException decoding %d bytes of data",
          in == null ? 0 : in.length, e);
    } catch (ClassNotFoundException e) {
      getLogger().warn("Caught CNFE decoding %d bytes of data",
          in == null ? 0 : in.length, e);
    } finally {
      CloseUtil.close(is);
      CloseUtil.close(bis);
    }
    return rv;
  }
Comment by Michael Nitschinger [ 19/Mar/14 ]
can you share an example to reproduce?




[JCBC-455] ClusterManager to have the same functionally as the UI. Created: 30/Apr/14  Updated: 12/May/14

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

Type: Improvement Priority: Critical
Reporter: Patrick Varley Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: cluster, customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 1.4

Issue Links:
Dependency

 Description   
It would be good if the ClusterManager class could do everything that the user could do via the web interface. For example the createNamedBucket() cannot set the number of R/W threads right now.

I guess the one problem with this is what to do when features get add/removed from the cluster? (May a subclass per a cluster version?)




[JCBC-458] Improve logging Created: 08/May/14  Updated: 12/May/14

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

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


 Description   
A few suggestion on making the log files easier to read and grep:

All messages should be pre fixed with the bucket they are related to. This is extremely important when a user has a number of different couchbase buckets connecting to different clusters but all logging to one place.

When the client starts for the 1st time it should log its own version.

What did the state change from and to?
Connection state changed for sun.nio.ch.SelectionKeyImpl@51ec8098

What is Binary config (I assume carrier publication)?
Binary config not available, bootstrapped through HTTP.




[JCBC-229] Find a way to proper test JCBC-227 Created: 01/Feb/13  Updated: 24/Apr/14

Status: In Progress
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.2
Fix Version/s: .future
Security Level: Public

Type: Task 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

 Description   
The issue fixed in jcbc-227 needs proper testing. Can you please add tests for this either as a unit test, or integrate it into sdkd? I'm not sure where it fits - what do you think?

 Comments   
Comment by Deepti Dawar [ 01/Feb/13 ]
Alright, I can add unit/integration test for the same.
Comment by Deepti Dawar [ 11/Feb/13 ]
http://review.couchbase.org/#/c/24520/
Comment by Michael Nitschinger [ 12/Feb/13 ]
Please only close once the change has been merged in, thanks.
Comment by Deepti Dawar [ 14/Feb/13 ]
http://review.couchbase.org/#/c/24520/6
Comment by Deepti Dawar [ 24/Apr/14 ]
http://review.couchbase.org/#/c/24770/




[JCBC-444] add more annotations for what is thrown from methods in CouchbaseClient Created: 27/Mar/14  Updated: 27/Mar/14

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

Type: Improvement Priority: Critical
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   
At the moment, there are a number of un-checked exceptions which may be thrown and aren't well described in the javadoc annotations. It would be good to add these so developers can identify things they may want to handle.




[JCBC-443] javadoc on OperationStatus.success() could be more clear Created: 27/Mar/14  Updated: 27/Mar/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: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The javadoc for OperationStatus.isSuccess() is rather confusing: "Does this status indicate success?"




[JCBC-434] update logging documentation to cover SLF4J, etc. Created: 21/Mar/14  Updated: 21/Mar/14

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

Type: Task Priority: Critical
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   
Current advanced usage section on logging doesn't cover SLF4J. Please add that.




[JCBC-425] document profiling capabilties Created: 04/Mar/14  Updated: 04/Mar/14

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.0, 1.3.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   
The profiling added in 1.2 has not been documented. We should add a section for that. It doesn't even seem to be in the release notes. I found it on Michael's blog, but it should be in the documentation too.




[JCBC-422] add discussion of timeout accuracy and implementation to documentation Created: 27/Feb/14  Updated: 27/Feb/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: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Since our timeouts are only as accurate as the underlying APIs/subsystems we use, we should document this for our users so they can plan accordingly. For instance, if processes aren't scheduled for a long period of time owing to CPU or memory contention... or in some cases IO doesn't happen for a long time and our timeout is IO event driven, we may not timeout to the application until later.





[JCBC-83] replace use of java assert in tests with junit assertions, including messages Created: 12/Jul/12  Updated: 13/Feb/14

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

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


 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2 because its a smaller change.




[JCBC-203] append/prepend are ASYNC, and can specify 0 for casunique Created: 02/Jan/13  Updated: 13/Feb/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: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-append.html


 Description   
This is a two-for-one bug report for the docs. First, the return value of append/prepend is Future<Boolean>, not "Object ( Binary object )". These are async ops, and need to be documented as such.

Next, the append and prepend methods say that the casunique argument must be specified, but don't mention that it is OK to pass 0 here if you just want to append to whatever is there.

In fact, using 0 for casunique is going to be the normal use case for these functions, since memcached (and Couchbase) defines them to be atomic. It's too bad that spymemcached made this interface clunky, but we can at least document this normal use case.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-204] document increment/decrement behavior with non-numeric value Created: 02/Jan/13  Updated: 13/Feb/14

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

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-incr.html


 Description   
Increment and decrement should document what happens if the key exists on the server, but the value is invalid. It should describe what a valid value is (and link to the Developer's Guide page that describes the server-side behavior in greater detail).

Valid value is a string. String is decimal representation of an unsigned 64-bit integer.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-406] create release notes for 1.4.0 release Created: 28/Jan/14  Updated: 28/Jan/14

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

Type: Task 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   
If documentation changes are small or none, plan is to supply Amy the release notes markdown and she'll handle the creation of the new doc set for 1.4.0.

Please attach it here and assign to Amy when complete.




[JCBC-310] Create a getBulk() operation that returns CASValue object Created: 23/May/13  Updated: 13/Jan/14

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

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


 Description   
The current client.getBulk(keys) returns the values only,

It would be useful to create an operation that returns the list of CASValue to allow developer to do CAS operations.

This should also be supported by the views when doing a "includeDocs" operation

 Comments   
Comment by Mladen Markov [ 31/Oct/13 ]
I also need this badly, for performance reasons.

Right now I'm looping through hundreds of documents per second, getting their CAS value one by one. I'm looking to do more bulk operations to save excessive round-trips to Couchbase. I see that net.spy.memcached.MemcachedClient does not have getsBulk() or asyncGetsBulk() methods, although the memcached protocol supports it.

So I'm not sure if this should be a feature request to Java Memcached Client or to Couchbase Java Client.
In any case, I would very much like to up-vote it.

Cheers
Mladen
Comment by mshaw [ 06/Jan/14 ]
I'm surprised that this is a minor issue. Same problem as Mladen, we require excessive round trips since this is the only way to ensure proper updates on bulk docs.
Comment by Michael Nitschinger [ 07/Jan/14 ]
Hi folks,

a bulk operation is nothing more than syntactic sugar on top of the regular get api, so looping does not get you more roundtrips or whatever. Can you give me a specific use case where you think bulking will help you to improve performance?

Also, mshaw, why do you think you'll have more network roundtrips because of looping?
Comment by Perry Krug [ 07/Jan/14 ]
Heard this request from another customer.

I agree that returning the CASvalue through a getBulk is a bit of syntactic sugar, but it's not intuitive to the user that they should have to do the async gets themselves and it should be easy enough to build that into getBulk right?

This also applies to include_docs via a view request where the user is actually forced to do a second round of gets (or again, implement it themselves manually)
Comment by mshaw [ 07/Jan/14 ]
Michael, I should have been more clear. It may be that it really is just a convenient API, but I was under the impression that the SDK is actually optimized for the bulk operations when compared to looping yourself.

By excessive I'm thinking of a scenario where we use a getBulk() which has no cas values. We then need to update some of those items so we need to get the updatable items again with the gets(), then apply the updates and save using the cas since there can be multiple writes to the file. We are using getBulk() because the Couchbase docs recommendation state it is more efficient than looping the calls. It seems that the only option around the above work around is to loop gets calls for all our items that may need updating, causing are calls at the very least to be inefficient according to Couchbase docs.
Comment by Matt Ingenthron [ 07/Jan/14 ]
One quick comment from a historical sense... I believe the getBulk() and thus it's API has been around longer than the CAS value has. This is legacy from spymemcached and the memcached protocol.

On the note about doing a loop versus a getBulk(), with the current code if you do a series of async gets(), it's going to be exactly the same as getBulk(). The internals of getBulk() perform the same logic. In fact, it's arguably faster if you're using the Futures directly, since you don't have to wait until they all arrive, You just block when the data is needed.

We should address that in the documentation.
Comment by mshaw [ 07/Jan/14 ]
Ok interesting thanks for that added info. I have seen getBulk() mentioned in webinars as the recommended way to get multiple records as well.
Comment by Matt Ingenthron [ 07/Jan/14 ]
For many clients, that will be the most efficient route which is why they say that in general introductions. Mostly it's described along with views, where you'll have a query and then multi-get the underlying docs. Java is a bit more advanced of a client with it's asynch capabilities, so it is a little different in this regard.
Comment by Mladen Markov [ 13/Jan/14 ]
Guys, correct me if I'm wrong but the memcached protocol supports bulk gets - getting CAS values for multiple keys with one call.
See the "gets <key>*" command at https://github.com/memcached/memcached/blob/master/doc/protocol.txt

Is one "gets 1000 keys" call not going to be way faster than 1000 (async) "get 1 key" calls?
Comment by Perry Krug [ 13/Jan/14 ]
Mladen, that part of the protocol only applies to asking for 1000 keys from the same node. In Couchbase-land, it's very likely that that set of 1000 keys actually comes from multiple nodes, in which case you need to make separate calls (at least one for each server). The Java client automatically does this for you and is just as fast as the single "get 1000 keys" call.




[JCBC-273] Unknown Host Exception should be caught Created: 15/Mar/13  Updated: 19/Dec/13

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

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


 Description   
Encountered these errors while running on Jenkins. These need to be handled.

Stack Trace :

  [junit] Testcase: testMessageReceived took 0.173 sec
    [junit] Testsuite: com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest
    [junit] 2013-03-15 04:07:54.268 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogus:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogus
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
    [junit] 2013-03-15 04:07:54.724 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogustoo:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogustoo
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.991 sec
    [junit] ------------- Standard Error -----------------
    [junit] 2013-03-15 04:07:54.268 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogus:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogus
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
    [junit] 2013-03-15 04:07:54.724 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogustoo:8091/pools ...skipping
    [junit] java.net.UnknownHostException: bogustoo
    [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175)
    [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
    [junit] at java.net.Socket.connect(Socket.java:546)
    [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409)
    [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530)
    [junit] at sun.net.www.http.HttpClient.&lt;init&gt;(HttpClient.java:240)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321)
    [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801)
    [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
    [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] at java.lang.reflect.Method.invoke(Method.java:616)
    [junit] at junit.framework.TestCase.runTest(TestCase.java:168)
    [junit] at junit.framework.TestCase.runBare(TestCase.java:134)
    [junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
    [junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
    [junit] at junit.framework.TestResult.run(TestResult.java:113)
    [junit] at junit.framework.TestCase.run(TestCase.java:124)
    [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
    [junit] at junit.framework.TestSuite.run(TestSuite.java:227)
    [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
    [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
    [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)

 Comments   
Comment by Michael Nitschinger [ 15/Mar/13 ]
Why should it be caught? The UnknownHostException is semantically 100% spot on.
Comment by Deepti Dawar [ 15/Mar/13 ]
If it is not caught, it should be handled in the junit test such that the junit test should expect that exception otherwise the test fails.
Comment by Michael Nitschinger [ 19/Jul/13 ]
Has this been resolved with recent changes to the tests?
Comment by Deepti Dawar [ 22/Jul/13 ]
No, this still exists.
Comment by Deepti Dawar [ 03/Sep/13 ]
I have tried to catch the UnknownHostException at very many places, but that does not seem to resolve the problem.
Even tried debugging the same, but seems like there is a logging level issue. Michael, can you please let me know where do we set the logging level and related properties ?
Comment by Michael Nitschinger [ 19/Dec/13 ]
Any progress on this? Still don't know what we need to fix here :)




[JCBC-113] code injection during development/debug causing IllegalStateException Created: 13/Sep/12  Updated: 19/Dec/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp, 1.1dp2, 1.1.0
Fix Version/s: .future
Security Level: Public

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


 Description   
Caused by: java.lang.IllegalStateException: Shutting down
at net.spy.memcached.MemcachedConnection.checkState(MemcachedConnection.java:824) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:640) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:841) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1003) ~[spymemcached-2.8.4.jar:2.8.4]
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1024) ~[spymemcached-2.8.4.jar:2.8.4]

It happens everytime I change the code in debug mode (JVM code injection)

From thread: http://www.couchbase.com/forums/thread/java-client-issue-after-code-injection

 Comments   
Comment by Michael Nitschinger [ 16/Nov/12 ]
Asked "cb" on the forums for more information to be able to reproduce the issue.
Comment by cb [ 23/Dec/12 ]
I tested on v1.1 and there are still issues:

Caused by: java.lang.IllegalStateException: Shutting down
at net.spy.memcached.MemcachedConnection.checkState(MemcachedConnection.java:825) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:641) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedClient.asyncGetAndTouch(MemcachedClient.java:1284) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedClient.getAndTouch(MemcachedClient.java:955) ~[spymemcached-2.8.9.jar:2.8.9]
at net.spy.memcached.MemcachedClient.getAndTouch(MemcachedClient.java:978) ~[spymemcached-2.8.9.jar:2.8.9]
at models.AdminUserSession.findByKey(AdminUserSession.java:35) ~[classes/:na]
Comment by Michael Nitschinger [ 24/Dec/12 ]
Hi cb,

thanks for responding. Would it be possible to help me out reproducing it? What kind of setup are you using? (OS, IDE, App Server) and so on? I never encountered this in my environments here... thanks very much!
Comment by cb [ 24/Dec/12 ]
Play Framewok 1.0.4
Couchbase 2 GA
Java Client 1.1

You can use the example app that you created in your Blog Post. (BTW - Still looking forward for the rest of the parts of this super good post!!)
Change something in the code - while running in sbt like this:

~run (note the "~") which tells sbt to inject any change into the running process.

Let me know if you can reproduce the bug.

Comment by Michael Nitschinger [ 24/Dec/12 ]
You mean 2.0.4?

Are you running on 1.6 or 1.7 java? Or which scala version? On which operating system are you running it?

Never came across this (neither while working on the blog posts nor working on it from other apps).

Comment by cb [ 24/Dec/12 ]
sorry 2.0.4

Jave Version:

Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

OSX 10.8.2
Comment by Michael Nitschinger [ 19/Jul/13 ]
Hey, are you still facing this issue? We've never seen it coming up somewhere else!
Comment by Michael Nitschinger [ 19/Dec/13 ]
cb, are you still running into this? If so, we should track that down finally.




[JCBC-377] Getting sdk error - 'Connection reconfiguration failed' while running situational tests Created: 11/Nov/13  Updated: 11/Nov/13

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

Type: Bug Priority: Major
Reporter: Deepti Dawar Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: ec2 centos machines


 Description   
Following is the exception in the situational test logs shared at - https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdGRQUllQSWVpV0Q3WGwxOERsOFcwMnc&usp=sharing#gid=0

SEVERE: Connection reconfiguration failed
SDKD: java.nio.channels.ClosedByInterruptException
SDKD: at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
SDKD: at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:634)
SDKD: at net.spy.memcached.MemcachedConnection.createConnections(MemcachedConnection.java:225)
SDKD: at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:131)
SDKD: at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:283)
SDKD: at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54)
SDKD: at java.util.Observable.notifyObservers(Observable.java:159)
SDKD: at com.couchbase.client.vbucket.BucketMonitor.replaceConfig(BucketMonitor.java:310)
SDKD: at com.couchbase.client.vbucket.BucketUpdateResponseHandler.messageReceived(BucketUpdateResponseHandler.java:81)
SDKD: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
SDKD: at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:202)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
SDKD: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
SDKD: at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:455)
SDKD: at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:538)
SDKD: at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:487)
SDKD: at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
SDKD: at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
SDKD: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
SDKD: at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
SDKD: at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:94)
SDKD: at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:390)
SDKD: at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:261)
SDKD: at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
SDKD: at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
SDKD: at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
SDKD: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
SDKD: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
SDKD: at java.lang.Thread.run(Thread.java:722)




[JCBC-357] Bulk touch function to batch multiple updates Created: 29/Aug/13  Updated: 06/Sep/13

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

Type: New Feature Priority: Minor
Reporter: David Haikney Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
A customer has requested a function to batch multiple touches into one network call similar to the "multitouch" call of the php SDK.




[JCBC-258] documentation needs to be much clearer about Query.setKey() requiring JSON encoded strings or use of ComplexKey Created: 06/Mar/13  Updated: 06/Sep/13

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

Type: Improvement Priority: Critical
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   
Neither the javadoc nor the existing documentation really cover the potential issues with setKey using a number or something that will autobox into a string value. This should be much clearer.




[JCBC-269] subsequent resubscribers should not run if a resubscriber is successful Created: 13/Mar/13  Updated: 06/Sep/13

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

Type: Bug Priority: Critical
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   
When investigating a case recently, I noticed many resubscribers running once a second. Looking at the code, it appears the kind of threadpool being used would just queue more and more up, but only run one at a time.

The subsequent resubscribers should exit immediately if resubscribe is no longer needed. Or the threadpool could be changed so we can't queue another while one is running.




[JCBC-341] TapClient should tap only vbuckets on nodes to avoid duplicate network traffic. Created: 06/Aug/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
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

Issue Links:
Relates to
relates to JCBC-340 Tap client should only connect to act... Closed




[JCBC-342] TAP Client streams should be reconfigure-aware (reestablish streams) Created: 06/Aug/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: .future
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

Issue Links:
Relates to
relates to JCBC-340 Tap client should only connect to act... Closed




[JCBC-290] Support for publishing view from dev to prod Created: 22/Apr/13  Updated: 06/Sep/13

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

Type: Task Priority: Major
Reporter: Perry Krug 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 [ 22/Apr/13 ]
"publishing" isn't a real action, it's just moving the same design document in under a different name. This should definitely be done, but as documentation about how to go from development to published.




[JCBC-316] noop on connect optional behavior needs to be documented Created: 10/Jun/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.7
Fix Version/s: .future
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   
One thing which needs to be better documented is how to enable the NOOP check on connect.

This should be done before 1.1.8, since it's part of the 1.1.7 ship.




[JCBC-283] Document how best to use expiry with times >30 days Created: 12/Apr/13  Updated: 06/Sep/13

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

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


 Description   
Really needed across all languages...do you want me to file separate issues?

We have some documentation on how to use expiration with relative values, but nothing clearly showing how we recommend calculating a timestamp and sending it to the operation.




[JCBC-301] Strange Logic in CouchbaseClient observePoll method Created: 09/May/13  Updated: 06/Sep/13

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

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


 Description   
At CouchbaseClient.java line 2192 and line 2196

They both call

replicaPersistedTo++;

it means when r.getValue() == ObserveResponse.NOT_FOUND_PERSISTED) && !isMaster, replicaPersistedTo will be called twice.

Is that intensional. Looks odd to me.

 Comments   
Comment by Henri Chen [ 09/May/13 ]
BTW, The code is based on Github master.




[JCBC-281] Document working with the cluster manager in java manual Created: 08/Apr/13  Updated: 06/Sep/13

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

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


 Description   
http://www.couchbase.com/autodocs/couchbase-java-client-1.1.5/com/couchbase/client/ClusterManager.html

This is in the Java docs, but not yet in the manual.




[JCBC-289] Document manipulation of the designdoc/view interface Created: 22/Apr/13  Updated: 06/Sep/13

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

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


 Description   
The library already supports programmatic creation of design docs and views, need to supply documentation around it.




[JCBC-28] refactor the entire cluster stream connection Created: 03/Apr/12  Updated: 06/Sep/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
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   
Because of the codebase's legacy, the handling of the Bucket and Configuration is rather odd. It used to exist outside the client to serve a different purpose. At that time, not changing the client internals was desirable.

Fast forwarding to now, the internals should be updated to have the NodeLocator or the connection abstract away much of the configuration details.




[JCBC-328] create tuneable for compressing JSON Created: 08/Jul/13  Updated: 06/Sep/13

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

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


 Description   
Currently, the compression of JSON or not is all the way down in spymemcached and hardcoded. This was probably intended to be tuneable and should be fixed up. For right now, if someone wants to compress their JSON, they have to implement an entire transcoder.

https://gist.github.com/ingenthr/5952891




[JCBC-296] Document changing compression threshold Created: 06/May/13  Updated: 06/Sep/13

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

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


 Description   

Please see the feature request below.

http://www.couchbase.com/forums/thread/java-client-compression-threshold




[JCBC-208] HTTP flush needs to be async Created: 09/Jan/13  Updated: 06/Sep/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0
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   
Since flush can take a long time, it should be possible to handle this async.

 Comments   
Comment by Michael Nitschinger [ 09/Jan/13 ]
See also http://www.couchbase.com/forums/thread/java-sdk-1-1-asynchronous-implementation-operation-requests




[JCBC-239] Docs: Document "paginator" Created: 06/Feb/13  Updated: 06/Sep/13

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

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


 Description   
Docs still point to library version 1.1...will that be updated?

I see reference to a paginator (http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-rn_1-1-0c.html) but can't find any further documentation on how to use it

 Comments   
Comment by Michael Nitschinger [ 06/Feb/13 ]
Library version is 1.1.2?

Docs for the paginator will be added soon!




[JCBC-201] All async ops should link to the Asynchronous Operations page Created: 02/Jan/13  Updated: 06/Sep/13

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: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-add.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-async.html

Etc., there are a bunch of these.


 Description   
There are a lot of async operations. They return *Future<*>. They should all have a link back to the overview of how Asynchronous Operations work, at http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-summary-asynchronous.html

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-199] constructor documented as client method returning "(none)" Created: 02/Jan/13  Updated: 06/Sep/13

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

Type: Bug Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-connection.html


 Description   
The constructor is documented to return "(none)", which isn't really correct.

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-connection.html

Also, the docs make it look like it's a method call on an existing client object ("client.new"), which isn't accurate:

"client.new CouchbaseClient([ url ] [, urls ] [, username ] [, password ])"



 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-183] Many methods in api reference don't link to corresponding documentation page Created: 14/Dec/12  Updated: 06/Sep/13

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

Type: Bug Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0.5h
Time Spent: Not Specified
Original Estimate: 0.5h
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html


 Description   
Many of the links in the api-reference-summary.html don't go anywhere. They should all link to the detail page for the particular method.

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html

It *may* be just the ones with durability requirements (persistto, replicateto) in the signature.




[JCBC-237] Docs: Document how to use observe properly outside of the "wrapped" methods Created: 05/Feb/13  Updated: 06/Sep/13

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

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


 Description   
There will be some cases where a user wants to use the observe functionality outside of the set()/add()/replace() methods what we have allowed for them to specify the "durabililty requirements".

Specifcally this may come up when using incr/decr/prepend/append and wanting to "observe" on that...or just using observe manually to control the behavior, retry, timeouts, etc.






[JCBC-114] Command Futures never receive results after rebalance-out (or other sorts of topology/network changes) Created: 17/Sep/12  Updated: 06/Sep/13

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

Type: Bug Priority: Major
Reporter: Mark Nunberg 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 JCBC-117 mention that OperationFuture.get(tmo)... Reopened

 Comments   
Comment by Mark Nunberg [ 03/Oct/12 ]
This is a real blocker, and seems to be related to a few vbuckets. This issue is preventing me from properly measuring command durations
Comment by Farshid Ghods (Inactive) [ 03/Oct/12 ]
Matt/Rags,

This issue is a blocker for executing more integration tests on java sdk. are there workarounds to avoid this use case or a fix on the way ?
Please assign this back to Mark if more information or logs needed for this issue
Comment by Matt Ingenthron [ 04/Oct/12 ]
Please have a look at this.
Comment by Mark Nunberg [ 05/Oct/12 ]
Michael,

I would not try this test manually.. the use case in more detail is as follows:

- Single CouchbaseClient object
- 20 user threads. 10 setting and 10 getting the same sorts of kv
- Operations are done asynchronously. They are submitted into a queue which is then checked periodically for isDone/isCancelled.
- 4 node cluster. Nodes are removed, connections are broken

The issue is those polling methods never returning true, unless they are retrieved synchronously (i.e. ft.get()).. which is actually an accidental detail
Comment by Matt Ingenthron [ 24/Oct/12 ]
We looked at this pretty closely today. The issue here is that the client as designed relies on the get() from the caller to trigger the timeout. An operation will, somewhat correctly, never transition to isDone() or isCancelled() unless someone cares to use it.

The scenario that was likely in play over the WAN here is that the request was in flight to the server while the config was in flight down to the client. It arrives at the server, but is never responded to. Since the get() is never called, it'll never time out and transition to the canceled state.

We recommend you change the test code to use the queue more like a queue and just get() each one. Iterating through the queue is a bit funny in the first place, but if using the get() on the Future objects, you'll still have asynchronous behavior and much of the time the get() will be returning since the data is already there.
Comment by Matt Ingenthron [ 24/Oct/12 ]
This behavior should be better documented, both in the javadoc and in the API reference.




[JCBC-15] add showtype-options to documentation Created: 23/Feb/12  Updated: 06/Sep/13

Status: Reopened
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: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Many of the Java docs should show the type in the options summary.

 Comments   
Comment by Michael Nitschinger [ 15/Nov/12 ]
Can you give me a quick example on what you mean? Reassign it back to me then and I'll fix it!
Comment by Matt Ingenthron [ 15/Nov/12 ]
If you look at the docs, there are many places where we have types that are returned, but we don't sufficiently describe those types. For example:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-add.html#table-couchbase-sdk_java_add

It mentions the OperationFuture, but nowhere really tell how to use it (to my knowledge).

You should be able to work with MC on the right way to fix these.




[JCBC-206] Need clear info and examples on proper error handling Created: 02/Jan/13  Updated: 06/Sep/13

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

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/getting-started.html

Issue Links:
Duplicate
is duplicated by JCBC-236 Error handling documentation Resolved

 Description   
It's very difficult for people to understand the error handling behavior of the client library, and how to properly handle errors. The async methods make it even more difficult. Information is spread across multiple sections, hidden in individual method descriptions, or else not mentioned at all. The docs should provide a clear description of how to use the API correctly, including example code that does correct error handling that can be cut-and-pasted.

There is a brief mention of error handling here, but it's hidden and very cursory, with no example code:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/create-update-docs.html

This doc mentions that .get() returns null on failure, but gives no hints on how to determine why, or what the right way to recover is:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/read-docs.html

This gives a very cursory mention of failure, but no way to get further details:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/delete-docs.html

No mention of JSON encoding errors or what to expect:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/json-handling-docs.html

Mentions that OperationFuture may return false even if operation succeeds due to durability requirement failure, but no clear example of how to tell the difference, what status codes to expect in each case, etc.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/advanced-persistence.html

Mentions that synchronous call may return an exception, but no info on what the exception would be, or in what circumstances it may return null with no exception:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-summary-synchronous.html

No mention of .isSuccess() method, or any info on how errors are reported via *Future objects. Also no mention of when the async method may fail immediately vs. when the failure will be reported only after checking .isSuccess() or another method on the future. No mention of what errors are reported as exceptions vs. what errors are reported only via the future object's methods.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-summary-asynchronous.html

No mention of when the constructor might fail or what exceptions might be thrown:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-connection.html

No mention of how to tell if the FALSE result is due to timeout, impossible persistence requirements, or other problem:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-observe.html

Not clear enough that .add(), .set(), .replace() are an async methods, too easy for new user to misunderstand how to use them:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-add.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-set.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-replace.html

No mention that .get() may throw an exception, or how errors other than NotFound may be reported:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get.html

Yay, here is an example that has a bit of error handling! Unfortunately, it is a "catch(Exception)" (i.e., very generic, and not intended to catch Couchbase-specific errors or timeouts), and no indication of how to handle actual Couchbase errors. Also gives false impression that get() will throw an exception on all failure, when in fact you need to check for failure with .isSuccess() or something.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-async.html

Also on that page (async get), mentions that a TimeoutException may be thrown. But that won't happen on asyncGet() call, instead it will be when checking .get() on the Future result. I think. It is welcome to list exceptions that can be thrown, but I think this one is incorrect.
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-async.html

.getBulk() and .asyncGetBulk() are complicated enough that they deserve their own example of proper error handling, and what happens when one server node is down and other nodes are up, so partial results are available, etc.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-bulk.html

Nice that these pages mention what exceptions can be thrown, so I can infer how to tell a timeout from a not found, etc. But why only here? Shouldn't these exceptions be more generally described elsewhere as applying to all operations (RuntimeException, InterruptedException, OperationTimeoutException)?:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-get-and-lock.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-unlock.html

Append and Prepend should normally use 0 for the casunique, and then I would not expect an EXISTS error. The example code is clunky, less efficient (suggests doing a .gets() call just to get the cas id), and likely to fail much more often. The example code does not do proper retry handling on an EXISTS error. It does not show how to distinguish an EXISTS, NOTFOUND, or server down error.:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-append.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-prepend.html

View queries might time out, on all or some servers. Should document how the client should handle errors from view queries. Also, if client requests a view that doesn't exist, how is that handled:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-view.html



There is no mention of error handling in the "Using the APIs" nor "Java Troubleshooting" sections, either:

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-started.html
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-troubleshooting.html

There is a brief mention of RuntimeException being "returned" (should say "thrown") in the section on handling timeouts, but this is too buried and too specific to be of real use. And there is no example code:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-troubleshooting.html

Also, the tutorial doesn't do error handling at all, for example:

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/managing-beers.html

Look for "client.set" and "client.query" on that page and you'll see it ignores error handling entirely. I think this is a mistake in tutorial code, it should be complete and correct, or at least it should provide a warning saying that there is no error handling, with a link to the docs that describe how to do proper error handling.



 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moving to 1.1.2, depending on the size of the change maybe will be 1.1.3 or in between.




[JCBC-291] Authentication failed on 5-th client Created: 17/Apr/13  Updated: 06/Sep/13

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: Andrew Kulikov Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Debian GNU/Linux 6.0 (amd64), Couchbase community edition.


 Description   
Let's assume I have:
- a cluster made of 4 couchbase nodes (couchbase1-couchbase4);
- 10 instances of client application (client1-client10).

In my client Java application I connect to the cluster using login, password and the following server list string:

{code}
"http://couchbase1:8091/pools,http://couchbase2:8091/pools,http://couchbase3:8091/pools,http://couchbase4:8091/pools"
{code}

When I start four instances of client application on client1-client4 -- everything is going OK. But when I am trying to start 5-th instance of client application on client5 -- I get the following error:

{code}
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.564 INFO com.couchbase.client.CouchbaseConnection: Reconnecting {QA sa=couchbase1/192.168.0.129:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL steps operation, toWrite=0, interested=0}
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.565 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@28a3001c
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.565 WARN net.spy.memcached.auth.AuthThreadMonitor: Incomplete authentication interrupted for node {QA sa=couchbase1/192.168.0.129:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL steps operation, toWrite=0, interested=8}
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.565 WARN net.spy.memcached.auth.AuthThread: Authentication failed to couchbase1/192.168.0.129:11210
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.566 INFO com.couchbase.client.CouchbaseConnection: Reconnecting due to exception on {QA sa=couchbase1/192.168.0.129:11210, #Rops=1, #Wops=0, #iq=0, topRop=SASL auth operation, topWop=null, toWrite=0, interested=1}
Mar 29 12:56:28 client1: at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:453)
Mar 29 12:56:28 client1: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:381)
Mar 29 12:56:28 client1: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:243)
Mar 29 12:56:28 client1: at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:229)
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.566 WARN com.couchbase.client.CouchbaseConnection: Closing, and reopening {QA sa=couchbase1/192.168.0.129:11210, #Rops=1, #Wops=0, #iq=0, topRop=SASL auth operation, topWop=null, toWrite=0, interested=1}, attempt 0.
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.566 WARN net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl: Discarding partially completed op: SASL auth operation
Mar 29 12:56:28 client1: 2013-03-29 12:56:28.666 WARN net.spy.memcached.auth.AuthThread: Authentication failed to couchbase1/192.168.0.129:11210
{code}

So, if I shutdown one of client1-client4 -- this moment client5 connects to the cluster without problems.

PS: No matter if I make cluster from 2 nodes. The behaveour is the same -- 5-th node get the same error.

 Comments   
Comment by Andrew Kulikov [ 20/May/13 ]
We have solved our problem! The reason was in limit for number of opened files. Have you ever tested couchbase with pam_limits enabled? If so, default configuration (nofile=1024) is suitable only for 3 clients simultaneously connected. 4-th client fails. We have greatly increased nofile parameter for couchbase user in limits.conf -- and the problem was solved.

I think you should add this issue in your documentation. Also, you should write an error in logfile -- if this limit (for open files or any other) is reached.
Comment by Michael Nitschinger [ 20/May/13 ]
Thanks for reporting your findings! I'll change it to a docs enhancement!




[JCBC-117] mention that OperationFuture.get(tmo) changes state when timeout has been reached Created: 24/Sep/12  Updated: 06/Sep/13

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

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

Issue Links:
Dependency
blocks JCBC-114 Command Futures never receive results... Reopened

 Description   
get(tmo) should not change the underlying state of the command to being timed out. It should simply respond with a TimeoutException but allow the command to continue.

Specifically, when the arg-tmo (timeout passed as an argument) expires, the underlying command is marked as timed out. For example, if one waits for 50ms on the command and a response has not been received within that time, the command is now dead ('TIMEDOUT', or similar) and waiting again will not help.

It is understandable that some code might rely on the old behavior, so at the very least, this should be documented in 'BIG RED LETTERS' in the get(tmo) method.

 Comments   
Comment by Matt Ingenthron [ 05/Oct/12 ]
Please explain further.
Comment by Michael Nitschinger [ 16/Oct/12 ]
Hey Mark,

Can you explain in more detail what you want to see changed? When the argument is timed-out what should happen then with it?

Thanks,
Michael
Comment by Matt Ingenthron [ 24/Oct/12 ]
As currently designed, the client uses get() to determine timeout. This is not going to change at the moment. There's no other appropriate place internal to the client to check for this timeout of the operation at the moment.
Comment by Mark Nunberg [ 24/Oct/12 ]
Moving this as a documentation bug
Comment by Matt Ingenthron [ 06/Nov/12 ]
Michael, I'd like you to give this one a shot as your first docs bug, I'll help you with this as needed.




[JCBC-184] API reference should show return types Created: 14/Dec/12  Updated: 06/Sep/13

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

Type: Improvement Priority: Major
Reporter: Tim Smith (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 8h
Time Spent: Not Specified
Original Estimate: 8h
Environment: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/api-reference-summary.html


 Description   
The return type is critical for understanding how to use a function. In particular with the Java client library, it's critical to know if a function returns a Future (i.e., it's an async function) or not. Otherwise it's impossible to use it correctly.

Currently one must click through, scroll around, and pick out the return value somewhere in a list of parameters on the details page. It would be worth the extra screen real estate on the api reference page to show the return value as well.






[JCBC-287] Failover + Readd of Streaming Node against 1.8.1 fails Created: 18/Apr/13  Updated: 06/Sep/13

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

Type: Task 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
Environment: Any Couchbase SDK against a 1.8 cluster


 Comments   
Comment by Michael Nitschinger [ 19/Apr/13 ]
Let me describe the observed behaviour in greater detail to clarify what is the issue.
I just verified against 2.0 that it's the same behaviour, but I don't know why wie didn't observe it there this way.

When someone clicks failover in the UI on the streaming node, our streaming connection gets closed. Now the client code is implemented that way that it gets back to the node list passed in and iterates over it. In the case observed it is the first node in the list which we failed over, but since it has not been removed yet the client is able to connect (and even retrieve the bucket information!).

Now comes the part that I don't understand fully. With the changeset not applied, it connects to the streaming connection from the failovered node but somehow it doesnt get the information fast enough when the same node (!) gets added back. Maybe because when the node gets rebalanced out the streaming connection gets closed again and we lag little bit behind to connect to the second node in the list.

That said, WITH the changeset applied we will not connect to the failovered node immediately because we recognize its in the cluster, but not part of the node list (which kinda sucks from a logical perspective in my opinion, because why do we close the streaming connection on failover AND allow to reestablish it afterwards?). So what will happen is that the SDK immediately connects to the second one and will observe the upcoming operations (rebalance out, rebalance in) correctly.

Does this make more sense now?
Comment by Matt Ingenthron [ 19/Apr/13 ]
Not 100%, no. Do we have a log that shows responses from nodes by chance?
Comment by Michael Nitschinger [ 19/Apr/13 ]
You mean the JSON responses from the nodes? Or the netty logs on the SDK side.
Comment by Michael Nitschinger [ 19/Apr/13 ]
So if you set "failover" on one of the nodes, all HTTP Rest resources are still 100% accessible, even if the streaming connection was closed from the server before. We can even establish it again.

The main diff is that the node shows up in pools, but not in the bucket node list. It also shows a "failovered" state, so we could also try to identify it at that point.

{
systemStats: {
cpu_utilization_rate: 1,
swap_total: 1069543424,
swap_used: 0
},
interestingStats: { },
uptime: "226",
memoryTotal: 1572306944,
memoryFree: 761069568,
mcdMemoryReserved: 1199,
mcdMemoryAllocated: 1199,
couchApiBase: "http://192.168.56.101:8092/",
clusterMembership: "inactiveFailed",
status: "healthy",
thisNode: true,
hostname: "192.168.56.101:8091",
clusterCompatibility: 131072,
version: "2.0.1-170-rel-enterprise",
os: "x86_64-unknown-linux-gnu",
ports: {
proxy: 11211,
direct: 11210
}
},

(this is pools) .. its not in the node list from the bucket info (see the clusterMembership part).

I can get you SDK debug logs as well, but they are already in the CBSE from mark.




[JCBC-356] NPE when sending null transcoder Created: 27/Aug/13  Updated: 06/Sep/13

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

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