Couchbase

[JCBC-65] Client constructor blocks or deadlocks

Wed, 17 Apr 2013 12:28:58 -0500

I am evaluating the couchbase product and hit a brick wall immediately when running through the simple hello world example.

I have a 3 node cluster running couchbase enterprise 1.8.2 on ubuntu 10.04 64 bit VMware images. All three are running in VMWare player instances on Windows 7 64bit.

When I try to run the Main example on Windows 7 using Java6 (64 bit) the code blocks somewhere in the Client constructor. The result is the logging below.

2012-06-14 14:07:46.313 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.150:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-06-14 14:07:46.316 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.151:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-06-14 14:07:46.319 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.152:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-06-14 14:07:59.843 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@24a4e2e3
2012-06-14 14:08:52.983 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@21ec6696
2012-06-14 14:08:52.987 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@27431340

I have also tried debugging but the code blocks in the constructor at

client = new CouchbaseClient(uris, "default", "");

The program never completes.

This works fine in a Linux environment with the following output received

2012-06-14 04:58:50.693 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.150:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-06-14 04:58:50.703 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.151:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-06-14 04:58:50.708 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.152:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-06-14 04:58:50.830 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1bc74f37
2012-06-14 04:58:50.834 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3a21b220
2012-06-14 04:58:50.843 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@732b3d53
2012-06-14 04:58:51.135 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client
Set Succeeded
Synchronous Get failed
Asynchronous Get Succeeded: Hello World!

Is there a JDK for windows 7 or a configuration setting that can be used to prevent this?

[JCBC-276] Client does not detect silently dying Streaming Node

Mon, 20 May 2013 14:30:42 -0500

When connected to the EPT/streaming node and the node is "frozen" or dies silently otherwise (doesn't force the closing of the chunked socket), the connection stays established.

This can easily be reproduced outside of the client by connecting the browser to the streaming URL and then freezing a VM. The browser will still "spin" and wait for new chunks to come up.

The proposed solution is to have a netty handler in place that raises a exception when there is not traffic for N number of seconds (like 30) over the streaming connection. After this is detected, we have two possibilities:

- reconnect completely, but this involves lots of overhead every 30 seconds.
- send a HTTP HEAD packet and only if this doesnt work out reconnect. This means in the normal case we only have a HTTP HEAD request sent every 30 seconds, not much overhead.
If this fails, we then trigger the reconfigure.

Netty has a ReadTimeoutHandler to help with this. My POC already kinda works, I just need to find a way to properly distinguish the HEAD response on the ResponseHandler from regular chunks that arrive from the same channel.

[JCBC-270] client does not handle failure of EPT node with memcached bucket

Mon, 20 May 2013 14:30:43 -0500

When investigating a case, it seems that the dropped configuration when using a memcached bucket is never reestablished. I'm not sure if this is because we rely on timeouts (which we won't get in this case) or something else.

Steps to reproduce:
1. Set up three node cluster
2. Run a constant workload, starting off of one of the nodes (192.168.1.200 in my config)
3. Remove that node from the cluster

Observed behavior:
The client sees the config dropped, but doesn't reconfigure.

Expected behavior:
Client bootstraps off of one of the other nodes.

Attached file shows the config log in this case.

[JCBC-269] subsequent resubscribers should not run if a resubscriber is successful

Mon, 20 May 2013 14:30:43 -0500

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-258] documentation needs to be much clearer about Query.setKey() requiring JSON encoded strings or use of ComplexKey

Mon, 20 May 2013 14:30:43 -0500

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-231] Handle View Errors (Vbucket & Merge) appropriately

Mon, 20 May 2013 14:30:44 -0500

During rebalance out it can happen that the view node is still able to service http connections, but fails with the following errors:

- error Reason: A view spec can not consist of merges exclusively.
or
- no_active_vbuckets Reason: Cannot execute view query since the node has no active vbuckets

If this is happening, the client needs to deal with it. Appropriate solution needs still to be dicussed, but one approach could be to retry on a different node. Note that this needs to work for both async and sync calls.

[JCBC-196] append/incr/decr/add/replace should not require CAS value to be passed

Duplicate — Mon, 20 May 2013 14:30:46 -0500

In the current implementation, there is no method for a non-CAS version of the append/prepend/incr/decr/add/replace operations. As per the memcached protocol, these operations do not require (but may be used with) a CAS id and requiring one greatly reduces the performance available by requiring a gets prior to the operation.

Perry

[JCBC-151] Client does timeout on connect in specific java environments (was believed to be java7 related).

Mon, 20 May 2013 14:30:47 -0500

People report that the Client does not work with 1.7. Here is a sample stack trace:

