[JCBC-489] Support Replica Read Created: 10/Jul/14  Updated: 10/Jul/14

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

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





[JCBC-488] Getting Failed to Access the View Exception Created: 08/Jul/14  Updated: 09/Jul/14

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

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

Issue Links:
Relates to

 Description   
Caused by: java.lang.RuntimeException: Failed to access the view
        at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:787)


Caused by: java.util.concurrent.ExecutionException: OperationException: GENERAL
        at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:98)
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:82)
        at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:72)
        at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:780)
        ... 9 more
Caused by: OperationException: GENERAL
        at com.couchbase.client.protocol.views.ViewOperationImpl.handleResponse(ViewOperationImpl.java:74)
        at com.couchbase.client.http.HttpResponseCallback.completed(HttpResponseCallback.java:103)
        at com.couchbase.client.http.HttpResponseCallback.completed(HttpResponseCallback.java:51)
        at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115)
        at org.apache.http.nio.protocol.HttpAsyncRequester$RequestExecutionCallback.completed(HttpAsyncRequester.java:376)
        at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115)
        at org.apache.http.nio.protocol.BasicAsyncClientExchangeHandler.responseCompleted(BasicAsyncClientExchangeHandler.java:179)


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

can you please give us more information on when you are seeing the exception (what code are you executing, whats going on at the server - nothing, rebalance, failover,..) Thanks!
Comment by meet_ravip [ 08/Jul/14 ]
Hi,
  We use couchbase 1.4 client and its dependent binaries and below is the code snippet. The failure happens in client.query method. We are running 200 concurrent request to perform the below operation. When couchbase running for more than few and if we start this test it fails, after restarting couchbase when this issue happens and restart the test then it works. Our's 3 node cluster setup. At that time failure there is no rebalance or failover. Lets know if you need any further details.
                        

CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder();
cfb.setOpTimeout(opTimeOut); //100000
cfb.setOpQueueMaxBlockTime(queueMaxBlockTime);30000
cfb.setTimeoutExceptionThreshold(timeoutExceptionThreshold);//998
cfb.setReadBufferSize(readBufSize);//16384
cfb.setShouldOptimize(shouldOptimize);//false
cfb.setMaxReconnectDelay(maxReconnectDelay);//30
cfb.setObsPollInterval(obsPollInterval);//10
cfb.setObsTimeout(obsTimeOut);//5
cfb.setViewTimeout(viewTimeout);//300
cfb.setViewWorkerSize(viewWorkerSize);//1
cfb.setViewConnsPerNode(viewConnectionsPerNode);//100

CouchbaseClient client = new CouchbaseClient(cfb.buildCouchbaseConnection(
hosts, bucketName, userName, password));


Query query = new Query();
query.setReduce(false);
// query.setIncludeDocs(true);
query.setIncludeDocs(false);
query.setStale(Stale.FALSE);


View view = client.getView(designDocumentName, viewName);
if (view != null) {
ViewResponse result = client.query(view, query);
if (result != null) {
List<String> keys = new ArrayList<String>();
for (ViewRow row : result) {
if (row.getKey() != null && !row.getKey().isEmpty()) {

keys.add(row.getKey());
}
}
if (keys.size() > 0) {

documents = client.getBulk(keys);
}
}
}

View Definition:-

