[JCBC-450] 1.4.0 is not published on maven central Created: 17/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

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


 Description   
Just reported by support, 1.4.0 doesn't seem to be on maven central.

 Comments   
Comment by Michael Nitschinger [ 18/Apr/14 ]
It shows up:

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.couchbase.client%22%20AND%20a%3A%22couchbase-client%22

and the artifacts can be downloaded.
Comment by Michael Nitschinger [ 18/Apr/14 ]
Dont think this is a bug, maybe the person needs to update his maven index in the IDE from time to time so it gets picked up properly by autocomplete.




[JCBC-423] Publish docs for Java SDK April 2014 release Created: 27/Feb/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Edit and publish developer guide and autodocs.




[JCBC-449] Add an overview to the javadoc and the CouchbaseClient class Created: 15/Apr/14  Updated: 15/Apr/14

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

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


 Description   
The HTML generated autodocs should have a better intro and get the user to the CouchbaseClient class more directly. For instance, if you go here:
http://www.couchbase.com/autodocs/couchbase-java-client-1.4.0/index.html

One would have to click around for a bit to find what they're searching for.




[JCBC-359] not all methods are documented on CouchbaseConnectionFactoryBuilder Created: 03/Sep/13  Updated: 15/Apr/14

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

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


 Description   
Just happened to notice several methods aren't documented or don't have docs punching through from the superclass.

http://www.couchbase.com/autodocs/couchbase-java-client-1.1.9/com/couchbase/client/CouchbaseConnectionFactoryBuilder.html




[JCBC-398] Extend CAS and asyncCAS operations to return new CAS value Created: 07/Jan/14  Updated: 15/Apr/14

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

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


 Description   
The purpose being to prevent having to make a second get request if the CAS value is needed after the CAS operation.

 Comments   
Comment by loolek [ 15/Jan/14 ]
We need this feature too!
Comment by Michael Nitschinger [ 20/Feb/14 ]
Looking into it for 1.4, let's see.




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

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

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





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

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

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


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

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

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

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

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

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


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

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




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

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

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





[JCBC-408] javadoc for ComplexKey class formatted incorrectly Created: 02/Feb/14  Updated: 15/Apr/14

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

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


 Description   
Some of the code examples in the javadoc are not formatted correctly.

See:
http://www.couchbase.com/autodocs/couchbase-java-client-1.3.1/com/couchbase/client/protocol/views/ComplexKey.html




[JCBC-413] Race condition in cluster manager class Created: 11/Feb/14  Updated: 15/Apr/14

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

Type: Bug Priority: Critical
Reporter: Juan Manuel Musacchio Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
I've been experiencing some connection issues ("Unable to connecto to cluster") while listing the couchbase buckets. After some debugging I realized that could be a race condition in the ClusterManager sendRequest method. The following are the involved lines (took it from master branch):

latch.countDown(); //line 474
success.set(true); //line 475
response.set(result); //line 476

The thing is that the mutex is decreased before setting sucess and response values, so later the code will check the success variable and could fail if success is not set before the thread starts (mutex is 0). I think the code should be:

success.set(true);
response.set(result);
latch.countDown();




[JCBC-421] Query.setLimit() performance problem Created: 26/Feb/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

Type: Improvement Priority: Major
Reporter: Philip Luppens Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: performance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OSX 10.9.1, JDK 1.7.0_45-b18, Couchbase 2.1.1 CE


 Description   
I've encounter a substantial slowdown in my code when using a view in combination with a query. It seems that setting the limit (other setters have not been tried, but are likely to show similar behaviour) will eventually call net.spy.memcached.util.StringUtils#isJsonObject(). In 2.10.5 and earlier, this method will use 'new Integer()/catch NumberFormatException' to test if the passed argument can be parsed to an Integer object. However, the number of thrown and caught exceptions was severely limiting performance on my setup.

Removing the setLimit() call on my Query object resulted in a threefold increase in performance (from 600 to 1900 rps).

Original SpyMemcached issue: http://code.google.com/p/spymemcached/issues/detail?id=298

 Comments   
Comment by Michael Nitschinger [ 26/Feb/14 ]
Thanks, I'm looking into it for the 1.4.0 release
Comment by Michael Nitschinger [ 26/Feb/14 ]
What setLimit() value are you using?

While looking at the issue, even if you go in there with a value of 1 new Integer() should not throw an exception and return true?
Maybe it comes from other params in your Query part?
Could you potentially upload that profile data somewhere that I can take a look at it?
Comment by Michael Nitschinger [ 26/Feb/14 ]
http://review.couchbase.com/#/c/33930/
Comment by Philip Luppens [ 26/Feb/14 ]
Well, here is the code (not much to it):

val query: Query = new Query()
query.setKey(playerKey)
query.setLimit(1)

That is all ...
Not sure if I can get the snapshot uploaded - but I can get you a screenshot of the profiling session: http://nsesa.org/uploads/screenshots/profiler.png
Comment by Michael Nitschinger [ 03/Mar/14 ]
Alright, I did a complete rewrite of the Query internals, it is much faster now. Will for sure get this into 1.4.0 final, I'll attach some JMH benchmark results in a second.
Comment by Philip Luppens [ 03/Mar/14 ]
Thank you very much, Michael. Looking forward to the 1.4 release.
Comment by Michael Nitschinger [ 03/Mar/14 ]
Resembling your use case (note that I named old and new query objects for simplicity reasons):

    @GenerateMicroBenchmark
    public void oldWithLimitAndKey(BlackHole bh) {
        bh.consume(new OldQuery().setLimit(100).setKey("user-michael").toString());
    }

    @GenerateMicroBenchmark
    public void newWithLimitAndKey(BlackHole bh) {
        bh.consume(new NewQuery().setLimit(100).setKey("user-michael").toString());
    }

Benchmark Mode Samples Mean Mean error Units
b.Benchmark.newWithLimitAndKey thrpt 10 1234.499 10.420 ops/ms
b.Benchmark.oldWithLimitAndKey thrpt 10 235.442 5.141 ops/ms


... in your case this is a 500% perf increase on the class (1.2k ops/ms instead of 235 ops/ms).





[JCBC-426] add envvar or property to force use of HTTP or Carrier Publication style bootstrapping Created: 10/Mar/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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


 Description   
For testing as well as in-the-field workarounds for particular cases, please add a feature to be able to force one type of configuration or another.




[JCBC-427] Unintended rollback to old configuration on http disconnect. Created: 11/Mar/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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





[JCBC-436] Expose custom auth timeout setting Created: 24/Mar/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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





[JCBC-439] Fix overriding of the auth descriptor in the builder Created: 26/Mar/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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





[JCBC-446] After all nodes have been tried on NMVB, clean out the list to start over again. Created: 04/Apr/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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





[JCBC-431] Add tainted config poller for carrier configs Created: 18/Mar/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

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





[JCBC-448] TU1 Upgrade scenario | ConcurrentModificationException in memcached connection while checking timeout Created: 07/Apr/14  Updated: 10/Apr/14  Resolved: 10/Apr/14

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

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


 Description   