2012-11-20 00:29:11.228 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/127.0.0.1:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2012-11-20 00:29:11.240 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3f757322
2012-11-20 00:29:11.502 INFO com.couchbase.client.ViewConnection: Added localhost/127.0.0.1:8092 to connect queue
2012-11-20 00:29:11.505 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode
2012-11-20 00:29:11.647 INFO net.spy.memcached.auth.AuthThread: Authenticated to localhost/127.0.0.1:11210
2012-11-20 00:29:12.051 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection
2012-11-20 00:29:12.060 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: localhost/127.0.0.1:8092 - Session request successful
2012-11-20 00:29:17.111 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [localhost/127.0.0.1:8092(closed)]
java.lang.RuntimeException: Timed out waiting for operation
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:68)
at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:428)
at Example1.main(Example1.java:43)
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:80)
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:65)
... 2 more
2012-11-20 00:30:12.168 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client
2012-11-20 00:30:12.177 INFO com.couchbase.client.ViewNode: Couchbase I/O reactor terminated
Disconnected from the target VM, address: '127.0.0.1:65280', transport: 'socket'

Process finished with exit code 0

Also See http://www.couchbase.com/forums/thread/java-asyncconnectionmanager-timed-out-waiting-operation-please-help-console-log-included
And http://stackoverflow.com/questions/13466010/using-java-api-in-scala-to-query-views-in-couchbase-throws-timeout-exception?utm_source=twitterfeed&utm_medium=twitter

[JCBC-89] re-enable optimization after error handling in binary optimized sets is fixed in dependent spymemcached

Mon, 20 May 2013 14:30:49 -0500

re-enable optimization after error handling in binary optimized sets is fixed in dependent spymemcached

[JCBC-291] Authentication failed on 5-th client

Mon, 20 May 2013 14:30:42 -0500

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.

[JCBC-248] ensure there is a floor to tuneables such that they can't be set so a client misbehaves

Mon, 20 May 2013 14:30:43 -0500

There have been a few situations where people have either inavertently or not knowing what they're doing set various internal timings to incorrect values. We should create a floor or a ceiling for these and change them with a warning if the user attempts to misuse it.

From a recent code example:
    private static String serverList = "";
    private static long opTimeout = -1;
    private static long opQueueMaxBlockTime = -1;
    private static long obsPollInterval = -1;
    private static int obsPollMax = -1;
    private static long msReconnectThresholdTime = -1;
    private static long maxReconnectDelay = -1;
    private static boolean shouldOptimize = false;
    private static int timeoutExceptionThreshold = -1;
    private static boolean useNagleAlgorithm = false;
    private static FailureMode failureMode = FailureMode.Cancel;
    private static int ttl = 86400;
    private static int threads = 1;
    private static long msBeforeGet = 5000l;
    private static long repeat = -1;

[JCBC-250] ClassCast Exception when using durability against memcached bucket

Mon, 20 May 2013 14:30:43 -0500

Apparently trying to use these operations:
CouchbaseClient.add(String key, int exp, String value, PersistTo req, ReplicateTo rep)

Against a memcached bucket causes an exception even if "req" and "rep" are set to 0. From the user's perspective, they expect this to work. Is it a major undertaking to make the classes compatible from the client side, independent of the bucket types and then let the operation succeed/fail when it can or can't?

java.lang.ClassCastException: com.couchbase.client.CouchbaseMemcachedConnection cannot be cast to com.couchbase.client.CouchbaseConnection
at com.couchbase.client.CouchbaseClient.observePoll(CouchbaseClient.java:1708)
at com.couchbase.client.CouchbaseClient.add(CouchbaseClient.java:1293)

[JCBC-296] Document changing compression threshold

Mon, 20 May 2013 14:30:42 -0500

Please see the feature request below.

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

[JCBC-287] Failover + Readd of Streaming Node against 1.8.1 fails

Mon, 20 May 2013 14:30:42 -0500

Failover + Readd of Streaming Node against 1.8.1 fails

[JCBC-206] Need clear info and examples on proper error handling

Duplicate — Mon, 20 May 2013 14:30:45 -0500

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.

[JCBC-235] Write the Java on Linux using Eclipse section of the Essentials Guide

Duplicate — Mon, 20 May 2013 14:30:44 -0500

Write the Java on Linux using Eclipse section of the Essentials Guide

Needs to cover:

Basic Installation/Setup of Eclipse
Adding the Couchbase Java components to Eclipse
Writing your first (small) app using Couchbase within Eclipse

Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images.

[JCBC-234] Write the Java on Mac OS X using Eclipse section of the Essentials Guide

Mon, 20 May 2013 14:30:44 -0500

Write the Java on Mac OS X using Eclipse section of the Essentials Guide

Needs to cover:

Basic Installation/Setup of Eclipse
Adding the Couchbase Java components to Eclipse
Writing your first (small) app using Couchbase within Eclipse

Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images.

[JCBC-233] Write the Java on Windows with Eclipse installation instructions for essentials guide

Mon, 20 May 2013 14:30:44 -0500

Write the Java on Windows using Eclipse section of the Essentials Guide

Needs to cover:

Basic Installation/Setup of Eclipse
Adding the Couchbase Java components to Eclipse
Writing your first (small) app using Couchbase within Eclipse

Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images.

[JCBC-237] Docs: Document how to use observe properly outside of the "wrapped" methods

Mon, 20 May 2013 14:30:43 -0500

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-228] a no-args constructor and an init method are needed

Mon, 20 May 2013 14:30:44 -0500

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

[JCBC-217] Create Source-Code Styleguide