function (doc,meta) { emit(meta.id,null);
Comment by Vladislav Koroteev [ 08/Jul/14 ]
I have same issue. I noticed that this exception occured when I do request to view and view is indexing.
Comment by RICHARDS PETER [ 09/Jul/14 ]
In our use case, data update in the couchbase bucket happens only once in a day. During the remaining day, all our clients only read the data from these buckets and still we face this issue. Could you please tell us whether it is possible to control indexing of the view?
Comment by Michael Nitschinger [ 09/Jul/14 ]
Thanks folks,

could you also tell me which server versions you are using? the Error: General points to a 500 response from the server, for whatever reason.
Comment by RICHARDS PETER [ 09/Jul/14 ]
Hi Michael,
We are using 2.1.1 community edition (build-764).
Comment by RICHARDS PETER [ 09/Jul/14 ]
Hi Michael,
Could you also tell me the server log files that should be analyzed to find more details about this error?
Comment by Michael Nitschinger [ 09/Jul/14 ]
Peter,

there is a cbcollect_info command that you can use to aggregate this info, but I would be interested in something else if you can take the time: enable FINEST logging (detailed info here http://nitschinger.at/Logging-with-the-Couchbase-Java-Client) and can you share that log? in there we should have more info from the actual server response and see whats going on.

Also, you could set a breakpoint at com.couchbase.client.protocol.views.ViewOperationImpl.handleResponse(ViewOperationImpl.java:74) and print the original exception https://github.com/couchbase/couchbase-java-client/blob/release14/src/main/java/com/couchbase/client/protocol/views/ViewOperationImpl.java#L74

maybe we should rethrow that.
Comment by Vladislav Koroteev [ 09/Jul/14 ]
I tried reproduce "java.lang.RuntimeException: Failed to access the view", but I can't. I do workload on Couchbase, so I can observer permanent indexing at web-interface. From JavaSDK I do query with stale=false. Earlier I get "java.lang.RuntimeException: Failed to access the view", now I have

java.lang.RuntimeException: Timed out waiting for operation
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:75)
at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:781)
at my.pack.MainView.main(MainView.java:29)
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation
at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:93)
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:82)
at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:72)
... 2 more

I tried it on Couchbase Server 2.2 and Couchbase Server 2.5.1 EE, on Java SDK 1.3.2, 1.4.1, 1.4.3.

Maybe this exception occures while view is compacting, not indexing?




[JCBC-487] com.couchbase.client.protocol.views.Qery key construct Created: 07/Jul/14  Updated: 07/Jul/14

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

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


 Description   
Hello.
There is a little bug in query.setKey. When

String login = "0987654321";
Query query = new Query();
query.setKey(login);

query will be with ?key=987654321 not 0987654321.

It's happen in query.quote()
(https://github.com/couchbase/couchbase-java-client/blob/1.4.3/src/main/java/com/couchbase/client/protocol/views/Query.java#L292)


Also in version 1.3.0 in similar situation (key = "0987654321") key will be key=0987654321 and in response
java.util.concurrent.ExecutionException: OperationException: SERVER: bad_request Reason: invalid UTF-8 JSON: {{error,garbage_after_value},\"0987654321\"}

// Excuse my bad English

 Comments   
Comment by Michael Nitschinger [ 07/Jul/14 ]
You should use ComplexKey instead of the string directly.

Try:

query.setKey(ComplexKey.of("0987654321");
Comment by reinerRubin [ 07/Jul/14 ]
>You should use ComplexKey instead of the string directly.
Thanks. It's work.
But I don't sure about setKey(String) behavior.




[JCBC-485] JsonObject and all its similars Created: 06/Jul/14  Updated: 07/Jul/14

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

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


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

If there is such utility I take it back :)

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

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

Does that work for you?




[JCBC-484] Publish docs for Java July 2014 release Created: 01/Jul/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

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

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


 Description   
Publish updated documentation, release notes, and javadocs.




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

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

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


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

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

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




[JCBC-482] Select proper replica node for getsFromReplica Created: 27/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.3
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-481] Integration Tests hang up after 85% progress Created: 25/Jun/14  Updated: 07/Jul/14

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

Issue Links:
Dependency

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




[JCBC-480] replica read with NOT_EXISTS never completes Created: 25/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.3
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-479] ComparisonFailure in running unit tests for 2.0 client Created: 24/Jun/14  Updated: 07/Jul/14

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

Issue Links:
Dependency

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

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

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

77 tests completed, 2 failed
:test FAILED

FAILURE: Build failed with an exception.

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

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

BUILD FAILED





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

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

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


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




[JCBC-477] Pass view timeout down to get bulk when docs used Created: 23/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.3
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-476] Rework now misleading WARN message. Created: 23/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.3
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-475] Harden DefaultConfigurationProvider on restart and shutdown. Created: 17/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

Status: Resolved
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 1.4.3
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:
Dependency




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

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

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


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




[JCBC-473] Flush support Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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-472] Implement support for snappy compression where supported Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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-471] Implement HELLO command Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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-470] Implement Carrier-based configuration management Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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-469] Implement HTTP-based configuration management Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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-468] Implement EBNF-based N1QL DSL Created: 10/Jun/14  Updated: 07/Jul/14  Resolved: 07/Jul/14

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

Type: New Feature 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-467] Java client not aware of failed over node under certain circumstances Created: 10/Jun/14  Updated: 23/Jun/14

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

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