[445.40 INFO] (SDKD log:137) ESC[39mApr 7, 2014 5:40:59 AM net.spy.memcached.MemcachedConnection checkPotentiallyTimedOutConnectionESC[0;39m
[445.40 INFO] (SDKD log:137) ESC[39mWARNING: Retrying selector keys after ConcurrentModificationException caughtESC[0;39m
[445.40 INFO] (SDKD log:137) ESC[39mjava.util.ConcurrentModificationExceptionESC[0;39m
[445.99 INFO] (LineGobbler doFilter:115) ESC[39m+++ Following exception has internal ID: 7ESC[0;39m
[445.99 INFO] (SDKD log:137) ESC[39m at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
        at java.util.HashMap$KeyIterator.next(HashMap.java:845)
        at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1026)
        at net.spy.memcached.MemcachedConnection.checkPotentiallyTimedOutConnection(MemcachedConnection.java:496)
        at net.spy.memcached.MemcachedConnection.handleOperationalTasks(MemcachedConnection.java:428)
        at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:417)
        at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:299)ESC[0;39m
[445.99 INFO] (SDKD log:137) ESC[39mApr 7, 2014 5:40:59 AM net.spy.memcached.MemcachedConnection handleIOESC[0;39m
[445.99 INFO] (SDKD log:137) ESC[39mINFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@65b4abcbESC[0;39m
[446.00 INFO] (SDKD log:137) ESC[39mApr 7, 2014 5:40:59 AM com.couchbase.client.CouchbaseConnection addOperationESC[0;39m

 Comments   
Comment by Deepti Dawar [ 10/Apr/14 ]
This is coming because the retry logic has been added in spy for the potential timeout.




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

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

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

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

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




[JCBC-337] add new method for retrieving configuration over memcached binary protocol Created: 30/Jul/13  Updated: 07/Apr/14  Resolved: 22/Feb/14

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

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

Issue Links:
Dependency
depends on MB-8728 add a new operation which allows for ... Closed

 Description   
To support better faster, more reliable response to configuration changes, the Java client should change from HTTP streaming configuration to the new memcached binary protocol method delivered under project CCCP.

In Java, this will necessitate a new constructor to start from hostname with an optional port number, as all current constructors are intended to be RESTful and use URIs.

This is part of project CCCP, as covered at http://www.couchbase.com/wiki/display/couchbase/Cluster+Configuration+Carrier+Publication

 Comments   
Comment by Michael Nitschinger [ 22/Feb/14 ]
I'm closing this since it has been merged technically. Let's open bug reports for all specific issues we identify.




[JCBC-240] Add the total number of rows in the ViewResponce Created: 07/Feb/13  Updated: 07/Apr/14  Resolved: 20/Feb/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.2
Fix Version/s: 1.4.0-dp1
Security Level: Public

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


 Description   
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

 Comments   
Comment by Michael Nitschinger [ 12/Mar/13 ]
http://review.couchbase.com/#/c/25027/
Comment by Steffen Larsen [ 17/May/13 ]
PS: The SDK version that was used was 1.1.5
Comment by Brad Wood [ 23/Jan/14 ]
What is the status of this ticket? The patch in the link says it will be included in version 1.2.3, but the current version of the Java SDK is 1.3.1 and I don't see "total_rows" available.
Comment by Michael Nitschinger [ 20/Feb/14 ]
it's in - finally ;)
Comment by Brad Wood [ 20/Feb/14 ]
Yeah!




[JCBC-400] New feature test for credential encryption in cbc Created: 14/Jan/14  Updated: 07/Apr/14  Resolved: 14/Feb/14

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

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

Issue Links:
Dependency

 Description   
New feature test for credential encryption in cbc

 Comments   
Comment by Deepti Dawar [ 14/Jan/14 ]
http://review.couchbase.org/#/c/32355/




[JCBC-445] 'Internal Server Error' in case of views for the latest jcbc Created: 02/Apr/14  Updated: 03/Apr/14

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

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

Attachments: Zip Archive 1.4-master_2.5.0.zip     Zip Archive 1.4-master_2.5.1.zip    
Issue Links:
Dependency
depends on MB-10743 View request may return 500 when node... Open

 Description   
Tested with the master on github i.e. 1.4-dp, reports have been shared.
Http return code 500 is being returned for the views because of which re-add and rebalance out scenarios are failing, each corresponding to the server version 2.5.0 and 2.5.1. Need to check with the server team for the 'Internal Server Error' that is being returned.




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

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

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


 Description   
At the moment, there are a number of un-checked exceptions which may be thrown and aren't well described in the javadoc annotations. It would be good to add these so developers can identify things they may want to handle.




[JCBC-443] javadoc on OperationStatus.success() could be more clear Created: 27/Mar/14  Updated: 27/Mar/14

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

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


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




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

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

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

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

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

See other specifications and details on CCBC-344




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

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

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


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

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

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

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

How can I avoid duplicate of document from paginated query?

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




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

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

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

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

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

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

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

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




[JCBC-437] implement JSR-107 Java Temporary Caching API Created: 25/Mar/14  Updated: 25/Mar/14

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

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


 Description   
As previously discussed, we should look to implement JSR-107 to meet the standards.




[JCBC-435] update README info on maven repos Created: 21/Mar/14  Updated: 21/Mar/14

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

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


 Description   
I happened to look at the README earlier and it still has old maven repository info.




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

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

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


 Description   
Current advanced usage section on logging doesn't cover SLF4J. Please add that.




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

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

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


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

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

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

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

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

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




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

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

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


 Description   
CouchbaseClient.getBulk

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




[JCBC-430] Situational Test Java CCCP upgrade : Results are showing auth issues causing latency with the java client. Created: 18/Mar/14  Updated: 18/Mar/14

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

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

Issue Links:
Dependency

 Description   
Description of specific scenarios is available in the respective SDKQE JIRA tasks.




[JCBC-429] Possible race condition with add() multiple times on the same key Created: 14/Mar/14  Updated: 18/Mar/14

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

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

Issue Links:
Gantt: start-finish

 Description   
public class CouchbaseAddTest {

    private ExecutorService pool;

    public static void main(String[] args) {
        new CouchbaseAddTest().run();
    }
    
    public void run() {
        // create a pool of 4 threads
        pool = Executors.newFixedThreadPool(4);
        
        // create 4 writers to run in parallel
        List<Future> fs = new ArrayList<Future>(4);
        for (int i=0; i<4; i++) {
                fs.add(pool.submit(new Writer(i+1)));
        }
        
        for (Future f : fs) {
            try {
                f.get();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        pool.shutdown();
    }
    
    private class Writer implements Runnable {
        private int id;
        private Gson gson;

        public Writer(int id) {
            this.id = id;
            gson = new Gson();
        }
        
        @Override
        public void run() {
            try {
                // Connect to the Cluster
                CouchbaseClient client = getClient();
                
                for (int i=0; i<1; i++) {
                    addDoc(client, i);

                    try {
                        Thread.sleep(200);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
               
                // Shutting down client
                client.shutdown();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        
        private CouchbaseClient getClient() throws IOException, URISyntaxException {
            
            CouchbaseConnectionFactoryBuilder builder = new CouchbaseConnectionFactoryBuilder();
            builder.setReadBufferSize(16384); //16384
            builder.setOpTimeout(60000); //60000
            builder.setFailureMode(FailureMode.Redistribute);
            builder. setOpQueueMaxBlockTime(5000); // add extra
            
            List<URI> couchServers = Arrays.asList(
                    new URI("http://server1:8091/pools"),
                    new URI("http://server2:8091/pools"),
                    new URI("http://server3:8091/pools"),
                    new URI("http://server4:8091/pools")
            );

            CouchbaseConnectionFactory connectionFactory =
                    builder.buildCouchbaseConnection(couchServers,
                            "usage", "", "");

            return new com.couchbase.client.CouchbaseClient(connectionFactory);
        }
        
        private void addDoc(CouchbaseClient client, int n) {
            Doc doc = null;
            String value = null;

            String key = String.format("dc1-daily-%d", n);
            if (get(client, key)==null) {
                doc = new Doc();
                value = gson.toJson(doc);
                add(client, key, value);
            }
            
            key = String.format("daily-%d", n);
            if (get(client, key)==null) {
                doc = new Doc();
                value = gson.toJson(doc);
                add(client, key, value);
            }
        }
        
        private Object get(CouchbaseClient client, String key) {
            return client.gets(key);
        }
        
        private void add(CouchbaseClient client, String key, String value) {
            
            OperationFuture f = client.add(key, value);
            OperationStatus status = null;
            try {
                status = f.getStatus();
            } catch (Exception e) {
                e.printStackTrace();
            }
            if (status!=null && status.isSuccess()) {
                System.out.println(String.format("%d Writer %d - Added %s", System.currentTimeMillis(), id, key));
            } else {
                System.out.println(String.format("%d Writer %d - Add failed %s", System.currentTimeMillis(), id, key));
            }

        }
    }
    
    private static class Doc {
        
        public String[] s = {
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890",
                "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890"
        };
    }
}



In some environments, this leads to duplicate adds being reported:

1393524003358 Writer 3 - Added dc1-daily-0
1393524003360 Writer 4 - Added dc1-daily-0
1393524003363 Writer 4 - Added daily-0
1393524003363 Writer 3 - Added daily-0
1393524003367 Writer 2 - Added dc1-daily-0
1393524003368 Writer 1 - Add failed dc1-daily-0
1393524003370 Writer 2 - Added daily-0
  

instead of the correct

1393524753507 Writer 1 - Added dc1-daily-0
1393524753507 Writer 2 - Add failed dc1-daily-0
1393524753507 Writer 4 - Add failed dc1-daily-0
1393524753507 Writer 3 - Add failed dc1-daily-0
1393524753510 Writer 2 - Added daily-0
1393524753510 Writer 4 - Add failed daily-0
1393524753510 Writer 1 - Add failed daily-0
1393524753511 Writer 3 - Add failed daily-0


reproduction was not yet successful

 Comments   
Comment by Matt Ingenthron [ 17/Mar/14 ]
I also tried to reproduce this, to no avail. One suspicion (originally raised by Michael) is perhaps the nodes being used for bootstrap aren't clustered or there is something unhealthy in the cluster?

It would be great to get a debug level log which will probably point to the issue. See http://docs.couchbase.com/couchbase-sdk-java-1.3/#configuring-logging for information on setting up logging.




[JCBC-420] 2 Threads of add() operation loops show success on first op Created: 25/Feb/14  Updated: 13/Mar/14  Resolved: 13/Mar/14

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

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


 Description   
Similar to: http://www.couchbase.com/issues/browse/JCBC-419

Two threads, each with a loop of add() operations over keys, they both start with same key. In both loops the first operation succeeds according to the OperationFuture [op.get()].

I was using Java SDK 1.3.2 running against Couchbase server 2.2.0


 Comments   
Comment by Jasdeep Jaitla [ 13/Mar/14 ]
moved to: https://www.couchbase.com/issues/browse/CBSE-995




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

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

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


 Description   
The profiling added in 1.2 has not been documented. We should add a section for that. It doesn't even seem to be in the release notes. I found it on Michael's blog, but it should be in the documentation too.




[JCBC-424] investigate adding a ping or other check to idle connections Created: 02/Mar/14  Updated: 02/Mar/14

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

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


 Description   
There have been a couple of reports of idle TCP connections causing operation failures. The underlying cause seems to be that some of these environments terminate seemingly idle TCP connections.

There are probably two solutions.
1) Don't let them go idle. On some existing thread or maybe with some kind of timer, do a version() operation or such regularly.
2) If it's possibly idle, send a ping before trying to send an op.

Of course, a 3rd solution is to automatically retry idempotent operations.




[JCBC-422] add discussion of timeout accuracy and implementation to documentation Created: 27/Feb/14  Updated: 27/Feb/14

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

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


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





[JCBC-417] Need asyncGetFromReplicaS() method Created: 19/Feb/14  Updated: 25/Feb/14  Resolved: 25/Feb/14

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

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


 Description   
There is no asyncGetFromReplicaS() method currently which can return CAS value like the asyncGetS(). This will help passing the CAS value in subsequent writes using CAS.

 Comments   
Comment by Michael Nitschinger [ 20/Feb/14 ]
looking into it for 1.4, it would be asyncGetsFromReplica :)




[JCBC-418] Deadlock in ViewConnection with Rebalance and retry requests Created: 21/Feb/14  Updated: 22/Feb/14  Resolved: 22/Feb/14

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

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





[JCBC-414] typo in release notes for 1.3.2 Created: 11/Feb/14  Updated: 20/Feb/14  Resolved: 20/Feb/14

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

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


 Description   
"if a custom execturo is passed in."




[JCBC-416] Client throws exception "Cannot cache data larger than 20971520 bytes" when receiving uncompressed document from server Created: 17/Feb/14  Updated: 17/Feb/14

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

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


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




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

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

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


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




[JCBC-203] append/prepend are ASYNC, and can specify 0 for casunique Created: 02/Jan/13  Updated: 13/Feb/14

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

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


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

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

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

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




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

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

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


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

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

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




[JCBC-410] Java February 2014 documentation release Created: 05/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JCBC-411 Publish Java February 2014 documentat... Technical task Closed Amy Kurtzman  
JCBC-412 Upload Javadocs Technical task Closed Amy Kurtzman  




Java February 2014 documentation release (JCBC-410)

[JCBC-412] Upload Javadocs Created: 05/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Upload javadocs to autodocs




Java February 2014 documentation release (JCBC-410)

[JCBC-411] Publish Java February 2014 documentation Created: 05/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Edit and publish the updated SDK documentation.




[JCBC-403] Fix undetected streaming disconnect on pure-view workloads Created: 22/Jan/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

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





[JCBC-409] clarify behavior or *getFromReplica in javadoc Created: 03/Feb/14  Updated: 03/Feb/14

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

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


 Description   
I've seen questions a few times on how replica read behaves w.r.t. multiple replicas and recovery of the active location.

IIRC, the getFromReplica() will give you the first responder and the asyncGetFromReplica() will give you a future which has all the responses? The javadoc doesn't indicate this though, so it'd be great if we can clarify.




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

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

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


 Description   
If documentation changes are small or none, plan is to supply Amy the release notes markdown and she'll handle the creation of the new doc set for 1.4.0.

Please attach it here and assign to Amy when complete.




[JCBC-404] Views created via with carriage returns are not executable via web admin Created: 23/Jan/14  Updated: 23/Jan/14

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

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


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

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

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

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

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

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

return arguments.viewFunction;
}
{code}


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

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

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

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

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

Since I am on Windows, each line ending in the map function is a carriage return followed by a line feed. The view will create and will be executable via the SDK and via the REST interface, but not via the web admin. After I modified the CFML SDK to strip out ASCII code 13 from the map and reduce functions, they work as expected.




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

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

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


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

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

Perl: Multi version of "arithmetic"

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

JavaScript: Now changed to arithmeticMulti()

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


Cheers,

--

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




[JCBC-399] ViewFuture Listeners get completed twice Created: 11/Jan/14  Updated: 14/Jan/14  Resolved: 14/Jan/14

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

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


 Description   
This is a regression from 1.3.0.

See https://github.com/ReactiveCouchbase/ReactiveCouchbase-core/issues/3 for more details

 Comments   
Comment by Michael Nitschinger [ 13/Jan/14 ]
http://review.couchbase.com/#/c/32305/




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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




[JCBC-391] Documentation for Java 1.3 Created: 19/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Σ Remaining Estimate: 4h Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 4h Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JCBC-392 Create documentation files for Java 1.3 Technical task Closed Amy Kurtzman  
JCBC-393 Publish Java 1.3 documentation Technical task Closed Amy Kurtzman  
JCBC-394 Autodocs for Java 1.3 Technical task Closed Amy Kurtzman  

 Description   
Documentation tasks for Java 1.3 release




Documentation for Java 1.3 (JCBC-391)

[JCBC-394] Autodocs for Java 1.3 Created: 19/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h


 Description   
Michael, when you create the autodocs for Java 1.3, please attach them to this task and reassign to me. Thanks, Amy




Documentation for Java 1.3 (JCBC-391)

[JCBC-393] Publish Java 1.3 documentation Created: 19/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 2h
Time Spent: Not Specified
Original Estimate: 2h


 Description   
This task includes:
1. Edit release notes.
2. Edit other revisions to the document.
3. Add new version to nanoc.yaml file.
4. Update links on www.couchbase.com/documentation
5. Publish document on external website (docs.couchbase.com).




[JCBC-396] Align getDesignDocument with other designDoc methods name-wise Created: 07/Jan/14  Updated: 09/Jan/14  Resolved: 09/Jan/14

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

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





[JCBC-397] Output Configuration Info on CouchbaseClient init Created: 07/Jan/14  Updated: 09/Jan/14  Resolved: 09/Jan/14

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

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





[JCBC-386] Report info when group and group_level are used together (was: Unable to use group_level to group using java client) Created: 03/Dec/13  Updated: 07/Jan/14  Resolved: 07/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Vikrant Mahajan Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: issue
Remaining Estimate: 2h
Time Spent: Not Specified
Original Estimate: 2h
Environment: Couchbase server 2.1.1
Client 1.2.2 from maven
Windows 7
Java 6


 Description   
Query Class contains HashMap for arguments for the class which later get converted to QueryURI.

But when using group=true and group level in object the response is not grouped because the group=true is applied last in the URL due to which response does not contains the grouped data.

Possible fixes.
1. Use LinkedHashMap in place of HashMap
2. Make the rest api of couchbase order independent of parameters

 Comments   
Comment by Vikrant Mahajan [ 03/Dec/13 ]
HashMap does not maintains the order due to which no guarantee is there about order of keys in toString() method of Query Class.
Use linkedhashmap to solve the issue and maintain the insertion order of keys
Comment by Michael Nitschinger [ 03/Dec/13 ]
Thanks for reporting, I'll look into it.
Comment by Michael Nitschinger [ 19/Dec/13 ]
After looking into it, there's a different thing.

The problem is that you technically should not use group and group_level together.. you can try that.. basically group=true means "highest group level" implicitly.

so if you use group_level, there is no need to set group to true at all, which will also fix your issue.
But please note that this is a common mistake, so I'll add a log info when both are set to people can fix it.

Does that make sense?
Comment by Michael Nitschinger [ 19/Dec/13 ]
I've updated the ticket name to reflect the issue.
Comment by Michael Nitschinger [ 19/Dec/13 ]
http://review.couchbase.org/#/c/31250
Comment by Michael Nitschinger [ 07/Jan/14 ]
docs added in master.




[JCBC-361] Add capability of async+durability without blocking (set, add, replace, delete and cas) Created: 17/Sep/13  Updated: 03/Jan/14  Resolved: 03/Jan/14

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

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

Issue Links:
Duplicate
duplicates JCBC-389 Make PersistTo/ReplicateTo really asy... Resolved
is duplicated by JCBC-389 Make PersistTo/ReplicateTo really asy... Resolved

 Description   
Thought this existed somewhere but couldn't find, feel free to mark as duplicate.

At the moment, there is no async operation for doing a CAS write with durability constraints.




[JCBC-390] Refactor ClusterManager to use new HttpCore functionality. Created: 19/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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





[JCBC-388] Refactor View Connection Management Created: 16/Dec/13  Updated: 31/Dec/13  Resolved: 31/Dec/13

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

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

Issue Links:
Relates to
relates to JCBC-151 Client does timeout on connect in spe... Resolved

 Description   
The underlying connection management for views has some flaws that need to be fixed in order to guarantee throughput and liveness even under failure conditions.

 Comments   
Comment by Michael Nitschinger [ 31/Dec/13 ]
merged into master




[JCBC-151] Client does timeout on connect in specific java environments (was believed to be java7 related). Created: 21/Nov/12  Updated: 31/Dec/13  Resolved: 31/Dec/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: 1.3.0
Security Level: Public

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

Issue Links:
Relates to
relates to JCBC-388 Refactor View Connection Management Resolved

 Description   
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

 Comments   
Comment by Quinn Slack [ 27/Nov/12 ]
This doesn't appear to be strictly related to Java7. I was able to get similar code to work on Java7. I even simulated loading a Play2 environment with other JARs that could potentially cause conflicts. It's possible that my simulation of the Play2 environment was insufficient and that Play2 does other stuff...

Code at https://github.com/sqs/couchbase-scala-example. Run with:

CBURL=http://localhost:8091/pools CBPASSWORD=mypassword sbt -Dconfig.file=conf/application.conf '~run'

Here is the output on my system that shows it's on Java7 (openjdk) and that shows the expected output from the views:

on java version 1.7.0_09
[info] play - Application started (Prod)
2012-11-27 01:34:27.115 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-27 01:34:27.120 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@6267e5a2
2012-11-27 01:34:27.147 INFO com.couchbase.client.ViewConnection: Added localhost/127.0.0.1:8092 to connect queue
2012-11-27 01:34:27.149 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode
2012-11-27 01:34:27.176 INFO net.spy.memcached.auth.AuthThread: Authenticated to localhost/127.0.0.1:11210
2012-11-27 01:34:27.282 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection
2012-11-27 01:34:27.288 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: localhost/127.0.0.1:8092 - Session request successful
Res = List(com.couchbase.client.protocol.views.ViewRowNoDocs@4667820f, com.couchbase.client.protocol.views.ViewRowNoDocs@358bcae5, com.couchbase.client.protocol.views.ViewRowNoDocs@6cb59bd9, com.couchbase.client.protocol.views.ViewRowNoDocs@70afb51, com.couchbase.client.protocol.views.ViewRowNoDocs@61f98673)
2012-11-27 01:34:27.396 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client
2012-11-27 01:34:27.403 INFO com.couchbase.client.ViewNode: Couchbase I/O reactor terminated
Comment by Michael Nitschinger [ 27/Nov/12 ]
Are you running on jdk7 on mac? Also, when you use play 2.1 it should work. Play2-related issues more were because of netty version incompatibilities.
Comment by Quinn Slack [ 27/Nov/12 ]
This is jdk7 on Arch Linux and Play 2.1-RC1.

I tried using a different netty, but no luck. What worked for me was moving calls to "new CouchbaseClient" out of static "object" initializers, since they appeared to be getting called in the Netty I/O thread (I got this exception in new CouchbaseClient: java.lang.IllegalStateException: await*() in I/O thread causes a dead lock or sudden performance drop. Use addListener() instead or call await*() from a different thread).
Comment by Michael Nitschinger [ 28/Nov/12 ]
Hi Quinn, this issue is a different one! The issue described here is that people seem to find connection timeouts with java 7.
Comment by Quinn Slack [ 28/Nov/12 ]
They may be related--or may just have similar symptoms. I was not getting timeout exceptions, but I was seeing view requests hang indefinitely until I made the fix described above.
Comment by dragos [ 13/Mar/13 ]
Hi Michael, can you help with this error ? I am trying to find a workaround or something to work. This is the only thing which is keeping us from using Couchbase. I also posted here : http://www.couchbase.com/forums/thread/couchbase-connectivity-problem-aws-vpc . As you can see in the times the timeout is received really fast.

2013-03-13 11:40:47.702 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/10.0.X.XXX:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2013-03-13 11:40:52.712 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@5cbfe9d
2013-03-13 11:40:52.840 INFO net.spy.memcached.auth.AuthThread: Authenticated to 10.0.X.XXX/10.0.X.XXX:11210
2013-03-13 11:40:57.860 INFO com.couchbase.client.ViewConnection: Added 10.0.X.XXX to connect queue
2013-03-13 11:40:57.863 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode
2013-03-13 11:40:58.070 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection
2013-03-13 11:40:58.077 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: /10.0.X.XXX:8092 - Session request successful
2013-03-13 11:41:03.113 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [10.0.X.XXX/10.0.X.XXX:8092]
Exception in thread "main" java.lang.RuntimeException: Timed out waiting for operation
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:67)
        at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:475)
        at couchbase.training.view.poc.CouchbasePOC.main(CouchbasePOC.java:63)
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation
        at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:85)
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:74)
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:64)
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hi dragos,

can you please post the full code where you connect to couchbase? (including factories and such)

Thanks!
Comment by dragos [ 13/Mar/13 ]
Hi Mike, this is the POC client for Couchbase:
package couchbase.training.view.poc;

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.net.URI;
import java.util.LinkedList;
import java.util.List;
import java.util.concurrent.TimeUnit;

import org.apache.commons.io.IOUtils;
import org.json.JSONException;
import org.json.XML;

import com.couchbase.client.CouchbaseClient;
import com.couchbase.client.CouchbaseConnectionFactory;
import com.couchbase.client.CouchbaseConnectionFactoryBuilder;
import com.couchbase.client.protocol.views.ComplexKey;
import com.couchbase.client.protocol.views.Query;
import com.couchbase.client.protocol.views.Stale;
import com.couchbase.client.protocol.views.View;
import com.couchbase.client.protocol.views.ViewResponse;
import com.couchbase.client.protocol.views.ViewRow;

public class CouchbasePOC
{
public static void main(String[] args) throws FileNotFoundException, JSONException, IOException
{
System.out.println("Hello from CouchBase");

// Set the URIs and get a client
final List<URI> uris = new LinkedList<URI>();

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

final String mappedName="problems";
long start = System.currentTimeMillis();

CouchbaseConnectionFactoryBuilder m_couchbaseConnectionFactoryBuilder = new CouchbaseConnectionFactoryBuilder();
m_couchbaseConnectionFactoryBuilder.setMaxReconnectDelay(10000);
m_couchbaseConnectionFactoryBuilder.setOpQueueMaxBlockTime(100);
m_couchbaseConnectionFactoryBuilder.setOpTimeout(20000);
m_couchbaseConnectionFactoryBuilder.setShouldOptimize(true);
m_couchbaseConnectionFactoryBuilder.setViewTimeout(300000);

CouchbaseConnectionFactory connFactory = m_couchbaseConnectionFactoryBuilder.buildCouchbaseConnection(uris, mappedName, "");

CouchbaseClient client = null;
try
{
client = new CouchbaseClient(connFactory);
}
catch (IOException e)
{
System.err.println("IOException connecting to Couchbase: " + e.getMessage());
System.exit(1);
}

final View view = client.getView(mappedName, mappedName);
final Query query = new Query();

final ComplexKey key = ComplexKey.of("problem",null,null,null,null);
query.setKey(key);
query.setStale( Stale.UPDATE_AFTER );
int counter=0;
try
{
final ViewResponse result = client.query(view, query);
for(ViewRow row : result)
{
counter++;
System.out.println(row.getId());
}
}
catch(java.lang.VerifyError e)
{
System.out.println("Error: " + e.getMessage());
}

System.out.println("time: " + (System.currentTimeMillis()-start) );
System.out.println("documents: " + counter );

client.shutdown(3, TimeUnit.SECONDS);
System.exit(0);
}
}
Comment by dragos [ 13/Mar/13 ]
I hope you would not mind that i called you Mike and not Michael.
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hehe no worries.

Can you do me a favor and remove the factory for a second and just use CouchbaseClient() without anything else? Let me know if the problem still persists or not! Thanks
Comment by dragos [ 13/Mar/13 ]
Hi Michael,
First i want to thank you for the quick feed-back. Your owesome !!!

Before using the factory i used the CouchbaseClient(uris, bucketName, "") which is also timing out. I added the factory to be able increase the timeout times for the connection but still the same problem.
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hmm okay, so its not the factory (we had some issues with default values in the past, thats why I'm asking).

Can you pin me down your operating system and exact java version you're using?Thanks for your help!
Comment by Michael Nitschinger [ 13/Mar/13 ]
Also, since you're so responsive (I hope we can pin this down finally!).. Can you run the same code with DEBUG log enabled (see https://code.google.com/p/spymemcached/wiki/Logging).. just use Logger.getLogger("com.couchbase.client").setLevel(Level.FINEST); instead of Logger.getLogger("net.spy.memcached").setLevel(Level.FINEST);

Thanks!
Comment by dragos [ 13/Mar/13 ]
This is my test environment for the client which will be similar for production.
OS Ubuntu Server 11.10 x64
java -version result:
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

My network infrastructure is like this:
In an AWS virtual private center (VPC) i have a subnet and in this subnet there are 2 machines. The client machine and the Couchbase server. The machines have identical OS and java version as mentioned above. I have open the ports and also checked the network ACL. The traffic is free to go,no restriction. If i am using a rest query with curl for the view i receive the result, the problem is only in the java SDK.
If needed more information please ask. I will gladly offer it.

Comment by Michael Nitschinger [ 13/Mar/13 ]
Hi Dragos,

yes, if you can please rerun the script with DEBUG logging enabled (see last comment).. Thanks very much in advance!
Comment by dragos [ 13/Mar/13 ]
I've setted the logger to finest and this is the error log obtained. Also i tested again the connection with curl and no problemes.

Mar 13, 2013 1:30:14 PM com.couchbase.client.CouchbaseProperties setPropertyFile
INFO: Could not load properties file "cbclient.properties" because: File not found with system classloader.
2013-03-13 13:30:14.679 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2013-03-13 13:30:19.689 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@4e99353f
2013-03-13 13:30:19.810 INFO net.spy.memcached.auth.AuthThread: Authenticated to 10.0.7.164/10.0.7.164:11210
2013-03-13 13:30:24.828 INFO com.couchbase.client.ViewConnection: Added 10.0.7.164 to connect queue
2013-03-13 13:30:24.830 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode
2013-03-13 13:30:25.025 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection
2013-03-13 13:30:25.033 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: /10.0.7.164:8092 - Session request successful
2013-03-13 13:30:30.083 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [10.0.7.164/10.0.7.164:8092]
Exception in thread "main" java.lang.RuntimeException: Timed out waiting for operation
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:67)
        at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:475)
        at couchbase.training.view.poc.CouchbasePOC.main(CouchbasePOC.java:68)
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation
        at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:85)
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:74)
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:64)
        ... 2 more

curl result

curl http://10.0.7.164:8092/problems/_design/dev_problems/_view/problems?stale=false\&connection_timeout=60000\&limit=10\&skip=0
{"total_rows":0,"rows":[
]
}
[4]+ Done
Comment by dragos [ 13/Mar/13 ]
I am available for next steps in debuging. With what can i help next ?
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hi, hmm no there should be more output (DEBUG), not just info... you need to copy this whole snippet before your code actually executes:

        // Tell spy to use the SunLogger
        Properties systemProperties = System.getProperties();
        systemProperties.put("net.spy.log.LoggerImpl", "net.spy.memcached.compat.log.SunLogger");
        System.setProperties(systemProperties);

        Logger.getLogger("com.couchbase.client").setLevel(Level.FINEST);

        //get the top Logger
        Logger topLogger = java.util.logging.Logger.getLogger("");

        // Handler for console (reuse it if it already exists)
        Handler consoleHandler = null;
        //see if there is already a console handler
        for (Handler handler : topLogger.getHandlers()) {
            if (handler instanceof ConsoleHandler) {
                //found the console handler
                consoleHandler = handler;
                break;
            }
        }

        if (consoleHandler == null) {
            //there was no console handler found, create a new one
            consoleHandler = new ConsoleHandler();
            topLogger.addHandler(consoleHandler);
        }

        //set the console handler to fine:
        consoleHandler.setLevel(java.util.logging.Level.FINEST);


I guess you're running it from your IDE?
Comment by dragos [ 13/Mar/13 ]
I am building the client on local IDE then uploading it to EC2 test machine. The snipped of code word and now i have a full log.

Mar 13, 2013 1:53:10 PM com.couchbase.client.CouchbaseProperties setPropertyFile
INFO: Could not load properties file "cbclient.properties" because: File not found with system classloader.
Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP readToString
FINE: Attempting to read configuration from URI: http://10.0.7.164:8091/pools
Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP readToString
FINE: Attempting to read configuration from URI: http://10.0.7.164:8091/pools/default?uuid=44b1e62dd7e65cd38ae7faaabe5ebb64
Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP readToString
FINE: Attempting to read configuration from URI: http://10.0.7.164:8091/pools/default/buckets?v=120523822&uuid=44b1e62dd7e65cd38ae7faaabe5ebb64
Mar 13, 2013 1:53:11 PM net.spy.memcached.MemcachedConnection createConnections
INFO: Added {QA sa=/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.VBucketNodeLocator fillNodesEntries
FINE: Updating nodesMap in VBucketNodeLocator.
Mar 13, 2013 1:53:16 PM com.couchbase.client.vbucket.VBucketNodeLocator fillNodesEntries
FINE: Adding node with address 10.0.7.164:11210.
Mar 13, 2013 1:53:16 PM com.couchbase.client.vbucket.VBucketNodeLocator fillNodesEntries
FINE: Node added is {QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8}.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Done dealing with queue.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selecting with delay of 0ms
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selected 1, selected 1 keys
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Handling IO for: sun.nio.ch.SelectionKeyImpl@2c76e369 (r=false, w=false, c=true, op={QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8})
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@2c76e369
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection insertOperation
FINE: Added Cmd: 10 Opaque: 1 to {QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=1, topRop=null, topWop=null, toWrite=0, interested=8}
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads
FINE: Read 24 bytes
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads
FINE: Completed read op: Cmd: 10 Opaque: 1 and giving the next 0 bytes
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleInputQueue
FINE: Handling queue
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Done dealing with queue.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selecting with delay of 0ms
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: No selectors ready, interrupted: false
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Done dealing with queue.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selecting with delay of 0ms
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: No selectors ready, interrupted: false
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleInputQueue
FINE: Handling queue
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Done dealing with queue.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selecting with delay of 0ms
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selected 1, selected 1 keys
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection insertOperation
FINE: Added SASL auth operation to {QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL auth operation, toWrite=0, interested=4}
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Handling IO for: sun.nio.ch.SelectionKeyImpl@2c76e369 (r=false, w=true, c=false, op={QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL auth operation, toWrite=0, interested=4})
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Done dealing with queue.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selecting with delay of 0ms
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selected 1, selected 1 keys
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Handling IO for: sun.nio.ch.SelectionKeyImpl@2c76e369 (r=true, w=false, c=false, op={QA sa=10.0.7.164/10.0.7.164:11210, #Rops=1, #Wops=0, #iq=0, topRop=SASL auth operation, topWop=null, toWrite=0, interested=1})
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads
FINE: Read 37 bytes
Mar 13, 2013 1:53:16 PM net.spy.memcached.auth.AuthThread$1 receivedStatus
INFO: Authenticated to 10.0.7.164/10.0.7.164:11210
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads
FINE: Completed read op: SASL auth operation and giving the next 0 bytes
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Done dealing with queue.
Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO
FINE: Selecting with delay of 0ms
Mar 13, 2013 1:53:21 PM com.couchbase.client.ViewConnection createConnections
INFO: Added 10.0.7.164 to connect queue
Mar 13, 2013 1:53:21 PM com.couchbase.client.CouchbaseClient <init>
INFO: viewmode property isn't defined. Setting viewmode to production mode
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP subscribe
FINE: Subscribing an object for reconfiguration updates com.couchbase.client.CouchbaseClient
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream
FINEST: Channel state changed: [id: 0x2e273686] OPEN


Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream
FINER: Channel state change is not a disconnect. Event value is true and Channel State is OPEN.
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream
FINEST: Channel state changed: [id: 0x2e273686, /10.0.7.213:55729 => /10.0.7.164:8091] BOUND: /10.0.7.213:55729


Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream
FINER: Channel state change is not a disconnect. Event value is /10.0.7.213:55729 and Channel State is BOUND.
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream
FINEST: Channel state changed: [id: 0x2e273686, /10.0.7.213:55729 => /10.0.7.164:8091] CONNECTED: /10.0.7.164:8091


Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream
FINER: Channel state change is not a disconnect. Event value is /10.0.7.164:8091 and Channel State is CONNECTED.
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: STATUS: 200 OK
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: VERSION: HTTP/1.1
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: HEADER: Cache-Control = no-cache
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: HEADER: Content-Type = application/json; charset=utf-8
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: HEADER: Date = Wed, 13 Mar 2013 13:55:42 GMT
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: HEADER: Pragma = no-cache
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: HEADER: Server = Couchbase Server 2.0.0-1976-rel-enterprise
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: HEADER: Transfer-Encoding = chunked
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER:

Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: CHUNKED CONTENT {
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: {"name":"problems","bucketType":"membase","authType":"sasl","saslPassword":"","proxyPort":0,"replicaIndex":false,"uri":"/pools/default/buckets/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","streamingUri":"/pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","localRandomKeyUri":"/pools/default/buckets/problems/localRandomKey","controllers":{"compactAll":"/pools/default/buckets/problems/controller/compactBucket","compactDB":"/pools/default/buckets/problems/controller/compactDatabases"},"nodes":[{"couchApiBase":"http://10.0.7.164:8092/problems","replication":0.0,"clusterMembership":"active","status":"healthy","thisNode":true,"hostname":"10.0.7.164:8091","clusterCompatibility":131072,"version":"2.0.0-1976-rel-enterprise","os":"x86_64-unknown-linux-gnu","ports":{"proxy":11211,"direct":11210}}],"stats":{"uri":"/pools/default/buckets/problems/stats","directoryURI":"/pools/default/buckets/problems/statsDirectory","nodeStatsListURI":"/pools/default/buckets/problems/nodes"},"ddocs":{"uri":"/pools/default/buckets/problems/ddocs"},"nodeLocator":"vbucket","autoCompactionSettings":false,"fastWarmupSettings":false,"uuid":"7675b7791efe17220792c2b41ff6c824","vBucketServerMap":{"hashAlgorithm":"CRC","numReplicas":1,"serverList":["10.0.7.164:11210"],"vBucketMap":[[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: Chunk length is: 3066
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: 0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: Chunk length is: 2048
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: ],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: Chunk length is: 3072
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: 1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1]]},"bucketCapabilitiesVer":"","bucketCapabilities":["touch","couchapi"]}
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog
FINER: Chunk length is: 361
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketMonitor logFiner
FINER: Getting server list returns this last chunked response:
{"name":"problems","bucketType":"membase","authType":"sasl","saslPassword":"","proxyPort":0,"replicaIndex":false,"uri":"/pools/default/buckets/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","streamingUri":"/pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","localRandomKeyUri":"/pools/default/buckets/problems/localRandomKey","controllers":{"compactAll":"/pools/default/buckets/problems/controller/compactBucket","compactDB":"/pools/default/buckets/problems/controller/compactDatabases"},"nodes":[{"couchApiBase":"http://10.0.7.164:8092/problems","replication":0.0,"clusterMembership":"active","status":"healthy","thisNode":true,"hostname":"10.0.7.164:8091","clusterCompatibility":131072,"version":"2.0.0-1976-rel-enterprise","os":"x86_64-unknown-linux-gnu","ports":{"proxy":11211,"direct":11210}}],"stats":{"uri":"/pools/default/buckets/problems/stats","directoryURI":"/pools/default/buckets/problems/statsDirectory","nodeStatsListURI":"/pools/default/buckets/problems/nodes"},"ddocs":{"uri":"/pools/default/buckets/problems/ddocs"},"nodeLocator":"vbucket","autoCompactionSettings":false,"fastWarmupSettings":false,"uuid":"7675b7791efe17220792c2b41ff6c824","vBucketServerMap":{"hashAlgorithm":"CRC","numReplicas":1,"serverList":["10.0.7.164:11210"],"vBucketMap":[[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1]]},"bucketCapabilitiesVer":"","bucketCapabilities":["touch","couchapi"]}
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update
FINEST: Received an update, notifying reconfigurables about a com.couchbase.client.vbucket.config.Bucketcom.couchbase.client.vbucket.config.Bucket@4cf3fdc4
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update
FINEST: It says it is problems and it's talking to /pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824
Mar 13, 2013 1:53:21 PM com.couchbase.client.CouchbaseConnection reconfigure
FINE: Node 10.0.7.164/10.0.7.164:11210 will stay in cluster config after reconfiguration.
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.VBucketNodeLocator updateLocator
FINE: Received updated configuration with insignificant changes.
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update
FINEST: Received an update, notifying reconfigurables about a com.couchbase.client.vbucket.config.Bucketcom.couchbase.client.vbucket.config.Bucket@fadb83cf
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update
FINEST: It says it is problems and it's talking to /pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824
Mar 13, 2013 1:53:21 PM com.couchbase.client.CouchbaseConnection reconfigure
FINE: Node 10.0.7.164/10.0.7.164:11210 will stay in cluster config after reconfiguration.
Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.VBucketNodeLocator updateLocator
FINE: Received updated configuration with insignificant changes.
Mar 13, 2013 1:53:21 PM com.couchbase.client.http.AsyncConnectionManager processConnectionRequests
INFO: Opening new Couchbase HTTP connection
Mar 13, 2013 1:53:21 PM com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback completed
INFO: /10.0.7.164:8092 - Session request successful
Mar 13, 2013 1:53:21 PM com.couchbase.client.ViewNode$EventLogger connectionOpen
FINE: Connection open: [/10.0.7.164:8092]
Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionTimeout
SEVERE: Connection timed out: [10.0.7.164/10.0.7.164:8092]
Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionClosed
FINE: Connection closed: [10.0.7.164/10.0.7.164:8092(closed)]
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hi, thanks for the log..

interestingly, there is nothing unusual in this.. I'll investigate further and come back to you if I need more info..

thanks so far!
Comment by dragos [ 13/Mar/13 ]
Thank you for spending time on this. Looking forward for a fix :) .
Comment by Michael Nitschinger [ 13/Mar/13 ]
interestingly, the connection is open and then times out...

INFO: /10.0.7.164:8092 - Session request successful
Mar 13, 2013 1:53:21 PM com.couchbase.client.ViewNode$EventLogger connectionOpen
FINE: Connection open: [/10.0.7.164:8092]
Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionTimeout
SEVERE: Connection timed out: [10.0.7.164/10.0.7.164:8092]
Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionClosed
FINE: Connection closed: [10.0.7.164/10.0.7.164:8092(closed)]

this sounds highly suspicious to me, maybe this is a bug in apache httpcore-nio...
Comment by dragos [ 13/Mar/13 ]
The time out is displayed after 5 seconds. As you suggested i removed the factory and the detailed logged above i obtained with using CouchbaseClient(uris, mappedName, ""). Do you have some way of testing the httpCore-nio ? Should i try to look for latest version of httpCore-nio.. ?
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hi,

yes you could try that.. I ran the test suite with 4.2.3 which is the latest one and there were no errors, so our code should work with it. You need to exchange the httpcore and httpcore-nio with the latest 4.2.3 jars

I don't think this is 100% the issue, but it helps us get rid of one more factor!

Thanks!
Michael
Comment by Michael Nitschinger [ 13/Mar/13 ]
Okay, the 5 second period can come from this:

 HttpParams params = new SyncBasicHttpParams();
      params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, 5000)
          .setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, 5000)
....


SO_TIMEOUT is: Defines the socket timeout (SO_TIMEOUT) in milliseconds, which is the timeout for waiting for data or, put differently, a maximum period inactivity between two consecutive data packets).

and CONNECTION_TIMEOUT is: Determines the timeout in milliseconds until a connection is established.


Dragos, can it be the case that it takes more than 5 seconds to return a result when using curl or so? That would explain the "fail fast" timeout here.. not saying that these times are okay this way, just to find the root cause..

Thanks!
Comment by dragos [ 13/Mar/13 ]
Hi Michael,
I've made a test with httpcore-nio-4.2.jar and with httpcore-4.2.1.jar and your intuition is good. The httpcore is not the problem because the timeout is still there. With curl the results is back fast, in less then half a second. So the problem must be somewhere in the java SDK in the way the view is retrieved.
Comment by dragos [ 13/Mar/13 ]
I've moved the Couchbase server to the same machine as the client to have all in same environment for testing. Now all is working fine but it is not possible for our product to stay on the same machine as Couchbase server for obvious reasons. In production we will have more then one app machine which we will try to access the Couchbase cluster.
Comment by Michael Nitschinger [ 13/Mar/13 ]
Hi Dragos,

okay so its definitely something with those timeouts.. The thing is we can increase them for sure, but the question is if it would work for your application given the long network latency - and if your application stays performant that way.

When you're running curl on a request, how long does it take?
Comment by dragos [ 14/Mar/13 ]
The curl request is very fast (a few milliseconds, and less then 0.5 seconds i am sure) and the network latency it is not a problem. Some how the couchbase client is taking to much time connecting. When it need to connect to a network machine in the same lan it takes more then 10 seconds. I experimented this in EC2 environment and on my local machine with a VM. If couchbase is local with the test app, the couchbase client is connecting fast.
Do you have any points on how a connection should be setup for couchbase client ? I am trying to use the factory builder and the connection factory from java sdk but still with no success.
Comment by Tim Smith (Inactive) [ 14/Mar/13 ]
Dragos,

I can think of two separate things to try. One is to increase the SO_TIMEOUT to 8000, CONNECTION_TIMEOUT to 12000. Identify what's being hit.

Probably more effective would be to use Wireshark to capture all traffic on the client machine, and see what is really happening. Start the capture (with tshark command-line tool, for example), then run the test client, let it time out, then run the curl command, let it succeed, then stop the capture. Gzip the capture data and attach it to this issue.

Tim
Comment by dragos [ 14/Mar/13 ]
Hi Tim,
I've started some load tests to be able to evaluate Couchbase, so this means i moved Couchbase server on the same machine as the load test client. I tried to use a pool of couchbase clients always connected to the server, and after a while the test failed because couldn't create more connections. From my initial research i seen that couchbase client is managing his own connection can you tell me how this is done or what are the policies of shutting down connections ? Can you point me to some best practices for couchbase client connectivity ?
Comment by Tim Smith (Inactive) [ 14/Mar/13 ]
I will handle that question about connection pooling, etc., separately, since it is unrelated to this bug about timeouts.

On this specific bug report, the current state as I understand it is that: curl returns very quickly with the correct results. The Java client times out after 5 seconds without returning the results.

My suggestion is to set up a very simple Java client that performs a single view query, and to get a packet capture of both curl and the Java client, to identify what the two are doing differently and why the curl succeeds but the Java client fails.
Comment by Jahangir Zinedine [ 27/Mar/13 ]
Hi Michael,

Any update on this issue?
I faced the same issue and here is my environment:
JRuby 1.7.3
Oracle JDK 1.7(with 1.6 the same thing happened)
Couchbase 2.0.1
Java SDK 1.1.3(with 1.1.4 the same thing happened)
And latest netty and http-core and other jar files.

Appreciate your help.

Thanks,
Jani
Comment by dragos [ 01/Apr/13 ]
Hi All,
Finally after a long time i found the workaround needed for the java client to not timeout. As has been suggested by the Couchbase team to use a host name for the Couchabase server i applied the same fix but to the client machine. Meaning on the client machine were the java Couchbase client was timing out ( in Amazon VPC ) we added a hostname for the Couchbase server. Our test URI from http://10.0.7.164:8091/pools has become http://couchbase:8091/pools. This workaround is also fixing a 10 seconds connectivity for the client.

On Ubuntu the hostname file is at: /etc/hosts
On Windows 7 the hostname file is at: C:\Windows\system32\drivers\etc\hosts

Example of host name entry in client machine:
10.0.7.146 couchbase
Comment by Michael Nitschinger [ 02/Apr/13 ]
Thanks very much dragos for tracking this down!

Does this mean that in your environment after the change, you're not seeing any performance impact anymore? Everything works as expected and performant?

Thanks!
Comment by dragos [ 02/Apr/13 ]
Hi Michael,
In this moment the client does not time out and the time taken by java couchbase client to connect takes around 1.5 seconds from 10 seconds which we can consider a normal behavior. As for performance with this workaround we can continue the POC and evaluate the performance. As a first impression i can say that we see a good speed but i will keep my reservation until final POC is tested and we can achieve a full load test.

What i want to emphasize that this is a welcomed workaround but it is not a solution on a longer term for our cloud production site. In a scenario where we need to create new machines and maybe new couchbase clusters it involves manual or specific automatic changes to the hosts file and of course extra managing of this. Bottom line is that we are waiting the fix on the couchbase java sdk 1.1.5 which will make this workaround obsolete.

Also i feel the need to mention that this workaround was found in collaboration with the Couchbase team which provided the basic information for the workaround to be found, so thank you guys.
Comment by Michael Nitschinger [ 02/Apr/13 ]
Hi Dragos,

I'm not sure if there is a thing that we can fix inside the client when this is a DNS/hostname resolution issue with the OS and amazon?

We would definitely need to investigate further, but all that the client does is try to use the hostname/IP provided during bootstrap. If nothing comes back or the host can't be found, we can't do much about it. Anyway, I think we need to do some more investigation here to really see whats the problem.
Comment by aboyev [ 09/Sep/13 ]
Hello, Michael!
I have the same problem. Here is my setup:
- Couchbase 2.1.1
- Java SDK 1.1.9
- Java 1.6.0_27 (and also tried 1.7)
[ERROR] getView | Exception while doing getView: Timed out waiting for operation
[ERROR] Exception while doing getView: I/O reactor has been shut down
It surely has something to do with the client, because when I launch second client it works properly for a while.
Also, it seems to happen under high loads more frequently
Comment by gaurang jhawar [ 24/Oct/13 ]
How did u change the "Meaning on the client machine were the java Couchbase client was timing out ( in Amazon VPC ) we added a hostname for the Couchbase server. Our test URI from http://10.0.7.164:8091/pools has become http://couchbase:8091/pools. This workaround is also fixing a 10 seconds connectivity for the client." in AWS .. I have EC2 instance for which i want to set the hostname and connect through it like you did... Can you tell me the exact steps for that
Comment by Michael Nitschinger [ 25/Oct/13 ]
Hi Gaurang,

are you also exhibiting a delay on connect? Or during operations? I think these two may be related but should be looked at separately and defined. What environment, client, workload and so on are you running?
Comment by gaurang jhawar [ 25/Oct/13 ]
My env is JDK 1.7.0_09
Client is my local machine ...

Couchbase server installed on aws ..

Reconnecting due to failure to connect to {QA sa=172.31.9.124/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
java.net.ConnectException: Connection timed out: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:692)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:423)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:261)
at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:288)
2013-10-24 22:14:01.893 WARN com.couchbase.client.CouchbaseConnection: Closing, and reopening {QA sa=172.31.9.124/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}, attempt 1.
2013-10-24 22:14:05.903 INFO com.couchbase.client.CouchbaseConnection: Reconnecting {QA sa=172.31.9.124/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-10-24 22:14:09.632 INFO com.couchbase.client.ViewConnection: Added 172.31.9.124 to connect queue
Comment by Michael Nitschinger [ 25/Oct/13 ]
One thing to note here is that this is not a good idea. You have "the internet" between your computer (client) and the server which adds latency. Can you try running the application also in an AWS instance and see if the error goes away?
Comment by gaurang jhawar [ 25/Oct/13 ]
I gave the elastic amazon IP in the url and also tried what dragos tried but that also didn`t work for me .. I made ALL TCP ports on firewall ON ... And I am not sure why it reconnects to the IP or fails to connect and load data in the bucket.

But its the same case as dragos ... for production that`s not viable .. since not everything can be on AWS.

Also I can connect to the same instance via telnet and http(browser) .. I don`t know why I am facing this issue with Java 1.7.

"2013-10-24 22:14:01.893 WARN com.couchbase.client.CouchbaseConnection: Closing, and reopening {QA sa=172.31.9.124/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}, attempt 1.
2013-10-24 22:14:05.903 INFO com.couchbase.client.CouchbaseConnection: Reconnecting {QA sa=172.31.9.124/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
2013-10-24 22:14:09.632 INFO com.couchbase.client.ViewConnection: Added 172.31.9.124 to connect queue
2013-10-24 22:14:09.632 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode
in INIT **************.
Here is the entity set : users
2013-10-24 22:14:09.868 WARN com.couchbase.client.CouchbaseConnection: Node expected to receive data is inactive. This could be due to a failure within the cluster. Will check for updated configuration. Key without a configured node is: 0.
30 Seconds: Load is in progress
2013-10-24 22:14:09.993 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2013-10-24 22:14:12.037 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@6dae04e2
2013-10-24 22:14:12.037 INFO com.couchbase.client.CouchbaseConnection: Reconnecting due to failure to connect to {QA sa=172.31.9.124/172.31.9.124:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0}
java.net.ConnectException: Connection timed out: no further information"

NOTE here it tried to reconnect to the client and says its inactive and I am not sure if this is a firewall issue or something else.
Comment by Michael Nitschinger [ 25/Oct/13 ]
Can you provide debug log information for the connect process? Maybe this helps pinning down where the issue is. (you can read here how to do it if you don't know already) :http://nitschinger.at/Logging-with-the-Couchbase-Java-Client

thanks
Comment by gaurang jhawar [ 25/Oct/13 ]
http://s000.tinyupload.com/index.php?file_id=46832814372422198765
Comment by Michael Nitschinger [ 25/Oct/13 ]
Thanks, can you also share the code you use?

In the code it looks like you are creating the CouchbaseClient object twice.
Please note that the bootstrapping succeeds (!) it is different from the ticket reported here.

Are you sure port 11210 is open from client to server? It looks like something is blocking it, http seems to work fine.
Comment by gaurang jhawar [ 25/Oct/13 ]
http://s000.tinyupload.com/index.php?file_id=34200463437173886967



ya the port is opened.

http://s000.tinyupload.com/index.php?file_id=06508245784961590671

Both inbound / outbound on aws as well as my local machine firewall ports are open
Comment by gaurang jhawar [ 26/Oct/13 ]
Any updateS?
Comment by couchbase-user [ 27/Oct/13 ]
This is a nightmare, can't believe no solution has been found yet for over a year now.....
Comment by Michael Nitschinger [ 28/Oct/13 ]
Hi couchbase-user, are you also running app/db over the internet or on a specific ec2 environment?
Comment by couchbase-user [ 28/Oct/13 ]
hey, actually I'm running them all on a local small network.
I am using ubuntu 12.4 on all machines and running java application on headnode to get view data and store them locally.
Comment by Michael Nitschinger [ 28/Oct/13 ]
Hm, I wonder why you are hitting this, I'm not sure its related.. do you get the same exception as the top of the ticket here? Can you provide debug logs so we can see at which point it is happening?

Maybe we need to tweak socket timeouts.
Comment by couchbase-user [ 28/Oct/13 ]
hey, here is my execution log:

28-Oct-2013 09:29:09 com.couchbase.client.CouchbaseProperties setPropertyFile
INFO: Could not load properties file "cbclient.properties" because: File not found with system classloader.
2013-10-28 09:29:09.618 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.0.100:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2013-10-28 09:29:09.620 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.0.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2013-10-28 09:29:09.620 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.0.102:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2013-10-28 09:29:14.635 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@7f09fd93
2013-10-28 09:29:14.635 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@79a5f739
2013-10-28 09:29:14.636 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@68e6ff0d
2013-10-28 09:29:14.656 INFO com.couchbase.client.ViewConnection: Added Cloud-assistant.local to connect queue
2013-10-28 09:29:19.663 INFO com.couchbase.client.ViewConnection: Added 192.168.0.102 to connect queue
2013-10-28 09:29:19.666 INFO com.couchbase.client.ViewConnection: Added 192.168.0.100 to connect queue
2013-10-28 09:29:19.667 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode
2013-10-28 09:29:19.788 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection
2013-10-28 09:29:19.794 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: /192.168.0.102:8092 - Session request successful
2013-10-28 09:29:24.815 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [192.168.0.102/192.168.0.102:8092]
Exception in thread "main" java.lang.RuntimeException: Timed out waiting for operation
    at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:67)
    at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:483)
    at HelloWorld.Export_Couchbase_View(HelloWorld.java:85)
    at HelloWorld.main(HelloWorld.java:287)
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation
    at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:85)
    at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:74)
    at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:64)

I thought this is exactly the same as the error at the top of this thread....
Comment by Michael Nitschinger [ 28/Oct/13 ]
In your logs I can see that 192.168.0.101 is changed to Cloud-assistant.local. Could it be that this is a DNS issue in your environment?
Also please make sure that ports 8091, 8092 (!) and 11210 are reachable on each node.

Both the socket and connection timeout for views are set to 5 second which is already "quite high" if you want to run a real workload over it.
Comment by couchbase-user [ 28/Oct/13 ]
I'm not sure what the DNS has to do with it or how to check it, something to note here is that sometimes it works fine (very rare).
I have also just tried to change the switch but still the same problem.
I'm working on investigating the DNS and firewall issue. thanks
Comment by Michael Nitschinger [ 28/Oct/13 ]
Okay, if you go directly to the view url, how long does it take you to? like with curl... so we can see how far you are over the 5 seconds and if you are under it then there's something else going on.
Comment by couchbase-user [ 28/Oct/13 ]
I have added different servers names to hosts files in all servers and disabled the firewall on all of them and now it seems to work fine.
Thanks a lot for your help Michael.
Comment by Michael Nitschinger [ 28/Oct/13 ]
perfect, good to know it works now.
Comment by gaurang jhawar [ 28/Oct/13 ]
Any updates on my issue Michael Nitschinger. Thanks
Comment by Michael Nitschinger [ 29/Oct/13 ]
Since we fixed the suspected issue with "couchbase-user" in kind of the same way,
ca you first verify that

- All ports are reachable from all the boxes (11210, 8091, 8092)
- DNS settings are configured properly, this is especially important in EC2

If you look through the thread here, some of the people reporting this thing fixed once they made sure their environmental settings were okay. Can you double check?
Comment by gaurang jhawar [ 31/Oct/13 ]
Couchbase-user how did u configure hostname . can u tell me a step by step approach .. dont give me links to couchbase documentation that didn`t help ..

Michael .. the ports are open I am able to ping .. it connects via java and everything but the timeout is quite frequent ..



C:\Users\gaurang\Downloads>tcping 54.219.141.78 8091

Probing 54.219.141.78:8091/tcp - Port is open - time=21.692ms
Probing 54.219.141.78:8091/tcp - Port is open - time=19.357ms
Probing 54.219.141.78:8091/tcp - Port is open - time=15.414ms
Probing 54.219.141.78:8091/tcp - Port is open - time=16.225ms

Ping statistics for 54.219.141.78:8091
     4 probes sent.
     4 successful, 0 failed.
Approximate trip times in milli-seconds:
     Minimum = 15.414ms, Maximum = 21.692ms, Average = 18.172ms

C:\Users\gaurang\Downloads>tcping 54.219.141.78 11210\

Probing 54.219.141.78:11210/tcp - Port is open - time=18.236ms
Probing 54.219.141.78:11210/tcp - Port is open - time=23.513ms
Probing 54.219.141.78:11210/tcp - Port is open - time=1218.881ms
Probing 54.219.141.78:11210/tcp - Port is open - time=14.712ms

Ping statistics for 54.219.141.78:11210
     4 probes sent.
     4 successful, 0 failed.
Approximate trip times in milli-seconds:
     Minimum = 14.712ms, Maximum = 1218.881ms, Average = 318.836ms

Comment by CathodTech [ 13/Dec/13 ]
We have been facing the same issue for couples of months - with Couchbase on RHEL, and we have just found out the solution that works for us.

We have 2 Tomcat nodes running; 1 with Java 1.7 and another with 1.6. Couchbase was deployed on another 4 servers in the same network. We simply defined all Couchbase nodes in /etc/hosts file in both Tomcat nodes as you normally would (with x.x.x.x hostname), then it magically works for us - without having to restart Tomcat, nor Couchbase nodes.
Comment by Michael Nitschinger [ 13/Dec/13 ]
Thanks for pointing this out, I'll see if I can get it into the official docs to aid other people. To me this really looks like java-related and network-related. Interestingly only a few people are hitting it.
Comment by CathodTech [ 14/Dec/13 ]
For the issue I faced, it looks more like Java API related. Perhaps, something to do with DNS (e.g., something like gethostbyname() / gethostbyaddr()), and how the API handles the case when IP has no hostname. Note that we only use IP address to add nodes into Couchbase cluster and Java on other servers also connect to Couchbase with IP address, not hostname.

From the trace, we found that java code has no problem connecting (via connection pool) with Couchbase nodes that has IP/hostname pair in /etc/hosts. But for Couchbase nodes that were not defined in /etc/hosts, it attempted to connect, then the connection dropped, and returned timeout issue.

My team also found that later when he restarted java to re-deploy, Couchbase connection attempts at start-up were much faster (on both Java 1.6 and 1.7).

For this issue, we didn't face it when deploying Java and Couchbase on the same server as, perhaps, it is common to have "127.0.0.1 localhost" defined in /etc/hosts.

We hope that the solution we found would help you and others as well. Not sure if others are facing the same scenario, though.
Comment by David Borsos [ 18/Dec/13 ]
I've ran into a very similar/the same situation with the latest couchbase (2.2.0) server and java client (1.2.3), I thought I share my experiences.

The problem I faced was when trying to call CouchbaseClient.getView(). This apparently goes to one node in the couchbase cluster and queries some view metadata over HTTP (roughly). However I got "ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out" and that pretty much killed my client there. Seeing the solutions here with the hosts file workaround, I tried that and it indeed worked, but it's not really a suitable solution for us, so I decided to see into this a little bit more. Here is what I found.

(Disclaimer: this worked for me, and although I found other ways around this they may not work for you, and I did these attempting to solve this particular issue and didn't really care about anything else these changes may break, so be careful!)

(0) Baseline, the environment specific thing that actually causes the issue is that call java api call InetAddress.getHostFromNameService(InetAddress addr, boolean check) returns very slowly if there's no hostname to be found for a given IP. I have no idea why is that in my environment, I suppose could be because of a bunch of different reasons. Slow here means that it takes 4-5 secs for me for this call to return with an unknown hostname

This comes into the picture when the couchbase client tries to get a view. It uses Apache Http client to do this, and the following things happen:
(1) When the request for the view gets created, eventually we get to BaseIOReactor.execute which instantiates SessionHandle, and registers the time when this happened (this will cause the timeout)
(2) Somewhere in the request processing, we actually DO hit getHostFromNameService. More specifically this happens because a RequestTargetHost interceptor runs and this injects the "Host" header into the HTTP request.
(3) some time after (2) we hit a timeout check which compares the timestamp recorded in (1) and the current time, obviously resulting in a timeout and the error in the client if (2) takes a long time as indicated

The ideal solution would obviously be to fix whatever is wrong with my DNS configs, but I'm not (yet) sure what's wrong (running Ubuntu 13.10 btw). And also make sure that our live environments won't have the same issue...

One workaround I found that might be generally usable is to override the JVM's DNS resolver, by starting the client with: -Dsun.net.spi.nameservice.provider.1=dns,sun This worked for me, but I don't know what side-effects it may have (generally this may not be a great idea). Additionally this resulted in a significant increase of startup speed as the couchbase client seems to do a lot of ip->hostname lookups when it's starting (are these really necessary?)

Also I'd like to ask from the Couchbase folks if it's really necessary to do this reverse DNS lookup for every HTTP request. I cloned your client from git, and removed the RequestTargetHost interceptor from these calls; that also solved the timeout problem, and all seems to work fine. I didn't do exhaustive testing on it, and this, too, can be environment specific - running my couchbase cluster in local VMs at the moment.

Thanks.
Comment by Michael Nitschinger [ 19/Dec/13 ]
Hi David,

thanks for the heads-up, that gives me a better idea of whats going on. I basically revamped the whole view connection management for the next 1.3 release which hopefully should address this to. Would you want to try it out based on a preliminary build?

The thing is that you can't remove the RequestTargetHost, but it only does the DNS lookup if HTTP.TARGET_HOST is not set, but we can infer that from our configuration. So the new code basically sets it before the request is put in the queue, once we've determined which node to ask, then it should be skipped.

I already have that locally, so if you want to try it out we can quickly see if it fixes the issue.
Comment by Michael Nitschinger [ 19/Dec/13 ]
The issue will be fixed with the overall changeset of jcbc-388, which will appear in - as it stands now - 1.3, slated for jan 2014.
Comment by David Borsos [ 19/Dec/13 ]
Michael,

That sounds great. I'd be happy to help you verify your new code; send it over or let me know how can I get it, I'll switch to it and see if it solves the problem. If we can get the new version in early January (I saw it's scheduled for the 7th) that's cool too, we won't be doing much during the holidays anyway :)

Thanks
Comment by Sergii [ 19/Dec/13 ]
Hi Michael,

i have run into the same issue with couchbase 2.2 on mac - Java 1.7

Can i have the changed jar to try the fix?

Thanks
Comment by Michael Nitschinger [ 31/Dec/13 ]
A fix for this has been merged into master and will be available in the next (1.3.0) release.
Comment by Michael Nitschinger [ 31/Dec/13 ]
The new code minimizes dns lookups to workaround the issue, but the environment still needs to be fixed properly :)




[JCBC-395] Specify specific generated version in headers Created: 31/Dec/13  Updated: 31/Dec/13

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

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


 Description   
Currently we hardcode the user client string in http requests, this can be made better and more specific, based on a generated class file and constants.




Documentation for Java 1.3 (JCBC-391)

[JCBC-392] Create documentation files for Java 1.3 Created: 19/Dec/13  Updated: 23/Dec/13  Resolved: 23/Dec/13

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

Type: Technical task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h


 Comments   
Comment by Amy Kurtzman [ 23/Dec/13 ]
The new files are available in the GitHub documentation repo in a branch named java-1.3, located at https://github.com/couchbaselabs/docs-ng/tree/java-1.3/content/couchbase-sdk-java-1.3.




[JCBC-370] Edit Java 1.2 guide Created: 15/Oct/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.2, 1.2.1
Fix Version/s: .next
Security Level: Public

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Edit the current version of the Java SDK guide.

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
Amy, is this still relevant? What are the open tasks here?
Comment by Amy Kurtzman [ 19/Dec/13 ]
This is done now.




[JCBC-228] a no-args constructor and an init method are needed Created: 31/Jan/13  Updated: 19/Dec/13

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

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


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

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Assigning towards 1.1.2 but we can defer it to 1.1.3 as well.
Comment by Michael Nitschinger [ 19/Dec/13 ]
We'll have something like this in 2.0




[JCBC-65] Client constructor blocks or deadlocks Created: 14/Jun/12  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: Martin Scott Assignee: Michael Nitschinger
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: OS: Windows 7 64bit
JDK: 1.6.0_31 also 1.6.0_33 64 bit
Couchbase enterprise edition running on 3 nodes all Ubuntu 10.04 64bit server (VMware images)

Attachments: Text File log.txt    

 Description   
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?

 Comments   
Comment by Raghavan Srinivas (Inactive) [ 14/Jun/12 ]
Thanks for giving the Java client library a spin.

Were you able to connect to a single windows 7 node? I suspect it might be a firewall/networking issue and if you can use the netstat command (or the appropriate command on windows 7)?

You may also want to follow the instructions noted in

http://www.couchbase.com/docs/couchbase-manual-1.8/couchbase-bestpractice-cloud.html

Changing IP addresses might be a cause for this.

Finally, a more detailed log would be useful, if the network troubleshooting does not help.

Please refer to

http://www.couchbase.com/wiki/display/couchbase/Couchbase+Java+Client+Library

for logging tips.
Comment by Martin Scott [ 14/Jun/12 ]
Apologies that should read

Couchbase Version: 1.8.0 enterprise edition (build-55)
Comment by Martin Scott [ 14/Jun/12 ]
Detailed logging up to the point when the client hangs
Comment by Raghavan Srinivas (Inactive) [ 14/Jun/12 ]
Thanks for the Log. I took a real quick look.

Were you able to follow the steps in

http://www.couchbase.com/docs/couchbase-manual-1.8/couchbase-bestpractice-cloud.html

and use the ip address that you are able to connect to (via the admin console)?
Comment by Alex Ma [ 14/Jun/12 ]
Hi Martin,

Can you verify connectivity from the JDK on your windows box?

This is what my connection code looks like:
// Connection details for Couchbase
List<URI> uris = new LinkedList<URI>();
uris.add(URI.create("http://10.4.2.3:8091/pools"));

CouchbaseClient client = null;
try {
client = new CouchbaseClient(uris, "default", "");
}
catch (Exception e) {
System.err.println("except: connect: " + e.getMessage());
System.exit(-1);
}


This will create a persistent connection to 8091 on 10.4.2.3 as well as connections to 11210 on every node in the cluster.

ssh'ing to 10.4.2.3 and running netstat - you should see something like whats below:


netstat -nat|grep 10.32.3.50
tcp 0 0 10.4.2.3:11210 10.32.3.50:65437 ESTABLISHED
tcp 0 0 10.4.2.3:8091 10.32.3.50:65442 ESTABLISHED
tcp 0 304 ::ffff:10.4.2.3:22 ::ffff:10.32.3.50:65516 ESTABLISHED


can you confirm this in your environment?

thanks

-Alex.
Comment by Martin Scott [ 18/Jun/12 ]
Hi, thanks for the responses.

Here is the netstat output from my Windows client

  TCP 192.168.186.1:139 0.0.0.0:0 LISTENING InHost
  TCP 192.168.186.1:51008 192.168.186.150:22 ESTABLISHED InHost
  TCP 192.168.186.1:53281 192.168.186.150:8091 TIME_WAIT InHost
  TCP 192.168.186.1:53284 192.168.186.150:11210 ESTABLISHED InHost
  TCP 192.168.186.1:53285 192.168.186.151:11210 ESTABLISHED InHost
  TCP 192.168.186.1:53286 192.168.186.152:11210 ESTABLISHED InHost
  TCP 192.168.186.1:53292 192.168.186.150:8091 ESTABLISHED InHost

and from the first node in the cluster with the client and other nodes.

tcp 0 0 192.168.186.150:41317 192.168.186.150:11210 ESTABLISHED
tcp 0 0 192.168.186.150:35883 192.168.186.151:11210 ESTABLISHED
tcp 0 0 192.168.186.150:11210 192.168.186.151:38013 ESTABLISHED
tcp 0 0 192.168.186.150:21100 192.168.186.152:46834 ESTABLISHED
tcp 0 0 192.168.186.150:11210 192.168.186.1:53284 ESTABLISHED
tcp 0 0 192.168.186.150:57559 192.168.186.151:22 TIME_WAIT
tcp 0 0 192.168.186.150:8091 192.168.186.1:53292 ESTABLISHED
tcp 0 48 192.168.186.150:22 192.168.186.1:51008 ESTABLISHED
tcp 0 0 192.168.186.150:11210 192.168.186.150:41317 ESTABLISHED
tcp 0 0 192.168.186.150:42433 192.168.186.152:11210 ESTABLISHED
tcp 0 0 192.168.186.150:11210 192.168.186.150:56214 ESTABLISHED
tcp 0 0 192.168.186.150:56214 192.168.186.150:11210 ESTABLISHED
tcp 0 0 192.168.186.150:11210 192.168.186.152:39222 ESTABLISHED
tcp 0 0 192.168.186.150:21100 192.168.186.151:60945 ESTABLISHED


I downloaded the source jars from the maven repo and debugging shows the client hanging at the getLatch().await() line below. There doesn't appear to be any thread calling the countDown method on the latch before or after this is called.

  private ChannelFuture getReceivedFuture() {
    try {
      getLatch().await();
    } catch (InterruptedException ex) {
      finerLog("Getting received future has been interrupted.");
    }
    return receivedFuture;
  }


Martin.
Comment by Martin Scott [ 18/Jun/12 ]
The stack trace where the client blocks

Thread [main] (Stepping)
BucketUpdateResponseHandler.getReceivedFuture() line: 147
BucketUpdateResponseHandler.getLastResponse() line: 127
BucketMonitor.startMonitor() line: 183
ConfigurationProviderHTTP.subscribe(String, Reconfigurable) line: 243
CouchbaseClient.<init>(CouchbaseConnectionFactory, boolean) line: 158
CouchbaseClient.<init>(CouchbaseConnectionFactory) line: 125
CouchbaseClient.<init>(List<URI>, String, String) line: 77
Main.main(String[]) line: 67

Comment by sean diamond [ 23/Jan/13 ]
I am having this exact same problem. Using windows 7 64 bit trying to connect to ubuntu.
I am using 32 bit os on linux and couchbase server 2.0.

I am also using the lastest java client version 1.1

Same Issue as described below.
The only workaround is to not use windows, if my java client is running on linux then it will work with no issues, it just deadlocks on the windows machine.
Comment by Tug Grall (Inactive) [ 17/Apr/13 ]
I am reopening the issue as we see this error again on some environment:
- Yuval
- http://www.couchbase.com/issues/browse/JCBC-65
...

Let me know if you prefer me to create a new issue for 1.1.x
Comment by Michael Nitschinger [ 29/May/13 ]
getting it onto the bugfix release train, altough I'm not sure if we get it into 1.1.7
Comment by Michael Nitschinger [ 19/Dec/13 ]
We haven't seen this again in a long time.. also we fixed issues along the way and have more in the 1.3 upcoming..

for anyone stumbling upon this when running 1.2* or 1.3*, please reopen a new issue with more context.. thanks!




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

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

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


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

Stack Trace :

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

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




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

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

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


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

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

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

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

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

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

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

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

Let me know if you can reproduce the bug.

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

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

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

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

Jave Version:

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

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




[JCBC-221] XDCR observe - java client Created: 28/Jan/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: Alex Ma Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Couchbase Server 2.0 GA with XDCR either across datacenters or AWS Regions

Issue Links:
Dependency
depends on MB-7614 XDCR: Provide Observe with XDCR Open

 Description   
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.

 Comments   
Comment by Dipti Borkar [ 28/Jan/13 ]
This needs additional internal discussion first.
Comment by Matt Ingenthron [ 28/Jan/13 ]
We also need some semblance of what kind of throughput and response times are reasonable. There are currently some architectural limitations that mean remote replication will take potentially quite a while. I'd be reticent to implement this without knowing if the end result is useable.
Comment by Michael Nitschinger [ 19/Dec/13 ]
This is not in scope since the client is one-bucket only.. Also, semantics change a lot over xdcr. This would be a much larger project in scope.




[JCBC-329] Add new junit tests in the view connection and query tests Created: 10/Jul/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: Deepti Dawar Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency

 Description   
Add new junit tests in the view connection and query tests.
More negative cases for View connection tests.
Also improve view query tests as per the test plan.

 Comments   
Comment by Deepti Dawar [ 15/Jul/13 ]
http://review.couchbase.org/#/c/27386/
Comment by Deepti Dawar [ 21/Aug/13 ]
Mark, Please advice, do we have to write mock code which fails to connect to the View Node ?
Otherwise we cannot get the node failure every time we test.
Comment by Michael Nitschinger [ 19/Dec/13 ]
With 1.3 upcoming the view connection has been revamped and tests added, so this is not needed anymore. Let's open specific tickets if we need more coverage on the new one.




[JCBC-387] Getting Started guide first example is missing try/catch around CouchbaseClient.get() Created: 04/Dec/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: Dave Rigby Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: JDK 1.7 OS X Mavericks


 Description   
When following the hello example in the getting started guide [1] I found a syntax error in the get() call. The code is missing a try/catch block for InterruptedException, ExecutionException when running with JDK 1.7:

Exception in thread "main" java.lang.Error: Unresolved compilation problems:
Unhandled exception type InterruptedException
Unhandled exception type ExecutionException

at App.main(App.java:23)

code fragment:

    // Try to connect to the client
    CouchbaseClient client = null;
    try {
      client = new CouchbaseClient(nodes, "beer-sample", "");
    } catch (Exception e) {
      System.err.println("Error connecting to Couchbase: " + e.getMessage());
      System.exit(1);
    }

    client.set("hello", "couchbase!").get(); // <----- HERE


[1] http://docs.couchbase.com/couchbase-sdk-java-1.2/#hello-couchbase

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
Thanks, will be fixed in the next few days when the PR is merged.




[JCBC-382] Feature suggestion-Bucket does not get created programmatically Created: 21/Nov/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

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


 Description   
A suitable feature to add would be the provision to create a bucket programmatically. A bucket has to be created in the Console, which is a digression if a lot of different buckets are required to be created.

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
You can already do that through the ClusterManager which is part of com.couchbase.client




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

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

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


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

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

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




[JCBC-367] Remove the API reference from the current 1.3 manual, maybe Created: 08/Oct/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

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

Attachments: PDF File couchbase-sdk-java-1.2.pdf    

 Description   
Was reviewing with Amy and in the translation from the old docs system to the new one we have a number of "couldn't resolve xref tag".

How shall we handle this. Should we remove the method summary and the operations sections, or ....? This should probably be the API ref.

 Comments   
Comment by Amy Kurtzman [ 08/Oct/13 ]
You can see the first instance of the problem in the Java Method Summary section.

I've attached a copy of the Java 1.2 SDK from the old documentation system so you can see the way it used to look.
Comment by Amy Kurtzman [ 15/Oct/13 ]
It's a problem in the 1.0 and 1.1 documentation also.
Comment by Michael Nitschinger [ 19/Dec/13 ]
has been removed from the docs, 1.3 docs will get a better manual. we still have javadocs of course.




[JCBC-372] ReplicaRead can cause Huge Heap/StackOverflowException. Created: 28/Oct/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

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


 Description   
Under specific scenarios, ReplicaReads can cause "inifinte" redispatch and therefore either overflow on the stack or cause huge heaps (created by large callbacks as a result).

 Comments   
Comment by Michael Nitschinger [ 19/Dec/13 ]
This has been fixed in the 12.3 and 1.2.2 series.




[JCBC-389] Make PersistTo/ReplicateTo really async and not block Created: 16/Dec/13  Updated: 16/Dec/13  Resolved: 16/Dec/13

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

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

Issue Links:
Duplicate
duplicates JCBC-361 Add capability of async+durability wi... Resolved
is duplicated by JCBC-361 Add capability of async+durability wi... Resolved

 Comments   
Comment by Michael Nitschinger [ 16/Dec/13 ]
See JCBC-361




[JCBC-315] Handle retrying with backoff on all nodes in view operations Created: 07/Jun/13  Updated: 16/Dec/13  Resolved: 16/Dec/13

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

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


 Description   
While handling the response of the view operations, the server returns the http error codes which have been interpreted at the client and the retry mechanism has been added as part of 1.1.7 release.
Now we also need to implement the backoff.

 Comments   
Comment by Michael Nitschinger [ 16/Dec/13 ]
Currently there is no backoff planned for views, operations are redistributed to other nodes if appropriate.




[JCBC-138] Java Client does not recover when only bootstrap node provided and failovered Created: 05/Nov/12  Updated: 16/Dec/13  Resolved: 16/Dec/13

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

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

Issue Links:
Dependency
blocks JCBC-308 Trouble in resubscribing to primary n... Closed
blocks JCBC-344 allow for setting bootstrap nodes via... Resolved

 Description   
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.

 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
This is how it will work in the 1.1 series. if we decide for changes in the 1.2 branch (CCCP), then this will change as well. For now wont fix.
Comment by Michael Nitschinger [ 04/Sep/13 ]
http://review.couchbase.com/#/c/28785/




[JCBC-376] Bring Views over to Netty Created: 07/Nov/13  Updated: 16/Dec/13  Resolved: 16/Dec/13

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

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


 Description   
This is currently in "poc" stage and will contain a series of commits that try to bring over views from apache http core to netty. This has a number of benefits aside from simplified architecture and reduced dependencies.

 Comments   
Comment by Michael Nitschinger [ 16/Dec/13 ]
This will be done for 2.0 as part of merging the complete IO layer.




[JCBC-324] Avoid NPE when Host is Up, but no CB is running Created: 02/Jul/13  Updated: 16/Dec/13  Resolved: 16/Dec/13

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

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

Issue Links:
Duplicate
is duplicated by JCBC-321 Null Pointer in client when deleting ... Closed
is duplicated by JCBC-379 If bucket details are incorrect, erro... Closed

 Description   
When the target host is reachable, but no server is running, the client throws a unhelpful NPE:

Caused by: java.lang.NullPointerException
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:148)
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:231)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:237)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:175)