Mon, 20 May 2013 14:30:44 -0500

A style guide for all java applications should be developed and paired with checkstyle rules. If possible, also provide a howto on IDE integration and git hooks.

[JCBC-203] append/prepend are ASYNC, and can specify 0 for casunique

Mon, 20 May 2013 14:30:45 -0500

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.

[JCBC-184] API reference should show return types

Mon, 20 May 2013 14:30:46 -0500

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-201] All async ops should link to the Asynchronous Operations page

Mon, 20 May 2013 14:30:45 -0500

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

[JCBC-199] constructor documented as client method returning "(none)"

Mon, 20 May 2013 14:30:45 -0500

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 ])"

[JCBC-183] Many methods in api reference don't link to corresponding documentation page

Mon, 20 May 2013 14:30:46 -0500

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-173] flush will not work owing to MB-7381

Dependency — Mon, 20 May 2013 14:30:46 -0500

During development of 1.1, RESTful flush was written, but it turns out that there is an issue with the server implementation of flush, and it requires Administrator level credentials. This makes it impractical for clients that don't have those credentials, like a default CouchbaseClient.

This means the flush implementation is done, but won't work for now.

[JCBC-189] Views having odd timeout issues on some clusters

Dependency — Mon, 20 May 2013 14:30:46 -0500

We're seeing really strange timeout issues which seem to affect only this specific cluster and only in terms of views. We've re-installed this cluster time and time again, and we've had similar configurations run successfully as well.

More details in comment..

[JCBC-171] document how to set config options in xml config files, and all config options available

Mon, 20 May 2013 14:30:46 -0500

I can't find any info on our web site, docs, tutorials, etc. for how how to set config options for Java client usage in an xml config file. Need examples of that, and exhaustive reference of all the options that can go in a config, along the lines of what we have for the CouchbaseConnectionFactoryBuilder class at:

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

Also, it's very confusing to have 1.1 docs with useful info that applies to 1.0 docs, too, but have the 1.0 docs not updated. For example, there's no mention in the 1.0 docs of any of the stuff that is mentioned on the 1.1 sdk-ccfb page, even though lots of that would be relevant to 1.0 too.

[JCBC-117] mention that OperationFuture.get(tmo) changes state when timeout has been reached

Dependency — Mon, 20 May 2013 14:30:48 -0500

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.

[JCBC-138] Java Client does not recover when only bootstrap node provided and failovered

Mon, 20 May 2013 14:30:47 -0500

Within the current implementation, when the bootstrap node is failovered/removed (and only that one is provided in the list) it gets correctly removed from the SDK, but either a new try to get a different streaming connection fails or something else is wrong.

Even when the node is added back into the cluster no new view connection is created (most arguably because no map updates are received anymore).

This issue may also be the cause for other bugs related to failover scenarios reported.

[JCBC-169] add overloaded methods for various types to the Query class

Mon, 20 May 2013 14:30:47 -0500

Currently, all types other than strings must go through the ComplexKey class. This may not be the best approach since it leads to a bit of oddness with needing to tell the ComplexKey class to handle a single element differently.

One alternative is to improve the Query class to handle other types, then deprecate the special handling in the ComplexKey class and change the behavior for a single element. This would be a small API change, but maybe small enough that with sufficient warning, we can do it in a minor release.

[JCBC-164] Support CAS for delete operation

Duplicate — Mon, 20 May 2013 14:30:47 -0500

It would be nice if the DELETE operation would support a CAS parameter, a feature which is available in e. g. the Ruby client library. Without the possibility for checking for a given CAS value it may happen that a DELETE removes a key-value pair which was just updated by an other thread.

[JCBC-166] sync up the getting started guide on the web page to the docs

Mon, 20 May 2013 14:30:47 -0500

http://www.couchbase.com/develop/java/current should be a perfect subset of the getting started in the docs repo

[JCBC-116] Implement the ObserveSet for better observing of replication/persistence

Mon, 20 May 2013 14:30:48 -0500

Implement the ObserveSet for better observing of replication/persistence

[JCBC-18] NPE if hostnames in server bootstrap list are mixed case

Mon, 20 May 2013 14:30:49 -0500

A user described a scenario where using mixed case in their URIs lead to an NPE. This is from the map lookup, since what the couchbase cluster sends us is different than what the user entered, I think.

See: http://www.couchbase.com/forums/thread/java-client-101-exception-using-couchbaseclient-servlet-filter

[JCBC-61] Expose returned CAS value in CASResponse when available from binary protocol

Mon, 20 May 2013 14:30:49 -0500

Customer request to add the capability to retrieve new cas value after a cas() operation to avoid a subsequent gets()

[JCBC-108] observe loop implementation behind mutations should be adaptive to server persistence latencies

Mon, 20 May 2013 14:30:49 -0500

The current observe loop implementation does not acknowledge the average persistence latency which is in the observe response.

[JCBC-115] thoroughly test on_error arguments

Mon, 20 May 2013 14:30:48 -0500

Support for on_error was recently added, but it does does not currently have a test for on_error=stop.