Attachments: Java Source File anotherMultithreadTest.java     Java Source File CouchbaseClientTesterFastAndThreaded.java     Java Source File CouchbaseClientTester.java     Java Source File CouchbaseClientTesterNewer.java     Text File logAfterSeemingFreeze.txt     Text File threadDumpDuringFreezeSunJVM.txt     Text File threadDumpDuringFreeze.txt    

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

This is using the 1.4.2 java client.

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

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

To unblock a node:
iptables -F

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

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

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

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

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

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

Questions:

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I can do a thread dump.

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

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

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

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

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

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

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

This is with 2.5.1 server against 1.4.2 client.

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

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




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

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

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


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

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




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

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

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


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

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

This came up in the training in NY.




[JCBC-464] client never recovers after full cluster failure and recovery using callbacks Created: 03/Jun/14  Updated: 09/Jul/14

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

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

Attachments: Text File thread-dump.txt    
Issue Links:
Relates to

 Description   
When running this demo, if I disconnect the cluster entirely and restart it, the client reconnects but never recovers:
https://github.com/couchbaselabs/CBLiveDemo




[JCBC-463] Java client occasionally leaks (non-daemon) netty IO threads after shutdown Created: 27/May/14  Updated: 17/Jun/14  Resolved: 17/Jun/14

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

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


 Description   
We're using CouchbaseClient v1.4 from a Java server with moderately high concurrency. When we shutdown the Couchbase client, it usually comes down cleanly, but we occasionally see lingering Netty threads
{noformat}
"New I/O worker #1" prio=10 tid=0x00000000014a3000 nid=0x58bd runnable [0x00007fc7c2f88000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked <0x000000059a590988> (a sun.nio.ch.Util$2) - locked <0x000000059a5909a0> (a java.util.Collections$UnmodifiableSet) - locked <0x000000059a5af320> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.jboss.netty.channel.socket.nio.SelectorUtil.select(SelectorUtil.java:52) at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:223) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102) at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) "Memcached IO over {MemcachedConnection to /10.6.70.3:11210 /10.6.70.2:11210 /10.6.70.1:11210}" prio=10 tid=0x00007fc7dcd48800 nid=0x58b8 runnable [0x00007fc7c38f1000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked <0x000000059e331fe0> (a sun.nio.ch.Util$2) - locked <0x000000059e331ff8> (a java.util.Collections$UnmodifiableSet) - locked <0x000000059a513d90> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:222) at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158)
{noformat}

This prevents clean Java server shutdown, and requires an aggressive "kill -9" to clean up. We figured out how to make the second thread start as 'daemon', but the "New I/O worker" thread can't be converted to daemon without gutting the client libs pretty heavily.

I haven't been able to reproduce this in isolated unit tests. We (Evernote) run around 500 Java7+Tomcat servers that receive a lot of activity over the course of a week, and see this problem come up in the wild around 20% of the time when we try to shut down. So it's a bit hard to narrow down the exact conditions that cause the thread leakage.

Our current workaround:
{noformat}
--- /tmp/BucketMonitor.java 2014-05-16 10:04:58.000000000 -0700
+++ src/main/java/com/couchbase/client/vbucket/BucketMonitor.java 2014-05-16 10:04:16.000000000 -0700
@@ -97,13 +97,28 @@
     this.configParser = configParser;
     this.host = cometStreamURI.getHost();
     this.port = cometStreamURI.getPort() == -1 ? 80 : cometStreamURI.getPort();