The logs also show more infos, but this NPE is not helpful in the stack.

 Comments   
Comment by Brad Wood [ 02/Jul/13 ]
Additional info here:
http://www.couchbase.com/communities/q-and-a/sdk-throws-unhelpful-npe-when-server-unreachable
Comment by Michael Nitschinger [ 18/Nov/13 ]
Brad, are you sure this is not fixed with recent releases?

I tried
 - not running node
 - running node with wrong bucket name
 - running node with wrong password

and I always get com.couchbase.client.vbucket.ConfigurationExceptions and not NPEs anymore... this is with vanilla 1.2.2 but I remeber fixing it earlier.

If you still see it, can you get me more information on the environment?




[JCBC-229] Find a way to proper test JCBC-227 Created: 01/Feb/13  Updated: 09/Dec/13

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

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

Issue Links:
Dependency

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

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




[JCBC-380] alternate bootstraps have a hardcoded port 8091 Created: 15/Nov/13  Updated: 28/Nov/13  Resolved: 28/Nov/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.9, 1.2, 1.2.1, 1.2.2
Fix Version/s: 1.2.3
Security Level: Public

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


 Description   
Since it is possible, though not easy, to make Couchbase run on a port other than 8091, the hostnames extracted from the configuration can't necessarily be on port 8091. The initial bootstrap port number should be applied to all of these derived URIs.

 Comments   