[JCBC-114] Command Futures never receive results after rebalance-out (or other sorts of topology/network changes)

Dependency — Mon, 20 May 2013 14:30:48 -0500

Command Futures never receive results after rebalance-out (or other sorts of topology/network changes)

[JCBC-11] Need more unit tests for couchbase-client

Mon, 20 May 2013 14:30:50 -0500

        CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder();
        cfb.setOpTimeout(10000); // wait up to 10 seconds for an operation to succeed
        cfb.setOpQueueMaxBlockTime(5000); // wait up to 5 seconds when trying to enqueue an operation


For example, will fill up the funnel (the blocking queue) to the rim, but not overflow (immediately timeout). Once it's at the rim, it'll have to wait to wait until at least one operation flows out to add another operation. This *will* slow down the callers (their async calls will actually block on this internal queue), but that's okay in a bulk loader.

However, there are no unit tests in couchbase-client to test this.

[JCBC-204] document increment/decrement behavior with non-numeric value

Mon, 20 May 2013 14:32:05 -0500

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.

[JCBC-15] add showtype-options to documentation

Mon, 20 May 2013 14:30:50 -0500

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

[JCBC-205] docs for touch() should mention getAndTouch()

Mon, 20 May 2013 14:30:45 -0500

It would be nice for the touch() docs to mention getAndTouch() as a common optimization:

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-gat.html

[JCBC-161] Remove Duplication in Observe checks

Mon, 20 May 2013 14:30:47 -0500

The fix for ~~JCBC-148~~ works, but it checks against all nodes in the cluster. If you have a larger cluster, you have much more nodes than there could be assigned to a specific key. As an enhancement, the code in checkConfigAgainstPersistence should check against the nodes for the given key, not for everything.

[JCBC-113] code injection during development/debug causing IllegalStateException

Mon, 20 May 2013 14:30:48 -0500

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

[JCBC-83] replace use of java assert in tests with junit assertions, including messages

Mon, 20 May 2013 14:30:49 -0500

replace use of java assert in tests with junit assertions, including messages

[JCBC-76] Replica read command

Mon, 20 May 2013 14:30:49 -0500

Implement a simple replica read command

[JCBC-208] HTTP flush needs to be async

Wed, 9 Jan 2013 05:13:02 -0600

Since flush can take a long time, it should be possible to handle this async.

[JCBC-28] refactor the entire cluster stream connection

Thu, 31 Jan 2013 09:57:54 -0600

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-209] Clarify the sync/async nature of operations in the docs

Fri, 11 Jan 2013 00:43:28 -0600

Clarify the sync/async nature of operations in the docs

[JCBC-33] Reconfiguration strategy used in TapConnectionProvider can lead to temporary deadlock of the ConfigurationProvider thread

Tue, 13 Nov 2012 07:47:53 -0600

Let's assume for now that a new node has been added to the cluster.

1. When a configuration change is detected, the reconfigure() method of TapConnectionProvider is called.
2. TapConnectionProvider will call ((CouchbaseConnection)conn).reconfigure(bucket);
3. Inside CouchbaseConnection reconfigure() the new server will be found and added to the list newServers
4. Then createConnections(newServers) will be called in the parent class MemcachedConnection
5. Depending on the log level you'll see the message logged from getLogger().info("Added %s to connect queue", qa);
6. Then the code will hang at the line: https://github.com/couchbase/spymemcached/blob/master/src/main/java/net/spy/memcached/MemcachedConnection.java#L155

qa.setSk(ch.register(selector, ops, qa));

The code will hang until another packet is received on the channel. This is the expected behavior in Java NIO. The recommended practice is perform registrations from the same thread as selects. In this case we're registering from the thread that was monitoring for configuration changes, and selecting from the main run loop of the MemcachedConnection.

See http://stackoverflow.com/questions/1057224/thread-is-stuck-while-registering-channel-with-selector-in-java-nio-server

It's not a huge problem for us, because even in an idle situation we eventually receive a NOOP. However, this combined with another bug I was hitting and made it really hard to troubleshoot. I'd suggest we look at ways to avoid this problem.

It's also possible this is a bug in Spy and not the Java client, but I haven't studied how createConnections() is used in other contexts within spy, so it might just be how we use it when reconfiguring from the java client.

[JCBC-229] Find a way to proper test JCBC-227

Dependency — Mon, 25 Feb 2013 05:12:00 -0600

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?

[JCBC-222] prioritized disk write queue - java client

Thu, 31 Jan 2013 08:46:51 -0600

ability for the client to specify that a write should be prioritized and the server to fast track that write to disk ahead of whatever might be in the disk write queue. Especially important during the case of rebalance where they may be a million+ items in the queue and the write needs to be prioritized for whatever purpose.