- factory = new NioClientSocketChannelFactory(Executors.newCachedThreadPool(),
- Executors.newCachedThreadPool());
+ factory = new NioClientSocketChannelFactory(newThreadPool(),
+ newThreadPool());
     this.headers = new HttpMessageHeaders();
       this.provider = provider;
   }
 
   /**
+ * Creates an executor based on a simple thread pool that only
+ * uses 'daemon' threads.
+ */
+ private java.util.concurrent.Executor newThreadPool() {
+ return Executors.newCachedThreadPool(
+ new java.util.concurrent.ThreadFactory() {
+ public Thread newThread(Runnable r) {
+ Thread t = new Thread(r);
+ t.setDaemon(true);
+ return t;
+ }
+ });
+ }
+
+ /**
    * Take any action required when the monitor appears to be disconnected.
{noformat}

 Comments   
Comment by Michael Nitschinger [ 02/Jun/14 ]
I've got a similar report with the memcache IO thread, maybe this is related. I'll dig into it further and update the progress.
Comment by Michael Nitschinger [ 02/Jun/14 ]
I started work in both spy and jcbc to tackle this individually and harden the shutdown procedures in both.

http://review.couchbase.org/#/c/37726/
http://review.couchbase.org/#/c/37724/




[JCBC-461] Use alternative constructor to allow configuration of max New I/O client Worker thread count Created: 21/May/14  Updated: 02/Jun/14  Resolved: 02/Jun/14

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

Type: Improvement Priority: Critical
Reporter: Vanessa Ablaya Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: performance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Linux, Java 1.6


 Description   
We are running multiple instances of an application on a blade with 24 cores. Netty creates (2 * #PROCESSORS) New I/O Client Worker threads per couchbase client. This is causing high thread count, as each of our application instances does not have complete access to the resources 24 processors. I want to be able to configure the maximum number of threads Netty creates.

Line 100 of BucketMonitor.java uses the following constructor from the netty library:

 public NioClientSocketChannelFactory(
            Executor bossExecutor, Executor workerExecutor)


I would like it to use the alternative constructor that netty provides, so that I can configure the workerCount value:

public NioClientSocketChannelFactory(
            Executor bossExecutor, Executor workerExecutor, int workerCount)



 Comments   
Comment by Michael Nitschinger [ 22/May/14 ]
That makes total sense. I'd rather not add an additional config setting for 1.* since the whole thing is revamaped for the 2.0 where the complete IO layer is based on netty and fully tunable.

What I could imagine though is a system property that you can set, which we could document. So people which run on those very powerful boxes can set it, and the others just don't have to care.
What do you think?
Comment by Michael Nitschinger [ 02/Jun/14 ]
Actually, I think we can trim that down since we are using it for streaming connections only. No need to provide that much. I'll investigate further and see what I can get into 1.4.2.
Comment by Michael Nitschinger [ 02/Jun/14 ]
Btw, two more things:

1) If you go to 1.4.1 and higher, it uses a different config fetching mechanism, so you should not see any of those threads created if you go with a server 2.5.0 and higher.
2) Even on your version, netty should create those threads only when needed, so do you mean you create lots of CouchbaseClient instances? You should reuse them as a singleton. Or do you see lots of those created even for one CouchbaseClient object? If so, this is a bug I think.

Can you provide more details on that? Maybe with a thread dump?
Comment by Michael Nitschinger [ 02/Jun/14 ]
http://review.couchbase.org/#/c/37722/
Comment by Michael Nitschinger [ 02/Jun/14 ]
We know only use one, so no need to configure. Please create a new ticket if you still then see issues with massive amount of threads generated, this is something else then for sure.




[JCBC-460] New configuration gets falsely discarded if only replica vbuckets change. Created: 12/May/14  Updated: 16/May/14  Resolved: 16/May/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.4.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-459] Ignore Configurations with a smaller or equal revid (if set) Created: 12/May/14  Updated: 16/May/14  Resolved: 16/May/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.0, 1.4.1
Fix Version/s: 1.4.2
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-458] Improve logging Created: 08/May/14  Updated: 12/May/14

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

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


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

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

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

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

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




[JCBC-457] Force carrier config fetching on reconnect of node. Created: 07/May/14  Updated: 12/May/14  Resolved: 08/May/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.0
Fix Version/s: 1.4.1
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-456] view query hangs indefinitely, prevents client shutdown too Created: 06/May/14  Updated: 12/May/14  Resolved: 12/May/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.4.0
Fix Version/s: 1.4.1
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
Environment: Mac OS X, Java 1.7.0_55 (I think)


 Description   
Grab the Developer Day code at https://github.com/couchbaselabs/DeveloperDay

Update the client to version 1.4.0.

Run example #9.

For me, it hangs after the last view request. If I downgrade to 1.3.2, it does not hang.

 Comments   
Comment by Matt Ingenthron [ 12/May/14 ]
verified fixed in 1.4.1




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

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

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

Issue Links:
Dependency

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

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




[JCBC-454] Query View bug Created: 27/Apr/14  Updated: 05/May/14  Resolved: 05/May/14

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

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

Attachments: PNG File stack trace.png    
Issue Links:
Duplicate
duplicates SPY-163 Bulk latch never counts down on empty... Resolved

 Description   
1.3.2 works, but 1.4.0 is broken.

Perform a simple query where you set the key to something non-existent and the query will never return. I think an empty result set is properly returned from the server but the Java client doesn't handle it properly afterwards.

      final Query query = new Query();
      query.setIncludeDocs(true);
      query.setKey(ComplexKey.of("abc")); << Non-existent key
      query.setStale(Stale.FALSE);
      final ViewResponse response = client.query(view, query); << Doesn't return.

I think the attached stack trace gives some idea of where it's hung up.

 Comments   
Comment by Michael Nitschinger [ 05/May/14 ]
Hi,

thanks for reporting this - it is a known issue and is already fixed in master, will be in the next bugfix release 1.4.1 this week hopefully.




[JCBC-453] Also check for new configs with different failure modes. Created: 25/Apr/14  Updated: 08/May/14  Resolved: 08/May/14

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





[JCBC-452] Publish docs for Java May 2014 release Created: 22/Apr/14  Updated: 09/May/14  Resolved: 09/May/14

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

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





[JCBC-451] Title on getting started refers to 1.3 Created: 18/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Task Priority: Major
Reporter: Patrick Varley Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: gettingstarted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: http://www.couchbase.com/communities/java/getting-started


 Description   
The title of the page is Couchbase Java Client Library 1.3. It should be 1.4.

 Comments   
Comment by Michael Nitschinger [ 18/Apr/14 ]
thanks!




[JCBC-450] 1.4.0 is not published on maven central Created: 17/Apr/14  Updated: 21/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.
Comment by Matt Ingenthron [ 21/Apr/14 ]
We determined that the issue is the lexical sort of the artifacts. In the future, we'll need to be more careful about how we publish DPs. I think the -SNAPSHOT approach understood by maven needs to be implemented. This should be fixed with a 1.4.1 shortly.




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

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

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
Are you sure this is possible with javadoc? I googled around a bit and didn't find anything.. well we could make it work with changing the files after generation or so.
Comment by Michael Nitschinger [ 17/Jun/14 ]
I fixed that in my build script, check out: http://www.couchbase.com/autodocs/couchbase-java-client-1.4.2/index.html




[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: 23/Jun/14

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

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

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

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

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




[JCBC-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-445] 'Internal Server Error' in case of views for the latest jcbc Created: 02/Apr/14  Updated: 19/Jun/14  Resolved: 19/Jun/14

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

 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.

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
Since the MB ticket was fixed, is this still an issue with 1.4.1 / the upcoming 1.4.2?
Comment by Deepti Dawar [ 04/Jun/14 ]
Will confirm after testing.
Comment by Deepti Dawar [ 19/Jun/14 ]
Latest tests are positive.

https://docs.google.com/a/globallogic.com/spreadsheets/d/1IKxchnrsHQgBQZVF79y55zIk5MsNeuPnZ_iIZ6ptv8s/edit#gid=1382174636

Hence, closing the issue.




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

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

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


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




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

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

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


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




[JCBC-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: 09/Jul/14

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

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


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

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

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

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

How can I avoid duplicate of document from paginated query?

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

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

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

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

- What reduce function do you use?

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

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

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

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

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




[JCBC-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-438] Add table for 1.8, 2.x and 3.x compatibility Created: 25/Mar/14  Updated: 01/Jun/14

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

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

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

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




[JCBC-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: .future
Security Level: Public

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


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




[JCBC-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-435] update README info on maven repos Created: 21/Mar/14  Updated: 01/Jun/14  Resolved: 01/Jun/14

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

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


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

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
The github master has now the 2.0 info and we have a link for 1.4 to the communities site.




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

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

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


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




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

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

Type: Improvement Priority: Critical
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 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: 01/Jun/14

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

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


 Description   
CouchbaseClient.getBulk

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




[JCBC-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-430] Situational Test Java CCCP upgrade : Results are showing auth issues causing latency with the java client. Created: 18/Mar/14  Updated: 19/Jun/14  Resolved: 19/Jun/14

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

Issue Links:
Dependency

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

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
QE issues are closed, is this still an issue?
Comment by Deepti Dawar [ 04/Jun/14 ]
Will confirm after testing.
Comment by Deepti Dawar [ 19/Jun/14 ]
Latest test results are positive

https://docs.google.com/a/globallogic.com/spreadsheets/d/1IKxchnrsHQgBQZVF79y55zIk5MsNeuPnZ_iIZ6ptv8s/edit#gid=1382174636

Closing it.




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

Status: Closed
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: Unassigned
Resolution: Won't Fix 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-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-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-425] document profiling capabilties Created: 04/Mar/14  Updated: 04/Mar/14

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

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


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




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

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

 Comments   
Comment by Michael Nitschinger [ 01/Jun/14 ]
I think we need to do this idle-ping style thing for another related bug edge case with CCCP, so I'll see if we can combine that for 1.4.2.
Comment by Mark Nunberg [ 02/Jun/14 ]
How about a simple ping() method? MySQL has it. We should have it in couchbase

btw ping won't help for those cccp edge cases either
Comment by Mark Nunberg [ 10/Jun/14 ]
I just realized this is attainable by something like the VERSION command :)
Comment by Michael Nitschinger [ 11/Jun/14 ]
Or even easier, what we do in 1.4.2 is a NOOP broadcast.




[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-422] add discussion of timeout accuracy and implementation to documentation Created: 27/Feb/14  Updated: 27/Feb/14

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

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


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





[JCBC-421] Query.setLimit() performance problem Created: 26/Feb/14  Updated: 04/May/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

Issue Links:
Gantt: start-finish
is triggered by SPY-127 Address performance of try/catch in i... Resolved

 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-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: Anonymous 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 scalabl3 [ 13/Mar/14 ]
moved to: https://www.couchbase.com/issues/browse/CBSE-995




[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-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-416] Client throws exception "Cannot cache data larger than 20971520 bytes" when receiving uncompressed document from server Created: 17/Feb/14  Updated: 01/Jun/14

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

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


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




[JCBC-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-413] Race condition in cluster manager class Created: 11/Feb/14  Updated: 02/Jun/14  Resolved: 02/Jun/14

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

Type: Bug Priority: Critical
Reporter: Juan Manuel Musacchio Assignee: Michael Nitschinger
Resolution: Fixed 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();

 Comments   
Comment by Michael Nitschinger [ 02/Jun/14 ]
Thanks, good catch. I'll get the fix in 1.4.2
Comment by Michael Nitschinger [ 02/Jun/14 ]
http://review.couchbase.org/#/c/37719/1
Comment by Michael Nitschinger [ 02/Jun/14 ]
merged into master




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




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

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

Type: Improvement 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   
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-408] javadoc for ComplexKey class formatted incorrectly Created: 02/Feb/14  Updated: 02/Jun/14  Resolved: 02/Jun/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.3.1
Fix Version/s: 1.4.2
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   
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-407] Add Utility to load bootstrap URIs from DNS SRV Created: 29/Jan/14  Updated: 01/Jun/14

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

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





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

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

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


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

Please attach it here and assign to Amy when complete.




[JCBC-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: 02/Jun/14

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0
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-404] Views created via with carriage returns are not executable via web admin Created: 23/Jan/14  Updated: 02/Jun/14

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

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

Issue Links:
Relates to
relates to MB-11275 Views created over REST API with CRLF... Resolved

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

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

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

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

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

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

return arguments.viewFunction;
}
{code}


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

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

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

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

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

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




[JCBC-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-402] Do you plan to add the java bindings for incr multi ? Created: 15/Jan/14  Updated: 01/Jun/14

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

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


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

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

Perl: Multi version of "arithmetic"

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

JavaScript: Now changed to arithmeticMulti()

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


Cheers,

--

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

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




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

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

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


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




[JCBC-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-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-398] Extend CAS and asyncCAS operations to return new CAS value Created: 07/Jan/14  Updated: 12/May/14  Resolved: 12/May/14

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

Type: New Feature Priority: Major
Reporter: Perry Krug Assignee: Michael Nitschinger
Resolution: Won't Fix 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.
Comment by Michael Nitschinger [ 12/May/14 ]
Hey Perry,

asyncCAS already supportes the new cas value (OperationFuture has a getCAS()) method, and we can't extend the cas() method to do it since its an ENUM and not a class.

If people really need it they, should use the asyncCAS method - makes sense?




[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-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-395] Specify specific generated version in headers Created: 31/Dec/13  Updated: 01/Jun/14

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

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


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




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




[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-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-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-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-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-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-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-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-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-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-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-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-377] Getting sdk error - 'Connection reconfiguration failed' while running situational tests Created: 11/Nov/13  Updated: 11/Nov/13

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

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


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

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




[JCBC-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-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-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-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-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-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-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: .future
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-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-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-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-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 (Inactive)
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 (Inactive) [ 01/Oct/13 ]
Added to all versions.
http://docs.couchbase.com/couchbase-sdk-java-1.2/




[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-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-359] not all methods are documented on CouchbaseConnectionFactoryBuilder Created: 03/Sep/13  Updated: 02/Jun/14  Resolved: 02/Jun/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.1.9
Fix Version/s: 1.4.2
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   
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




Views are having issues in access and validations (JCBC-333)

[JCBC-358] make log file accessible Created: 30/Aug/13  Updated: 30/Aug/13  Resolved: 30/Aug/13

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

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

Attachments: Microsoft Excel java-1.1.8-release-2.1.1-763-1h_AT-2013-07-22T19-34-57.xlsx    

 Description   
Please make the log file mentioned in JCBC-333 readable. Thanks!




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

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

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


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




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

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

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


 Description   
Not blocking anyone, but the library could be more resilient by properly handling a null transcoder instead of throwing the following exception:

Aug 27 09:40:07: INFO: Reconnecting due to exception on {QA sa=localhost/127.0.0.1:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: -108 Opaque: 41 Key: 10 Exp: 10, topWop=null, toWrite=0, interested=1}
Aug 27 09:40:07: java.lang.NullPointerException
Aug 27 09:40:07: at com.couchbase.client.CouchbaseClient$9.gotData(CouchbaseClient.java:953)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.GetlOperationImpl.decodePayload(GetlOperationImpl.java:59)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.OperationImpl.finishedPayload(OperationImpl.java:178)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl.java:162)
Aug 27 09:40:07: at net.spy.memcached.protocol.binary.GetlOperationImpl.readFromBuffer(GetlOperationImpl.java:31)
Aug 27 09:40:07: at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:563)
Aug 27 09:40:07: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:480)
Aug 27 09:40:07: at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:261)
Aug 27 09:40:07: at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:288)

 Comments   
Comment by Michael Nitschinger [ 27/Aug/13 ]
what do you think is appropriate? The only thing that comes to my mind is checking for every command and throw a InvalidArgumentException?
Comment by Perry Krug [ 27/Aug/13 ]
I'm not sure what the right approach is (surely Matt can) but the customer indicated that an NPE was always something we shouldn't see




[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

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-350] Race Condition in observe/replica Created: 27/Aug/13  Updated: 11/Sep/13  Resolved: 11/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: 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


 Comments   
Comment by Michael Nitschinger [ 27/Aug/13 ]
Pushed into master, awating reporter feedback for close.




[JCBC-349] Calling flush() on CouchbaseClient throws a ClassCastException Created: 26/Aug/13  Updated: 04/Sep/13  Resolved: 04/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: Bug Priority: Blocker
Reporter: Alan Kleiman Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
When calling flush() on CouchbaseClient a ClassCastException is thrown:

java.lang.ClassCastException: com.couchbase.client.CouchbaseMemcachedConnection cannot be cast to com.couchbase.client.CouchbaseConnection
at com.couchbase.client.CouchbaseClient.flush(CouchbaseClient.java:2421) ~[couchbase-client-1.1.9.jar:1.1.9]
at com.couchbase.client.CouchbaseClient.flush(CouchbaseClient.java:2410) ~[couchbase-client-1.1.9.jar:1.1.9]

The problem seems to be in CouchbaseClient:2421, maybe related to JCBC-323?

 Comments   
Comment by Michael Nitschinger [ 26/Aug/13 ]
Jup looks like a bug! Expect a fix for the next release.
Comment by Michael Nitschinger [ 27/Aug/13 ]
http://review.couchbase.org/#/c/28599/




[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-347] Adjust observe intervals for better performance Created: 20/Aug/13  Updated: 27/Aug/13  Resolved: 27/Aug/13

Status: Resolved
Project: Couchbase Java Client
Component/s: None
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: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[JCBC-346] Support CRAM-MD5 as a sasl mechanism Created: 15/Aug/13  Updated: 27/Aug/13  Due: 19/Aug/13  Resolved: 27/Aug/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: Bug Priority: Major
Reporter: Mike Wiederhold Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Matt Ingenthron [ 15/Aug/13 ]
Michael: I know you're missing a bit of information here, but the goal is that the 2.2 server release be tested with this functionality. This would mean getting this together either on the 16th or monday the 23rd.
Comment by Michael Nitschinger [ 27/Aug/13 ]
JCBC ticket merged, corresponding SPY will be in 2.9.2




[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-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-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-342] TAP Client streams should be reconfigure-aware (reestablish streams) Created: 06/Aug/13  Updated: 06/Sep/13

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

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

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




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

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

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

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




[JCBC-340] Tap client should only connect to active vbuckets Created: 16/Aug/12  Updated: 06/Aug/13  Resolved: 06/Aug/13

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

Type: Bug Priority: Critical
Reporter: Mike Wiederhold Assignee: Matt Ingenthron
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-341 TapClient should tap only vbuckets on... Open
relates to JCBC-342 TAP Client streams should be reconfig... Open

 Comments   
Comment by Michael Nitschinger [ 06/Aug/13 ]
Here is the first set of changes:

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

The other changes will be tracked in subsequent tickets and linked.




[JCBC-339] Couchbase java client ignores provided username and always use bucket as username during HTTP authorization step Created: 31/Jul/13  Updated: 31/Jul/13  Resolved: 31/Jul/13

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

Type: Bug Priority: Blocker
Reporter: Sergey Bushik Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Server: CentOS 2.6.32 x86_64, Client: MacOS Darwin 12.4.0, Java 1.6


 Description   
new CouchbaseClient(servers, "default", "username", "password") doesn't honor provided username and always use bucket as username during HTTP authorization step.

Outgoing request is:
FINE: www.MessageHeader@658f73867'>sun.net.www.MessageHeader@658f73867 pairs: {GET /pools HTTP/1.1: null}{Accept: application/json}{user-agent: Couchbase Java Client}{X-memcachekv-Store-Client-Specification-Version: 1.0}{Authorization: Basic ZGVmYXVsdDpwYXNzd29yZA==}{Host: 192.168.1.79:8091}{Connection: keep-alive}
Text value of Authorization header corresponds to "Basic default:password", while it should be "Basic username:password"

Therefore 401 unauthorized response received:
www.MessageHeader@92f1bf07'>sun.net.www.MessageHeader@92f1bf07 pairs: {null: HTTP/1.1 401 Unauthorized}{WWW-Authenticate: Basic realm="Couchbase Server Admin / REST"}{Server: Couchbase Server 2.1.0-718-rel-enterprise}{Pragma: no-cache}{Date: Wed, 31 Jul 2013 13:10:21 GMT}{Content-Length: 0}{Cache-Control: no-cache}

The actual bug hides at line #131 of method com.couchbase.client.CouchbaseConnectionFactoryBuilder.buildCouchbaseConnection(final List<URI> baseList, final String bucketName, final String usr, final String pwd), wher usr parameter is not used anyhow and just ignored

Or see it at:
https://github.com/couchbase/couchbase-java-client/blob/master/src/main/java/com/couchbase/client/CouchbaseConnectionFactoryBuilder.java#L131

 Comments   
Comment by Michael Nitschinger [ 31/Jul/13 ]
Hi Sergey,

that's intended and not an issue. This is because the "user" is currently not being used, you always need to use the bucket name as the user and the password.

The only occasion where you dont get around with bucket level credentials is by adding/removing buckets, with the ClusterManager, and there you need to provide the admin creds.

Makes sense?
Comment by Sergey Bushik [ 31/Jul/13 ]
Technically, I see extended signature which accepts bucket, username & password parameters. Even though the credentials are valid, it throws out error, which says nothing about username parameter usage, but...

java.io.IOException: Server returned HTTP response code: 401 for URL: http://192.168.1.79:8091/pools
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:424)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210)
at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147)
at com.couchbase.client.CouchbaseConnectionFactory.getVBucketConfig(CouchbaseConnectionFactory.java:229)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:241)
Exception in thread "main" com.couchbase.client.vbucket.ConfigurationException: Configuration for bucket "default" was not found in server list ([http://192.168.1.79:8091/pools]).

That's confusing. By the way, I debugged and found that it's possible to authenticate using bucket/u