Comment by Michael Nitschinger [ 16/Nov/13 ]
Two things here

- IMHO this is an enhancement, since its a new requirement to run against != 8091
- Not sure if we can grab it from the initial list because things can change, picking it up from the new config may be better - hope the server supplies it correctly.
Comment by Michael Nitschinger [ 16/Nov/13 ]
Is there a way to change the ports to test it?
Comment by Michael Nitschinger [ 18/Nov/13 ]
http://review.couchbase.org/#/c/30372/




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

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

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


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

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

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

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

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




[JCBC-383] Some org.springframework.data.repository.CrudRepository methods throw Exception Created: 24/Nov/13  Updated: 26/Nov/13  Resolved: 25/Nov/13

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

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


 Description   
The following methods in the org.springframework.data.repository.CrudRepository<T,ID extends Serializable> interface throw and exception.
deleteAll()
count()
findAll()
findAll(Iterable<ID> ids)

The exception is:

Exception in thread "main" org.springframework.dao.InvalidDataAccessResourceUsageException: Could not load view

"all" for design doc "catalog"; nested exception is com.couchbase.client.protocol.views.InvalidViewException: Could

not load view "all" for design doc "catalog"
at org.springframework.data.couchbase.core.CouchbaseExceptionTranslator.translateExceptionIfPossible