Should be able to work with observe operations as well as observe+xdcr(http://www.couchbase.com/issues/browse/MB-7614)

[JCBC-221] XDCR observe - java client

Dependency — Thu, 31 Jan 2013 08:46:36 -0600

Add functionality to the Java client so that request for observe can block the request until either persisted to disk, replicated to another node intra cluster or replicated to a remote cluster.

[JCBC-5] automatically deploying to download locations

Thu, 31 Jan 2013 09:57:45 -0600

Idea here is that each commit to the master branch should automatically update a maven snapshot repository. This way, approved code is automatically available for use.

If the artifact's git describe matches a release, it should deploy to the production repository.

For example

1.0.0 is a release
1.0.0_2_gf36ab47 is 2 changes past the last release

The latter should go to a snapshot maven repo, while the former should go the production repository.

[JCBC-180] Allow for default value to append/prepend

Dependency — Tue, 7 May 2013 14:07:11 -0500

As with incr/decr, it would be very helpful to have a default value come along with the append/prepend operation to keep them atomic and avoid the extra round-trip of an add()

[JCBC-280] Provision for auth failure in case of calling createBucket in the same txn twice and adding updateBucket functionality

Fri, 26 Apr 2013 05:21:11 -0500

There are three ways using which we are creating connection in the java client to the server.

1) ClusterManager
2) BucketTool

Both of these classes internally call the ClusterManager.createBucket for creation of the bucket.

Now if I am using all the three instances of the above classes in a single function, the bucket information is overridden without any checks. Ideally using any of the connection classes if I have created a SASL bucket with some information like bucket name = 'SaslBucket', bucket password = 'password', I should not be allowed to change the password using instance of another class. There should be auth failure error being returned the second time client tries to connect to the same bucket. Server supports this because there is an Edit Bucket functionality at the server for the same.

There should be a means of distinction in the request that we want to create the bucket or update.
In case of bucket creation duplicity should be checked where as in case of update this should be allowed as is.

Also, the expectation is that, the user might update the bucket information if he requires to change the password or other details, by explicitly calling updateBucket method which is currently not available.

[JCBC-274] Jenkins test results failing.

Dependency — Mon, 13 May 2013 02:17:00 -0500

When the jenkins job for java build is run with the latest source in Git and the tests are run, 6 tests are failing. Those are very obvious errors and can be fixed. Screenshot attached.

[JCBC-266] NPE in ConfigurationProviderHTTP needs to be handled.

Dependency — Sat, 18 May 2013 01:56:46 -0500

NPE in ConfigurationProviderHTTP needs to be handled.
This is seen at quite a lot of places.

Please refer to the integration test results at :

https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdHJBNHJ0eGZfbjBaenBSVGM2VS1oNlE#gid=0

Stack Trace :

SDKD: Mar 12, 2013 1:55:39 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run
SDKD: WARNING: Resubscribe attempt failed:
SDKD: java.lang.NullPointerException
SDKD: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:149)
SDKD: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:319)
SDKD: at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:405)
SDKD: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
SDKD: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
SDKD: at java.lang.Thread.run(Thread.java:619)
SDKD: Mar 12, 2013 1:55:39 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run

[JCBC-289] Document manipulation of the designdoc/view interface

Mon, 22 Apr 2013 10:21:16 -0500

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

[JCBC-290] Support for publishing view from dev to prod

Mon, 22 Apr 2013 12:18:50 -0500

Support for publishing view from dev to prod

[JCBC-283] Document how best to use expiry with times >30 days

Fri, 12 Apr 2013 07:53:51 -0500

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-281] Document working with the cluster manager in java manual

Mon, 8 Apr 2013 10:17:47 -0500

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-279] Docs: Cross-link bulk loading and blocking queue documentation with async commands

Tue, 2 Apr 2013 19:05:49 -0500

Just had a customer potentially running >1M touch() operations all at once and not checking the return code nor having them in a blocking queue. I think it would be worthwhile to make sure that everyone realizes the importance of proper handling of async operations and it's not obvious when just looking at the API reference for an individual operation.

[JCBC-277] Provide warnings when dependencies don't match expected versions

Tue, 26 Mar 2013 11:53:42 -0500

Recent issues with netty dependencies would be easier caught if we had logging when dependencies are mismatched from what we expect.

[JCBC-275] Slow performance in virtualized environments

Wed, 20 Mar 2013 07:27:21 -0500

This is a placeholder bug meant to indicate that there are disproportionate performance impacts in the Java client when running under a virtualized environment. There are no obvious bottlenecks but it is something we've seen in multiple situations and should be investigated.

In short, there is no specific CPU, network, or disk bottleneck being hit, but performance still seems to drop significantly.

Will update with specific stats later on.

[JCBC-273] Unknown Host Exception should be caught

Fri, 15 Mar 2013 10:34:26 -0500

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

[JCBC-263] memcached connection fails with "Attempting to overwrite channel"

Mon, 11 Mar 2013 13:45:28 -0500

In this case, multiple CouchbaseClient objects are being connected. At the 14th instance, this is printed to the screen and the application hangs.