(CouchbaseExceptionTranslator.java:69)
at org.springframework.data.couchbase.core.CouchbaseTemplate.execute(CouchbaseTemplate.java:236)
at org.springframework.data.couchbase.core.CouchbaseTemplate.queryView(CouchbaseTemplate.java:192)
at org.springframework.data.couchbase.repository.support.SimpleCouchbaseRepository.deleteAll

(SimpleCouchbaseRepository.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.springframework.data.repository.core.support.RepositoryFactorySupport

$QueryExecutorMethodInterceptor.executeMethodOn(RepositoryFactorySupport.java:344)
at org.springframework.data.repository.core.support.RepositoryFactorySupport

$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:329)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.data.couchbase.repository.support.ViewPostProcessor$ViewInterceptor.invoke

(ViewPostProcessor.java:80)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke

(ExposeInvocationInterceptor.java:91)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy13.deleteAll(Unknown Source)
at service.CatalogService.main(CatalogService.java:77)


 Comments   
Comment by deepak vohra [ 24/Nov/13 ]
The design doc "catalog" is a variable.
Comment by Michael Nitschinger [ 25/Nov/13 ]
hi,

please in the future open spring tickets here: https://jira.springsource.org/browse/DATACOUCH

also, you need a design document with the name "catalog" and a view with the name "all". That returns a list of IDs for the subset of documents. It needs to be published to production, not in dev mode.
Comment by deepak vohra [ 25/Nov/13 ]
The default "production" is used. The requirement for a design document and a view is not mentioned in the Spring Data git page.
https://github.com/spring-projects/spring-data-couchbase

Why do the other methods not generate an exception if the design document and view are required?
Comment by deepak vohra [ 25/Nov/13 ]
May have closed the issue too early. A requirement for a view or design document is not mentioned in GIT nor on the Repositories documentation.

http://docs.spring.io/spring-data/data-jpa/docs/current/reference/html/repositories.html
Comment by deepak vohra [ 25/Nov/13 ]
Added the "catalog" design document and the "all" view and still getting the exception. The Console with the "all" view is listed.
http://i763.photobucket.com/albums/xx277/dvohra10/all_view_zps11dc43cc.jpg
http://i763.photobucket.com/albums/xx277/dvohra10/all_view1_zps1a05fdac.jpg
Comment by deepak vohra [ 25/Nov/13 ]
A reduce function was also required in the "all" view.

http://i763.photobucket.com/albums/xx277/dvohra10/all_view2_zps86018401.jpg

Thanks for your feedback. The exception is fixed if an "all" view is added with a map function and a reduce function.
 Issue may be considered Closed.
Comment by Michael Nitschinger [ 26/Nov/13 ]
HI,

yeah that's right.. sorry the docs for that are not up to date.. I'll also plan to add the requred function directly in the exception so you can copy/paste.




[JCBC-381] Error: notfound (Document does not exist) Created: 20/Nov/13  Updated: 21/Nov/13  Resolved: 21/Nov/13

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

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


 Description   