[SDKD(WARNING) 5.49 cbsdk.sdkd.remote remote.py:266] WARNING: URIs: [http://10.2.1.102:8091/pools?#]
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM com.couchbase.sdkd.cbclient.Handle makeViewTimeout
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] WARNING: ~~JCBC-168~~: Manually setting view timeout to 75000
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection createConnections
[SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] INFO: Added {QA sa=/10.2.1.102:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection createConnections
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Added {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM com.couchbase.client.CouchbaseClient <init>
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: viewmode property isn't defined. Setting viewmode to production mode
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@6d79953c
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@4934ce4a
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8}, attempt 1.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting due to failure to connect to {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] java.net.ConnectException: Could not send noop upon connect! This may indicate a running, but not responding memcached instance.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:439)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}, attempt 1.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}, attempt 3.
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] INFO: The channel or socket was null for {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Exception in thread "SDK Handle-14" java.lang.NullPointerException
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.queueReconnect(MemcachedConnection.java:589)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.reconfigure(CouchbaseMemcachedConnection.java:132)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:273)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at java.util.Observable.notifyObservers(Observable.java:159)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:258)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:188)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:288)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:246)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.SdkdConfig.getClient(SdkdConfig.java:99)
[SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.cbclient.Handle.<init>(Handle.java:159)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:104)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:189)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:245)
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.auth.AuthThread$1 receivedStatus
[SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] INFO: Authenticated to /10.2.1.102:11210
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.MemcachedConnection attemptReconnects
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.MemcachedConnection handleIO
[SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@79884a40
[SDKD(WARNING) 13.56 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.auth.AuthThread$1 receivedStatus
[SDKD(WARNING) 13.56 cbsdk.sdkd.remote remote.py:266] INFO: Authenticated to /10.2.1.101:11210
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:36 PM net.spy.memcached.MemcachedConnection attemptReconnects
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] Exception in thread "Memcached IO over {MemcachedConnection to /10.2.1.102:11210 /10.2.1.101:11210}" java.lang.AssertionError: Attempting to overwrite channel
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.setChannel(TCPMemcachedNodeImpl.java:496)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.registerChannel(TCPMemcachedNodeImpl.java:484)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.attemptReconnects(MemcachedConnection.java:680)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:262)
[SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158)

[JCBC-264] create a unit test for ensuring couchbase client configuration works with memcached bucket type

Mon, 11 Mar 2013 15:44:29 -0500

With a recent bug, we had the config's lack of warmup throwing off the configuration provider. This should be unit-testable since we have unit tests for the configuration provider.

[JCBC-262] Transcoder error not reported correctly

Mon, 11 Mar 2013 09:42:32 -0500

When a custom transcoder has an error, certain CAS operations fail with an error about the operation being cancelled, which is misleading and doesn't point to the transcoder as a problem.

Logs:
Mar 7, 2013 10:20:37 AM net.spy.memcached.protocol.TCPMemcachedNodeImpl setupResend
WARNING: Discarding partially completed op: Cmd: 0 Opaque: 120 Key: *****
Mar 7, 2013 10:20:40 AM net.spy.memcached.auth.AuthThread$1 receivedStatus
INFO: Authenticated to 127.0.0.1/127.0.0.1:11210

The error occurs on the get on the future. It is in fact a marshalling error in the transcoder but that never gets reported.

Code:
OperationFuture<CASValue<documentType>> future = this.client.asyncGets(key, transcoder);
return future.get(5, TimeUnit.SECONDS);

Transcoder (incorrect):

@Component
public class TranscoderImpl<T> implements Transcoder<T> {

@Autowired
@Qualifier("JSON")
Marshaller marshaler;

@Autowired
@Qualifier("JSON")
Unmarshaller unmarshaler;

@Override
public boolean asyncDecode(CachedData arg0) {
// TODO Auto-generated method stub
return false;
}

@Override
public T decode(CachedData arg0) {
// TODO Auto-generated method stub
StreamSource str = new StreamSource(new java.io.ByteArrayInputStream(arg0.getData()));

Object obj;
try {
obj = unmarshaler.unmarshal(str);
} catch (Exception e) {
// TODO Auto-generated catch block
throw new RuntimeException(e);
}

return (T)obj;
}

@Override
public CachedData encode(T arg0) {
// TODO Auto-generated method stub
ByteArrayOutputStream sink = new ByteArrayOutputStream();

try {
marshaler.marshal(arg0, new StreamResult(sink));
} catch (Exception e) {
// TODO Auto-generated catch block
throw new RuntimeException(e);
}

return new CachedData(0, sink.toByteArray(), getMaxSize());
}

@Override
public int getMaxSize() {
// TODO Auto-generated method stub
return CachedData.MAX_SIZE;
}

}

[JCBC-259] String starting with number converted to number only in setKey for views

Wed, 6 Mar 2013 14:52:18 -0600

If a key of "3abc" is passed in to a setKey for a view query, it will convert this into just 3.

Looking at /src/main/java/com/couchbase/client/protocol/views/Query.java:558
it looks like NumberFormat.getInstance().parse(value.toString()).toString(); will convert 3abc to 3.

This is because NumberFormat.parse is define to "Parses text from the beginning of the given string to produce a number. The method may not use the entire text of the given string." so if the string starts with a number it will not fail out and just be used as a string.

[JCBC-255] improve warmup handing

Wed, 27 Feb 2013 14:18:56 -0600

With the integration of ~~JCBC-27~~, the client will do an exponential backoff at construction time when the server is unavailable, and then throw an exception (from the ctor, unfortunately) if it could not complete.

There are scenarios where this isn't ideal. For example, if someone were to cut off power to a datacenter, the app servers will start up much faster than the Couchbase cluster will. Unfortunately, this means someone will need to go around and restart the app servers after the DB cluster is up.

This process should be improved and bootstrapping should no longer block construction. It should block operations (there is a latch for that), but not construction.

[JCBC-246] Docs: No CAS+durability in API reference table

Tue, 12 Feb 2013 07:05:05 -0600

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

Doesn't contain CAS methods with durability constraints.

[JCBC-239] Docs: Document "paginator"

Wed, 6 Feb 2013 15:18:23 -0600

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

[JCBC-295] Spring Connector Guide

Mon, 6 May 2013 11:32:41 -0500

Phase 1:

-Need intended user/audience from SME
-Need suggested topics for TOC from SME

[JCBC-301] Strange Logic in CouchbaseClient observePoll method

Thu, 9 May 2013 23:21:24 -0500

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.

[JCBC-303] javadoc builds must include spymemcached

Duplicate — Wed, 15 May 2013 11:21:36 -0500

Current javadoc build process does not include the spymemcached docs, which were included in previous releases. The documentation:

http://hub.internal.couchbase.com/confluence/display/techpubs/Using+Existing+Docs+System+%28WIP%29

does not mention how to include, nor is there evidence of how it was done before.

Need to have:

* a process that includes correct third-party documentation, when required.

* one that is not tied to a particular host

* is fully documented

[JCBC-294] OOME on ViewResponse for very large view

Thu, 2 May 2013 08:17:10 -0500

We had some complain from developer that are using large view for example 500k elements. (with small content id+url for example). The total size of the view is in this case around 52Mb.

The result out of memory.
2013-05-01 16:47:06.536 INFO
com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback:
/192.168.63.99:8092 - Session request successful
Exception in thread "I/O dispatcher 3" java.lang.OutOfMemoryError: Java
heap space
    at org.apache.http.util.CharArrayBuffer.expand(CharArrayBuffer.java:61)
    at org.apache.http.util.CharArrayBuffer.append(CharArrayBuffer.java:91)
    at org.apache.http.util.EntityUtils.toString(EntityUtils.java:200)
    at org.apache.http.util.EntityUtils.toString(EntityUtils.java:221)
    at
com.couchbase.client.protocol.views.HttpOperationImpl.getEntityString(Http
OperationImpl.java:106)
    at
com.couchbase.client.protocol.views.ViewOperationImpl.handleResponse(ViewO
perationImpl.java:60)

Note from our community member

After digging into the SDK and apache code, it occurred that the viewResponse actually contains Strings (the json objects). I think the "problem" lies in handleResponse method in ViewOperationImpl.
Here the SDK are using the apache http core to get the json String via the call
String json = getEntityString(response);
Would it be smarter to give back a InputStream instead? This could quite
easily be fixed because the response could give back a HttpEntity that
again could give the developer a InputStream.
In this way the SDK did not have to copy each Char, which it actually
does in the apache http core library (see expand in
CharArrayBufffer.class ). It does the following: char newbuffer[] = new
char[Math.max(this.buffer.length << 1, newlen)];
I think it kind of chokes when it get 52MB it have to copy from Char to a
String and then deliver it back.

BTW: I've tried calling the same view and operating on it form node.js
(using baseview and the official sdk), it just worked like a charm. And
this is prob. because you get a stream of data chunks that you can work
on, which seems more effective.

[JCBC-240] Add the total number of rows in the ViewResponce

Fri, 17 May 2013 02:38:55 -0500

It will be great to have the total number of rows in the ViewResponse object when calling a view.