If a JSON document is added to the default bucket error Error: notfound (Document does not exist) gets generated.

Couchbase-Java-Client-1.2.2

 Comments   
Comment by Michael Nitschinger [ 20/Nov/13 ]
This is a bit vague.

Can you please share the code snippet that is causing your error alongside with the complete error description?
Thanks
Comment by deepak vohra [ 21/Nov/13 ]
Without the exception handling:

public String VALUE =
          "{\"journal\":\"Oracle Magazine\"," +
               "\"publisher\":\"Oracle Publishing\"," +
               "\"edition\":\"May June 2012\"," +
               "\"title\":\"A\"," +
               "\"author\":\"B\",}";

List<URI> uris = new LinkedList<URI>();
uris.add(URI.create("http://192.168.1.71:8091/pools"));
CouchbaseClient client = new CouchbaseClient(uris, "default", "");
OperationFuture<Boolean> setOp = client.set("catalog", 10, VALUE);


If another bucket is used the error is not generated.
Comment by Michael Nitschinger [ 21/Nov/13 ]
can you please also add the logs?
Comment by deepak vohra [ 21/Nov/13 ]
An error log is not generated, but in the Console when the "catalog" Id document is selected the following error message is displayed.
http://s763.photobucket.com/user/dvohra10/media/Image50_zpse7e02c1c.jpg.html?filters[user]=137762904&filters[recent]=1&sort=1&o=0
Comment by deepak vohra [ 21/Nov/13 ]
The image link did not get added. The following is the image link.
http://i763.photobucket.com/albums/xx277/dvohra10/Image50_zpse7e02c1c.jpg
Comment by deepak vohra [ 21/Nov/13 ]
A document id for "catalog" document gets added to the default bucket.
http://i763.photobucket.com/albums/xx277/dvohra10/Image52_zps7be39b3b.jpg

But when the catalog id is clicked the error message gets displayed.
Comment by Michael Nitschinger [ 21/Nov/13 ]
In your set code, that 10'means it will be gone after 10 seconds! Set to 0 to let it live forever
Comment by deepak vohra [ 21/Nov/13 ]
Thanks. The document stays stored with the following setting.

OperationFuture<Boolean> setOp = client.set("catalog", 0, VALUE);




[JCBC-378] Upload autodocs for Java 1.2.2 Created: 13/Nov/13  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

Type: Task Priority: Major
Reporter: Amy Kurtzman Assignee: Amy Kurtzman
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-321] Null Pointer in client when deleting bucket via UI Created: 24/Jun/13  Updated: 18/Nov/13  Resolved: 18/Nov/13

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

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

Issue Links:
Duplicate
duplicates JCBC-324 Avoid NPE when Host is Up, but no CB ... Resolved

 Description   
un 24 09:12:19: WARNING: Connection problems with URI http://localhost:8091/pools ...skipping
Jun 24 09:12:19: java.io.IOException: Server returned HTTP response code: 401 for URL: http://localhost:8091/pools
Jun 24 09:12:19: at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1615)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:318)
Jun 24 09:12:19: at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:406)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
Jun 24 09:12:19: at java.lang.Thread.run(Thread.java:722)
Jun 24 09:12:19: Jun 24, 2013 9:12:19 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run
Jun 24 09:12:19: WARNING: Resubscribe attempt failed:
Jun 24 09:12:19: java.lang.NullPointerException
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:148)
Jun 24 09:12:19: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:318)
Jun 24 09:12:19: at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:406)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
Jun 24 09:12:19: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
Jun 24 09:12:19: at java.lang.Thread.run(Thread.java:722)

 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
This is halfway expected, but the NPE is not. there is some other ticket tracking the same path, I'll link them as soon as I find the other.




[JCBC-379] If bucket details are incorrect, error message is unhelpful Created: 15/Nov/13  Updated: 18/Nov/13  Resolved: 18/Nov/13

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

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

Issue Links:
Duplicate
duplicates JCBC-324 Avoid NPE when Host is Up, but no CB ... Resolved

 Description   
If an incorrect bucket name or password is specified when connection (which is easier since bucket names are case-sensitive) the following error is thrown:
{code]
Caused by: java.lang.NullPointerException
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:148)
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:231)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:237)
... 167 more
{code]

There should be additional checks in place to help guide the developer to fix the issue.

 Comments   
Comment by Brad Wood [ 15/Nov/13 ]
Darn, you guys don't have wiki markup enabled. You should do that, it's very handy for prettying up ticket descriptions.

Argh-- I can't edit my own ticket either to remove the {code} blocks :(
Comment by Brad Wood [ 15/Nov/13 ]
I didn't specify the affects version and since I can't edit it, I'll put it here. I'm on couchbase-client-1.1.7.jar. Hmm, I think there's a new version I should try to see if this is fixed.
Comment by Brad Wood [ 15/Nov/13 ]
Ok, just upgraded to couchbase-client-1.2.2.jar and the error message is the same, so this does affect the latest version.




[JCBC-263] memcached connection fails with "Attempting to overwrite channel" Created: 11/Mar/13  Updated: 18/Nov/13  Resolved: 18/Nov/13

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

Type: Bug Priority: Major
Reporter: Mark Nunberg Assignee: Mark Nunberg
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: This is a "run of the mill" memcached instance. I have not particularly been able to reproduce it though - nevertheless I am placing it in here so that it may be noted.

Server version is 2.0.0


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


 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
Hey Mark,

i just stumbled across this ticket. Did you try to connect with a CouchbaseClient against a vanilla memcached instance? That wont work obviously.
Comment by Michael Nitschinger [ 18/Nov/13 ]
Never seen this again, closing for now.




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

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

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


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

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




[JCBC-375] Resubscriber giving illegal argument exception Created: 31/Oct/13  Updated: 05/Nov/13  Resolved: 05/Nov/13

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

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


 Description   
Please check the job -
http://sdkbuilds.couchbase.com/job/sdkd-java-exec/72/console

and find the error as below -

[SDKD(WARNING) 185.27 cbsdk.sdkd.local executor.py:66] WARNING: Resubscribe attempt failed:
[SDKD(WARNING) 185.27 cbsdk.sdkd.local executor.py:66] java.lang.IllegalArgumentException: Reconfigurable cannot be null and must never be re-set to a new object
[SDKD(WARNING) 185.27 cbsdk.sdkd.local executor.py:66] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:316)
[SDKD(WARNING) 185.27 cbsdk.sdkd.local executor.py:66] at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:456)
[SDKD(WARNING) 185.28 cbsdk.sdkd.local executor.py:66] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[SDKD(WARNING) 185.28 cbsdk.sdkd.local executor.py:66] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[SDKD(WARNING) 185.28 cbsdk.sdkd.local executor.py:66] at java.lang.Thread.run(Thread.java:722)
[SDKD(WARNING) 185.28 cbsdk.sdkd.local executor.py:66]
[SDKD(WARNING) 185.28 cbsdk.sdkd.local executor.py:66] Oct 31, 2013 10:11:33 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run
[SDKD(WARNING) 185.28 cbsdk.sdkd.local executor.py:66] INFO: Reconnect attempt 16, waiting 10,000ms




[JCBC-250] ClassCast Exception when using durability against memcached bucket Created: 20/Feb/13  Updated: 05/Nov/13  Resolved: 18/Jul/13

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

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

Attachments: Text File 1.1.5-sdk.log     Text File 1.1.6-sdk.log    

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

 Comments   
Comment by Deepti Dawar [ 14/May/13 ]
This problem has been fixed in the version 1.1.6. It was there till 1.1.5 but now has been fixed.

Please find the same log of run in 1.1.5 and 1.1.6 to strengthen the findings.

Its good to close.

Thanks !
Comment by Michael Nitschinger [ 27/May/13 ]
This is not fixed. Will make sure to fix it for 1.1.7
Comment by Michael Nitschinger [ 27/May/13 ]
Deepti, for simple cases like this, SDKQE is overkill.

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

    client.set("foo", "bar", PersistTo.MASTER);
    
    client.shutdown();

this shows the problem against a memcache bucket.
Comment by Michael Nitschinger [ 27/May/13 ]
http://review.couchbase.com/#/c/26541/
Comment by Michael Nitschinger [ 18/Jul/13 ]
woops, this has been fixed some time ago already.
Comment by Karthik PV [ 05/Nov/13 ]
Hi. I am still getting the same issue with Version 2.1. Interestingly, this does not happen with 2.2
Comment by Michael Nitschinger [ 05/Nov/13 ]
Hm, I'm not sure to which versions you relate to, because thats not dependend on the server.

Can you share the exception? and the couchbase java client version you are using?
Comment by Karthik PV [ 05/Nov/13 ]
HI Michael. We are using 1.1.6 java client. Still it works with 2.2 and not with 2.1?
Comment by Michael Nitschinger [ 05/Nov/13 ]
No, this should not be the problem here, something else is going on.

You need to upgrade to 1.1.7 to have this fixed!

Although I'd recommend you to go straight to 1.2.2. which will be released this week.
Comment by Karthik PV [ 05/Nov/13 ]
What's the latest stable version? Have a Go-Live this week and this is a potential SHOW-Stopper :)
Comment by Michael Nitschinger [ 05/Nov/13 ]
as of now the latest stable is 1.2.1, but we'll release 1.2.2 this week.