This is the value present in the JSON attribute "total_rows" of a response
{"total_rows":1412,"rows":[

This enhancement request comes from the community forum:
http://www.couchbase.com/forums/thread/recommend-including-totalrows-value-java-client-viewresponse-class

[JCBC-285] Memcached connection disconnects in case of single node server instance.

Mon, 22 Apr 2013 00:43:58 -0500

When I tried to establish a Memcached Connection with a single node server - either 1.8.1 or 2.0.1, following errors were received :

2013-04-16 18:27:01.247 INFO net.spy.memcached.MemcachedConnection: Added {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
Created a MemcachedClient with port 11211
2013-04-16 18:27:01.251 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1ffb3754
2013-04-16 18:27:01.263 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000001cbc.
2013-04-16 18:27:01.266 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:27:01.267 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 1.
2013-04-16 18:27:01.268 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:27:01.268 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000001cbc Flags: 0 Exp: 0 Data Length: 52
Deepti Exception 1 java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException: Cancelled
2013-04-16 18:27:01.269 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000002cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:03.772 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000003cbc.
2013-04-16 18:27:05.271 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=2, #iq=0, topRop=null, topWop=Cmd: add Key: Emp0000000002cbc Flags: 0 Exp: 0 Data Length: 52, toWrite=0, interested=0}
2013-04-16 18:27:05.273 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@30b42a7e
2013-04-16 18:27:05.275 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000003cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:27:05.278 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000003cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8}, attempt 2.
2013-04-16 18:27:05.279 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000003cbc Flags: 0 Exp: 0 Data Length: 52
Deepti Exception 1 java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException: Cancelled
2013-04-16 18:27:05.281 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:27:05.281 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000004cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:07.783 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000005cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:10.286 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000006cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:12.788 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000007cbc.
2013-04-16 18:27:13.281 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=4, #iq=0, topRop=null, topWop=Cmd: add Key: Emp0000000004cbc Flags: 0 Exp: 0 Data Length: 52, toWrite=0, interested=0}
2013-04-16 18:27:13.283 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1a23b006
2013-04-16 18:27:13.286 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000007cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:27:13.289 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000007cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8}, attempt 3.
2013-04-16 18:27:13.291 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000007cbc Flags: 0 Exp: 0 Data Length: 52
Deepti Exception 1 java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException: Cancelled
2013-04-16 18:27:13.292 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:27:13.293 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000008cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:15.796 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000009cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:18.298 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000010cbc.
Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation
2013-04-16 18:27:29.302 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=3, #iq=0, topRop=null, topWop=Cmd: add Key: Emp0000000008cbc Flags: 0 Exp: 0 Data Length: 52, toWrite=0, interested=0}
2013-04-16 18:27:29.304 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3bb59c1b
2013-04-16 18:27:29.306 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:27:29.306 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 4.
2013-04-16 18:27:29.307 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:27:59.338 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:27:59.340 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@7685dfcf
2013-04-16 18:27:59.342 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:27:59.344 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 5.
2013-04-16 18:27:59.346 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:28:29.376 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:28:29.378 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@606145c5
2013-04-16 18:28:29.380 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:28:29.382 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 6.
2013-04-16 18:28:29.384 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:28:59.414 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:28:59.416 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@15fac189
2013-04-16 18:28:59.417 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:28:59.419 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 7.
2013-04-16 18:28:59.420 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:29:29.451 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:29:29.453 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@6520b476
2013-04-16 18:29:29.454 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:29:29.456 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 8.
2013-04-16 18:29:29.457 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:29:59.485 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:29:59.487 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3ebbe4b0
2013-04-16 18:29:59.488 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:29:59.490 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 9.
2013-04-16 18:29:59.491 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:30:29.521 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:30:29.523 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@14220a0c
2013-04-16 18:30:29.524 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:30:29.526 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 10.
2013-04-16 18:30:29.527 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:30:59.557 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:30:59.559 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@2d64ff8f
2013-04-16 18:30:59.561 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:30:59.562 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 11.
2013-04-16 18:30:59.564 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version
2013-04-16 18:31:29.582 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-04-16 18:31:29.584 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@59799a64
2013-04-16 18:31:29.585 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}
java.io.IOException: Disconnected unexpected, will reconnect.
at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247)
at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915)
2013-04-16 18:31:29.587 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 12.
2013-04-16 18:31:29.588 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version

Memcached connection is trying to re-distribute the data on other nodes in a cluster which is why the connection is not getting established.

[JCBC-244] Sample Application : fix the welcome file and gitignore

Thu, 2 May 2013 16:33:23 -0500

1- the Welcome auto redirect in Jetty does not work correctly.
2- Update the gitignore to handle IDE and OS

[JCBC-247] ViewReponse: Provide a way to return the JSON as it is

Tue, 7 May 2013 14:09:23 -0500

The Java API provide most of the time access to the JSON document (as string):
- get commands
- view command using the ViewRow.getDocument

When we call a view the result is a ViewResponse, but it is not possible to get the JSON document out of it, and the view engine returned a JSON doc.

It could be interesting for some development, to be able to do a viewResponse.toJSON() that returns the exact result of the view. (this function may not be compliant with the includesDoc(true) option)

The use case is simple, suppose I am creating a REST API and I would like to call the view and return the result to the user it would be good to do something like :

@GET
@Produces({ "application/json"})
@Path("/person/")
public String getPersons( ) {

           View view = client.getView(PERSON_DSGN_DOC, PERSON_BY_NAME_VIEW);
            Query query = new Query();
            ViewResponse viewResponse = client.query(view, query);
            return viewResponse.toJSON();

}

Today I have to loop on each result and create a new object/document

[JCBC-302] Small issue in release note 1.1.6

Mon, 13 May 2013 13:36:54 -0500

In the release note :
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-rn_1-1-6a.html

Small typo:
"(wthout the quotes) "

should be "without"

[JCBC-300] Add as Example: Java/NoSQL Tricks

Mon, 20 May 2013 14:35:47 -0500

http://www.infoworld.com/d/application-development/how-teach-java-ee-app-new-nosql-tricks-215277

[JCBC-292] Missing documentation about delete method with durability option

Thu, 25 Apr 2013 07:29:05 -0500

The Delete chapter of the documentation does not mention the methods with durability parameter (persistedto and replicatedto)

http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-delete.html#table-couchbase-sdk_java_delete

We need to put the same type of content that the one used for the store operation:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-durability.html

may be "join/merge" the store and delete?