If you just want to fix this one issue go to 1.1.7 ;)
Comment by Karthik PV [ 05/Nov/13 ]
Thanks a lot Michael for the help and the super-quick response!




[JCBC-373] ReplicaGetFuture is not thread safe. Created: 28/Oct/13  Updated: 31/Oct/13  Resolved: 31/Oct/13

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: 1.1.8, 1.1.9, 1.2, 1.2.1
Fix Version/s: 1.2.2
Security Level: Public

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





[JCBC-374] Active replica get future is not completed properly Created: 30/Oct/13  Updated: 31/Oct/13  Resolved: 31/Oct/13

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

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





[JCBC-369] observePoll has wrong logic on delete Created: 15/Oct/13  Updated: 31/Oct/13  Resolved: 31/Oct/13

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

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





[JCBC-368] Deadlock in BucketMonitor.startMonitor() on CountDownLatch when channel creation fails. Created: 14/Oct/13  Updated: 24/Oct/13  Resolved: 24/Oct/13

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.9, 1.2
Fix Version/s: 1.2.2
Security Level: Public

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

Issue Links:
Duplicate
is duplicated by JCBC-326 Couchbase client stuck indefinitely i... Resolved

 Description   
Deadlock in BucketMonitor.startMonitor() on CountDownLatch when channel creation fails.

Before deadlocking it also logs following exception (which by itself is another bug):

java.lang.IllegalStateException: An Executor cannot be shut down from the thread acquired from itself. Please make sure you are not calling releaseExternalResources() from an I/O worker thread.
at org.jboss.netty.util.internal.ExecutorUtil.terminate(ExecutorUtil.java:73)
at org.jboss.netty.util.internal.ExecutorUtil.terminate(ExecutorUtil.java:49)
at org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.releaseExternalResources(NioClientSocketChannelFactory.java:180)
at org.jboss.netty.bootstrap.Bootstrap.releaseExternalResources(Bootstrap.java:319)
at com.couchbase.client.vbucket.BucketMonitor$1.operationComplete(BucketMonitor.java:193)
at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:428)
at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:419)
at org.jboss.netty.channel.DefaultChannelFuture.setFailure(DefaultChannelFuture.java:381)
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.processConnectTimeout(NioClientSocketPipelineSink.java:394)
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink$Boss.run(NioClientSocketPipelineSink.java:289)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)



 Comments   
Comment by Michael Nitschinger [ 14/Oct/13 ]
Hi, Thanks for reporting.

can you give me more details about your env? Particulary, which sdk version do you run and on which platform/os?
Comment by Deniss Afonin [ 14/Oct/13 ]
Yeah, sorry for missing that. Here it is:

couchbase-client-1.2.0

running with

java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

on OS X 10.8.5
Comment by Michael Nitschinger [ 14/Oct/13 ]
I see what's going on there, but I'd like to add a test to reproduce. How are you running into this?
Comment by Deniss Afonin [ 14/Oct/13 ]
I can't always reproduce that, this happens from time to time.
Comment by Michael Nitschinger [ 14/Oct/13 ]
I see, thanks for reporting it. Look forward to a proper fix in the next bugfix release.
Comment by Michael Nitschinger [ 14/Oct/13 ]
I think I fixed it, but in any case something went wrong during connection to the streaming connection.

Does the error is expected to happen in your environment or was it considered stable? I wonder in which circumstances you saw that. Even with my fix, its just shutting down properly but still the streaming conn attachment won't succeed.
Comment by Deniss Afonin [ 14/Oct/13 ]
Well, this happens for us only when couchbase server is not in local network i.e. we are connecting via internet with ~100ms latency and that internet connection might not be that stable.

Issue JCBC-326 might also be related to this.
Comment by Michael Nitschinger [ 14/Oct/13 ]
Yes that's what I assumed. So the thing is, in general we don't recommend running your app servers and db servers across the internet (they should be in the same datacenter, especially if you care about latency).

But this shouldn't be a limitation of the client itself. So I have a bugfix for this upcoming, but I'll also see what I can do to add some more retry logic to try different nodes from the list so if one fails we eventually connect to another one.
Comment by Michael Nitschinger [ 24/Oct/13 ]
fix has been merged into master and will be available in 1.2.2.




[JCBC-371] Remove redundant bucket reference Created: 23/Oct/13  Updated: 24/Oct/13  Resolved: 24/Oct/13

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

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





[JCBC-363] Add intro to Java SDK guides Created: 24/Sep/13  Updated: 15/Oct/13  Resolved: 01/Oct/13

Status: Closed
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.0, 1.1.0, 1.2
Fix Version/s: 1.0, 1.1.0, 1.2
Security Level: Public

Type: Task Priority: Minor
Reporter: Amy Kurtzman Assignee: Gwen Leong
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The SDK guides currently begin with the Getting Started section. They need an introduction and meaningful web page title so customers know what guide they are reading.

For each version of the SDK guide, please:

1. Add a short introduction (# Introduction) before the Getting Started section. Sample intro:
    This guide provides information for developers who want to use the Couchbase <language> SDK to
    build applications that use Couchbase Server.

2. In the corresponding index.erb file, change the title to one that follows this naming pattern:
    Couchbase <language> SDK <version> Guide


 Comments   
Comment by Gwen Leong [ 01/Oct/13 ]
Added to all versions.
http://docs.couchbase.com/couchbase-sdk-java-1.2/




[JCBC-326] Couchbase client stuck indefinitely in constructor Created: 04/Jul/13  Updated: 14/Oct/13  Resolved: 14/Oct/13

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

Type: Bug Priority: Major
Reporter: dmitry karlinsky Assignee: Michael Nitschinger
Resolution: Duplicate Votes: 0
Labels: customer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Windows, Java app.

Attachments: Text File client-initalization-stuck.txt    
Issue Links:
Duplicate
duplicates JCBC-368 Deadlock in BucketMonitor.startMonito... Resolved

 Description   
We recently had some connectivity / responsiveness issues with our Couchbase cluster and we noticed that our automated test suite was stuck for over 12h waiting for CouchbaseClient's constructor to complete, which intern was waiting for channelLatch.await().
I'm attaching the stack trace of the hanging thread.
I don't understand the purpose of this latch wait, but perhaps there should be a timeout passed to the await() method, preferably user configurable.

 Comments   
Comment by dmitry karlinsky [ 11/Jul/13 ]
Another stack trace of - stuck on different countdown latch:
java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0x1a934078> (a java.util.concurrent.CountDownLatch$Sync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
        at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
        at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getReceivedFuture(BucketUpdateResponseHandler.java:147)
        at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getLastResponse(BucketUpdateResponseHandler.java:127)
        at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:220)
        at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:177)
        at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:333)
        - locked <0x1a8c4670> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP)
        at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:247)
        at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:175)
Comment by Michael Nitschinger [ 14/Oct/13 ]
Closing this, because it's a duplicate - kinda - of 368.

The latch is never counted down on failure and we are running into issues there. The fix in 368 will take care of the deadlock here.




[JCBC-366] Properly allow override of metrics and listeners Created: 07/Oct/13  Updated: 11/Oct/13  Resolved: 11/Oct/13

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

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





[JCBC-343] Adding Listener support Created: 14/Aug/13  Updated: 01/Oct/13  Resolved: 01/Oct/13

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

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


 Comments   
Comment by thanhbv [ 21/Sep/13 ]
see the following scala code:

val op: OperationFuture[T] = ... //an OperationFuture of type T
op.addListener(new OperationCompletionListener {
  def onComplete(op2: OperationFuture[_]) {
    //I think op2 == op ???
    if(op.getStatus.isSuccess){
      //Here, how to get the value (of type T) in the successfully completed OperationFuture op?
      //I want the result of op.get: https://github.com/couchbase/spymemcached/blob/fb6e0f01cfae13a180127cd65dbec7b025cfbc8e/src/main/java/net/spy/memcached/internal/OperationFuture.java#L158
      //I think we shoud add the following check to (first line of method) OperationFuture#get:
      //if(op != null && op.getState() == OperationState.COMPLETE) return objRef.get();
    }
  }
})
Comment by thanhbv [ 21/Sep/13 ]
@see https://gist.github.com/thanh-buiviet/6649489
Comment by Matt Ingenthron [ 23/Sep/13 ]
Michael is out this week but he should look at this soon. Reopening for now though itmay be a separate request.
Comment by Michael Nitschinger [ 30/Sep/13 ]
Hey,

I'm not quite sure what you say here, can you elaborate a bit? I'm not sure if we should change the OperationFuture.get() behavior, but I'm open to everything if its a bug :)

Also, yes, the future in the onComplete callback is the same. Just so that you could pass in a specific object that doesn't need to come out of the same scope.
Comment by thanhbv [ 30/Sep/13 ]
I have a XXFuture[T] f that hold a future that when complete will produce a value v of type T if success, or produce a failure with some reason.
XXFuture can be OperationFuture, GetFuture, HttpFuture,.. (not just OperationFuture)

When I call f.addListener(some_handler) then, in some_handler (will be call when f is completed), spymemcache need provide a way for me to determine if f is success or not.
"a way" here is f.getStatus.isSuccess. OK.

When I see that f is successful, I need a way to get "the successful value" v.
"a way" here is f.get. Right?

So, I think the implementation of `get` method in OperationFuture, GetFuture,.. should check that if `this` future is already completed then the `get` method should return the completed value immediately.

I think the behavior of the get methods should as the description above.
get := if(completed){ return the completed value} else {value = do_get(); return value }


Sorry. English is not my first language :)
Comment by Michael Nitschinger [ 30/Sep/13 ]
You are right, but that's whats happening (if I understand you correctly).

If the latch is already counted down in the future, you'll get the response back immediately. So first checking for success (which implies that its completed) and then calling .get() is perfectly fine.

Does that makes sense? It's not mine either ;)
Comment by thanhbv [ 01/Oct/13 ]
The current implementation of #get, when the future is completed successfully:
+ OperationFuture#get will almost return immediately. It's OK.
+ BulkGetFuture#get is delegated to #internalGet that call some java.util.concurrent.FutureTask#get. It's OK too.
+ GetFuture#get is also OK.
...
:D after digging into all subclasses of ListenableFuture, I found that all of it is OK! So I think this issue should be (re-)set to resolved now.

thank you.




[JCBC-308] Trouble in resubscribing to primary node via cbc, when all servers go down one by one. Created: 21/May/13  Updated: 25/Sep/13  Resolved: 25/Sep/13

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

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

Attachments: Text File cbc_server_all_nodes_failure.log    
Issue Links:
Dependency
depends on JCBC-138 Java Client does not recover when onl... Resolved
Duplicate
is duplicated by JCBC-304 Client leads to a deadlock when all t... Closed

 Description   
PFA the logs.
More specifically so, it is a concern in case of views.


 Comments   
Comment by Deepti Dawar [ 25/Sep/13 ]
Fixed as the case is similar to JCBC-138.




[JCBC-334] release notes for 1.2.0 Created: 24/Jul/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

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

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


 Description   
Need published release notes for 1.2.0.

This would be expected around first week of September.

 Comments   
Comment by kzeller [ 24/Jul/13 ]
Important: as of 7/24 we are waiting on Ray to get ubu-1701 running. Java 1.2 files exist but are not yet publishable on the web.
Comment by Matt Ingenthron [ 29/Jul/13 ]
Update from Karen last week, the VM has been recovered. I believe we're good to go on docs.




[JCBC-345] Enhance intelligence of client to know about all nodes of a cluster for making REST connection Created: 15/Aug/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

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

Type: Improvement Priority: Major
Reporter: Perry Krug Assignee: Matt Ingenthron
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
If configured with a single host (a load balancer), the client may pause for everytime it loses this connection. The same thing happens when configured with a list of hosts and the client reaches the end of the list...it pauses before going back to the top.

I don't think it's appropriate to ask for the client to constantly spin on trying to make a connection if in fact none can be made.

Another solution to this would be to have the client be aware of ALL the servers in a cluster (which it gets via the vbucket map info) and be able to try all of them, and/or know which ones are alive so that it doesn't have to wait

 Comments   
Comment by Perry Krug [ 15/Aug/13 ]
This is also needed when trying to upgrade the entire cluster as IP addresses are changing (mostly in AWS)
Comment by Perry Krug [ 27/Aug/13 ]
Matt, can this get added to 1.2 as well or is it being deferred?
Comment by Michael Nitschinger [ 27/Aug/13 ]
Perry, whats the deal here?

The reconfiguration is done with backoff (and sleep during backoff), so its not really consuming CPU time.
Comment by Perry Krug [ 27/Aug/13 ]
The deal is to enhance the client so that even if all of the bootstrap nodes become available (or are removed from the cluster) the running client still is able to communicate with the cluster and receive topology changes.

Example:
-4 node cluster with 1.1.1.1, 1.1.1.2., 1.1.1.3, 1.1.1.4.
-1.1.1.1 and 1.1.1.2 are given to the java client as bootstrap nodes
-Now, an upgrade is taking place and 1.1.1.1 and 1.1.1.2 are being swapped out for .5 and .6.
-With the current implementation, the client would not be able to receive further topology updates
-This enhancement is asking that even though .1 and .2 were used for bootstrap, .3 and .4 would be included within the internal list of the client so that when .1 and .2 go away, it can failover to .3 or .4 and continue working.

Obviously a restart of the same client would fail because it couldn't reach .1 or .2, but this is understood and not what we're trying to achieve.

Comment by Michael Nitschinger [ 27/Aug/13 ]
Okay gotcha, I'll think this through.




[JCBC-348] Request for "metrics gathering" feature Created: 22/Aug/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

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

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


 Description   
Similar to Cassandra's indication with speed4J, a request for a feature to be able to gather metrics from a test workload in terms of number of operations, latencies, etc.




[JCBC-360] Prepare for move to maven central Created: 10/Sep/13  Updated: 17/Sep/13  Resolved: 17/Sep/13

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

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





[JCBC-344] allow for setting bootstrap nodes via a configuration file, including dynamic updates Created: 14/Aug/13  Updated: 13/Sep/13  Resolved: 13/Sep/13

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

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

Issue Links:
Dependency
depends on JCBC-138 Java Client does not recover when onl... Resolved

 Description   
Currently, bootstrap parameters may be supplied only via arguments to the constructor. A feature should be added to allow for URLs to be used for bootstrap to be configured via a properties file or something along those lines. This should be able to be edited, and then picked up, during a given client object's lifetime.

 Comments   
Comment by Michael Nitschinger [ 04/Sep/13 ]
The second part of this feature list is to be done in issue JCBC-138.

The constructor with properties will be tracked in this one.




[JCBC-351] Enhance ReplicaRead with active node Created: 27/Aug/13  Updated: 13/Sep/13  Resolved: 13/Sep/13

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