[JCBC-619] Implement support for DCP (Streaming) Created: 03/Nov/14  Updated: 03/Nov/14

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

Type: New Feature Priority: Blocker
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-618] Improve Field Serviceability Created: 03/Nov/14  Updated: 03/Nov/14

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

Type: New Feature Priority: Blocker
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   
Building on http://www.couchbase.com/issues/browse/JVMCBC-60 and exposing it to the java client.




[JCBC-617] Implement support for JSR 107 (JCache) Created: 03/Nov/14  Updated: 03/Nov/14

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

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


 Description   
Support for JSR 107 needs to be added. It yet needs to be determined if we ship it as part of the client or as a separate project.




[JCBC-576] Add support for geospatial querying Created: 07/Oct/14  Updated: 03/Nov/14

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

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


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

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




[JCBC-407] Bootstrap through DNS SRV Created: 29/Jan/14  Updated: 03/Nov/14

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

Type: New Feature Priority: Blocker
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-609] Fix Maven Tags on 2.0 Client, remove "beta" from package tags. Created: 28/Oct/14  Updated: 30/Oct/14

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

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


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

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



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




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

Status: Open
Project: Couchbase Java Client
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.2
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:
Dependency
depends on JVMCBC-35 Expose View retry codes in response s... Resolved




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

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

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





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

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


 Comments   
Comment by Michael Nitschinger [ 13/Nov/14 ]
this needs to be a specific exception when returned from the server as a result so that the user can react to it.




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

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

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


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

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

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








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

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

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


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




[JCBC-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: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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

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

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

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

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

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




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

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

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


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




[JCBC-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-269] subsequent resubscribers should not run if a resubscriber is successful Created: 13/Mar/13  Updated: 06/Sep/13

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

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


 Description   
When investigating a case recently, I noticed many resubscribers running once a second. Looking at the code, it appears the kind of threadpool being used would just queue more and more up, but only run one at a time.

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




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

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

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


 Description   
Neither the javadoc nor the existing documentation really cover the potential issues with setKey using a number or something that will autobox into a string value. This should be much clearer.




[JCBC-89] re-enable optimization after error handling in binary optimized sets is fixed in dependent spymemcached Created: 31/Jul/12  Updated: 19/Jul/13

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

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


 Comments   
Comment by Matt Ingenthron [ 17/Dec/12 ]
I do think this one needs to be addressed before 1.2.




[JCBC-629] Document remove cas on doc actually deleted or not Created: 17/Nov/14  Updated: 17/Nov/14

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

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





[JCBC-628] Add support for creating JsonArray and JsonObject from raw json strings Created: 17/Nov/14  Updated: 20/Nov/14

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

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


 Comments   
Comment by Simon Baslé [ 20/Nov/14 ]
To be fleshed out and probably combined with support for NULL values.




[JCBC-622] Add project name and description to generated pom Created: 04/Nov/14  Updated: 17/Nov/14

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

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





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

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

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


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

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

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

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

Thanks

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

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

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

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

Thanks!
Comment by Matt Ingenthron [ 31/Oct/14 ]
Thanks Facundo. Note that the logging may come from two different threads and in order to understand what's happening if you still see this behavior, we'll need to see logs from both the IO thread and what's happening at your app's thread relative to each other. Just INFO on up logging would be useful.
Comment by Matt Ingenthron [ 31/Oct/14 ]
Oh, and the behavior you were seeing maps exactly to something that was fixed in 1.4.5.
Comment by Michael Nitschinger [ 03/Nov/14 ]
Okay great, please let us know if 1.4.5 resolved the issue or not and if not, please give us more info how its going.
Thanks!




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

Status: In Progress
Project: Couchbase Java Client
Component/s: Documentation
Affects Version/s: 1.4.5, 2.0.0
Fix Version/s: 2.0.2
Security Level: Public

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


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

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

 Comments   
Comment by Michael Nitschinger [ 04/Nov/14 ]
This is in progress.
Comment by Matt Ingenthron [ 18/Nov/14 ]
Todd: any updates on this? There is a pull request on this too.
Comment by Amy Kurtzman [ 18/Nov/14 ]
The pull request that Matt mentioned has been closed in favor of waiting for an approved statement of what versions we support as agreed upon by client dev, PM, and QE.




[JCBC-607] Rework and extend Tutorial based on 2.0.1 Created: 27/Oct/14  Updated: 17/Nov/14

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

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


 Description   
On this page:

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

I see these two issues:

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

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

 Comments   
Comment by Michael Nitschinger [ 04/Nov/14 ]
I need to upgrade this issue to a larger effort in order to rework the tutorial which will also incorporate those changes. I've marked it for 2.0.2 but plan to get it done much earlier.




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

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

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


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

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

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

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

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




[JCBC-595] Automatically prefix zip jars with "couchbase-" Created: 17/Oct/14  Updated: 04/Nov/14

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

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


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

Shouldn't those have couchbase in them?

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

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

Now the question is

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

If it doesn't break anything, what about prefixing in the zip files with couchbase- ?
Comment by Michael Nitschinger [ 04/Nov/14 ]
For now I'll do this by hand when relesing, looking into automating this through gradle.




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

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

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


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


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

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

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

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

}
}

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

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

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


dependency

       <dependency>

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

<artifactId>couchbase-client</artifactId>

<version>1.3.0</version>

  </dependency>

        <dependency>

        <groupId>commons-codec</groupId>

        <artifactId>commons-codec</artifactId>

        <version>1.7</version>

      </dependency>

      <dependency>

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

        <artifactId>jettison</artifactId>

        <version>1.3</version>

       

      </dependency>

           <dependency>

        <groupId>net.spy</groupId>

        <artifactId>spymemcached</artifactId>

        <version>2.11.4</version>

      </dependency>

      <dependency>

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

<artifactId>netty</artifactId>

<version>3.2.0.Final</version>

</dependency>

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

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

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

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




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

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

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

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

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

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




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

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

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


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

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

thanks




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

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

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


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

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

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

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




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

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

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


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




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

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

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


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

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




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

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

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

Attachments: Java Source File Hello.java    

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

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

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




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

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

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

Issue Links:
Relates to

 Description   
This is the only failed integration test from beta2

Class com.couchbase.client.java.DesignDocumentTest

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




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

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

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





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

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

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





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

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

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

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

 Description   
The following code hangs on the 2nd query.

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





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

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

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





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

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

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

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

 Description   
CouchbaseConnectionFactoryBuilder.setHashAlg() is currently not operational.




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

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

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


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

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

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




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

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

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


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

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

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

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




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

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

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

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

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

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

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

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




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

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

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


 Description   
Hi,

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

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

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

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

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

Richards Peter.




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

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

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

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

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

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

However, our plan also calls for a policy driven fallback

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

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

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

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

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

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

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




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

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

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

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




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

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

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

Issue Links:
Relates to

 Description   
Customer is using client side profiling as suggested in:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

here is more info on each specific metric:

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

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

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

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

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

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

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

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

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

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

[MEM] Request Rate: All.csv

>> rate of outgoing requests

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

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

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

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

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

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

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

>> see above, just for reads.




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

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

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


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




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

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

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


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

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


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






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

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

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

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

 Description   
This was observed on Couchbase Server 2.2.0. The same behavior is not evident on Couchbase Server 2.5.1. It appears to be independent of any Java client version. The very first call of asyncGetBulk does not respect the timeout value, and continues to process and wait. Subsequent calls do properly respect the timeout value. One interesting note is that this only occurs when the timeout value is "close" to the actual execution time. That is, a very short timeout is indeed honored.

Steps to reproduce:

* Download a Java client, such as http://packages.couchbase.com/clients/java/1.4.3/Couchbase-Java-Client-1.4.3.zip

* Unzip

* Copy the attached App.java into the unzipped directory

* Compile and run:

javac -cp couchbase-client-1.4.3.jar:spymemcached-2.11.4.jar App.java

java -cp .:couchbase-client-1.4.3.jar:spymemcached-2.11.4.jar:jettison-1.1.jar:netty-3.5.5.Final.jar:commons-codec-1.5.jar:httpcore-4.3.jar:httpcore-nio-4.3.jar App > 143.txt

* Note the following output in the first group. It would be expected that the first call would timeout, but does not:

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=108ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=17ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=18ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=16ms


Exception:********************
Timeout future is: true
Operation timed out. - failing nodes: 10.4.2.107/10.4.2.107:11210, cbhost.domain/10.4.2.57:11210
Timeout set to:16
getMulti : Time taken=18ms

Timeout future is: false
Fetched 72 keys
Timeout set to:16
getMulti : Time taken=17ms


ASK - Determine why the first call does not honor the timeout, and ideally suggest a workaround for Couchbase Server 2.2.0, short of upgrading to Couchbase Server 2.5.1 (where the issue does not appear exist, and therefore looks to be a server-side issue)




 Comments   
Comment by Aleksey Kondratenko [ 11/Aug/14 ]
Not honoring timeouts cannot be server side issue. Passing to Michael who owns couchbase java sdk
Comment by Jeff Dillon [ 12/Aug/14 ]
Please disregard my previous comments with respect to being apparently fixed with Couchbase Server 2.5.1. This behavior evidences itself across all CB server versions, and also reproduces with CB Java client 1.4.4. In my latest 2.5.1 test, I set the timeout to 30 ms, and see the same incorrect behavior. So this is indeed a client issue (as noted), apologies on the initial misinformation.
Comment by Michael Nitschinger [ 14/Aug/14 ]
A few remarks:

- The simple benchmark also profiles logging and so forth.
- System.currentTimeMillis() precision is sometimes beyond all joke, always use nanotime.

So something like this is more accurate:

        while (low == 10) {
            try {
                startTime = System.nanoTime();
                future = client.asyncGetBulk(Main.getKeys());
                future.get(timeout, TimeUnit.MILLISECONDS);
                endTime = System.nanoTime();
                System.out.println("Timeout future is: " + future.isTimeout());
                System.out.println("Fetched " + Main.getKeys().size() + " keys");
            } catch (Exception e) {
                System.out.println("\nException:********************\nTimeout future is: " + future.isTimeout());
                System.out.println(e.getMessage());
            }
            operationTime = endTime - startTime;
            System.out.println("Timeout set to:" + timeout + "\ngetMulti : Time taken=" + TimeUnit.NANOSECONDS.toMillis(operationTime) + "ms\n");
        }

Now also note that profiling on the blocking .get() call not only waits on the latch where the timeout is applied, but it also puts all data together and so forth. So as far as I can see it the timeout is honored, its just not what you benchmark that close. Keep in mind that the first few calls are subject t JVM warmup, optimizations and so forth which can take some time. It's not a huge surprise that the first few calls are slightly slower, but I guess thats not what the JVM optimizes for compared to a long-running server.

Does that help?
Comment by Jeff Dillon [ 14/Aug/14 ]
I am seeing the same behavior when using nanoTime. And it's not slightly slower, it's an order of magnitude difference. And I don't think it's JVM warmup either, as different timeout values show consistent differences every time. Using a short time out value works as expected, but is not the timeout value they desire. When the timeout is "close" to the actual execution time, it experiences this behavior. This is what I'm seeing in my tests, and is what the customer is seeing also.
Comment by Matt Ingenthron [ 20/Aug/14 ]
Jeff Dillon: I understand from James this has been observed on 2.5.1 now as well. Can you confirm and update it appropriately? Also, I've moved it to JCBC, since the investigation has lead here.
Comment by Jeff Dillon [ 20/Aug/14 ]
Yes, please see my previous comment from 12/Aug/14 1:47 PM




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

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

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





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

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

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


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




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

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

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


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




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

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

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


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

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


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

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

{code}



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

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

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

        }
   
{code}

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




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

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

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


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

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


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

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

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


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



log:

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

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

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

Thanks again




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

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

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


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

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

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




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

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

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


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

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

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

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

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






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

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

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


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

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

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




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

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

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

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

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

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




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

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

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

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

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

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

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

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

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




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

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

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


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




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

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

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


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





[JCBC-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-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-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-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-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-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-328] create tuneable for compressing JSON Created: 08/Jul/13  Updated: 06/Sep/13

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

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


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

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




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

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

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


 Description   
One thing which needs to be better documented is how to enable the NOOP check on connect.

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




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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




[JCBC-303] javadoc builds must include spymemcached Created: 14/May/13  Updated: 19/Jul/13

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

Type: Bug Priority: Major
Reporter: Phil Labee (Inactive) Assignee: Phil Labee (Inactive)
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JCBC-293 Clarification/Agreement on Javadocs B... Resolved

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

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

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


Need to have:

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

* one that is not tied to a particular host

* is fully documented

 Comments   
Comment by Phil Labee (Inactive) [ 15/May/13 ]
I modified the couchbase-java-client/build.xml file to also use the source files under

    ../spymemcached/src/main/java/

for generating javadocs, but I'm getting errors:

    package org.apache.log4j does not exist
    package org.springframework.beans.factory does not exist
    
so it looks like a classpath issue.
Comment by Michael Nitschinger [ 15/May/13 ]
Hi Phil,

normally log4j and spring beans are configured as "provided", so you should not need them during runtime in spy. maybe just run "ant jar" once in the directory so it fetches the dependencies in the right directories?
Comment by Phil Labee (Inactive) [ 29/May/13 ]
commit 0b2ddd7de1e963f1ad3e4817ee55c5ef7bc70901 adds to "docsjar" target to include spymemcached in docs jarfile

Requires spymemcached repo clones to workspace as peer to couchbase-java-client (or modify the extern.root property).
Comment by Phil Labee (Inactive) [ 29/May/13 ]
The generated ZIP file doesn't work right. It contains the docs from both projects, but I need to collate the package list files so that they appear together. Right now there are two copies of the top level html file (e.g. allclasses-frame.html) so depending on whether you answer yes or no to overwrite when unzipping, you get either the couchbase or the spymemcached files displayed.

Next step is to build the zip file with the proper index files.
Comment by Matt Ingenthron [ 29/May/13 ]
Phil: the idea is to use the javadoc command once using both projects as input, and then javadoc will build the appropriate indexes. Something like:

javadoc /path/to/couchbase-client/* /path/to/spymemcached/*
Comment by Michael Nitschinger [ 19/Jul/13 ]
Phil,

is the process finished and automated by now?




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

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

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


 Description   
At CouchbaseClient.java line 2192 and line 2196

They both call

replicaPersistedTo++;

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

Is that intensional. Looks odd to me.

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




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

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

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


 Description   

Please see the feature request below.

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




[JCBC-294] OOME on ViewResponse for very large view Created: 02/May/13  Updated: 19/Jul/13

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

Type: Task Priority: Major
Reporter: Tug Grall (Inactive) Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Java application with large view


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

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


Note from our community member

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

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

 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
assigning this to .next, because this potentially requires larger changes and needs more investigations.




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

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

Type: Improvement Priority: Major
Reporter: Andrew Kulikov Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Debian GNU/Linux 6.0 (amd64), Couchbase community edition.


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

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

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

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

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

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

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

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

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




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

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

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


 Comments   
Comment by Matt Ingenthron [ 22/Apr/13 ]
"publishing" isn't a real action, it's just moving the same design document in under a different name. This should definitely be done, but as documentation about how to go from development to published.




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

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

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


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




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

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

Type: Task Priority: Major
Reporter: Michael Nitschinger Assignee: Michael Nitschinger
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Any Couchbase SDK against a 1.8 cluster


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

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

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

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

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

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

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

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

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




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

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

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


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

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




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

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

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


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

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




[JCBC-279] Docs: Cross-link bulk loading and blocking queue documentation with async commands Created: 02/Apr/13  Updated: 19/Jul/13

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

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


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




[JCBC-275] Slow performance in virtualized environments Created: 18/Mar/13  Updated: 19/Jul/13

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

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


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

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

Will update with specific stats later on.




[JCBC-262] Transcoder error not reported correctly Created: 11/Mar/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.3
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   
When a custom transcoder has an error, certain CAS operations fail with an error about the operation being cancelled, which is misleading and doesn't point to the transcoder as a problem.

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

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

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

Transcoder (incorrect):

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

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

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

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

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

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

return (T)obj;
}

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

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

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

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

}




[JCBC-255] improve warmup handing Created: 27/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.3
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   
With the integration of JCBC-27, the client will do an exponential backoff at construction time when the server is unavailable, and then throw an exception (from the ctor, unfortunately) if it could not complete.

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

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




[JCBC-248] ensure there is a floor to tuneables such that they can't be set so a client misbehaves Created: 15/Feb/13  Updated: 19/Jul/13

Status: Open
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.0.3, 1.1.0, 1.1.1, 1.1.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   
There have been a few situations where people have either inavertently or not knowing what they're doing set various internal timings to incorrect values. We should create a floor or a ceiling for these and change them with a warning if the user attempts to misuse it.

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






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

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

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


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

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

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

Docs for the paginator will be added soon!




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

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

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


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

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






[JCBC-234] Write the Java on Mac OS X using Eclipse section of the Essentials Guide Created: 04/Feb/13  Updated: 19/Jul/13

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

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


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

Needs to cover:

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

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


 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
Same here!
Comment by kzeller [ 19/Jul/13 ]
ditto, not now at all




[JCBC-233] Write the Java on Windows with Eclipse installation instructions for essentials guide Created: 04/Feb/13  Updated: 19/Jul/13

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

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


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

Needs to cover:

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

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


 Comments   
Comment by Michael Nitschinger [ 19/Jul/13 ]
aaand same here ;)
Comment by kzeller [ 19/Jul/13 ]
Tag, you're it (but not really yet at all, maybe October?)




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

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

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

Issue Links:
Dependency

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

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




[JCBC-222] prioritized disk write queue - java client Created: 28/Jan/13  Updated: 19/Jul/13

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

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


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

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




[JCBC-217] Create Source-Code Styleguide Created: 23/Jan/13  Updated: 19/Jul/13

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

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


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

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




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

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

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


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

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




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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



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




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

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

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


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

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

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




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

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

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


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

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

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

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




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

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

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

Etc., there are a bunch of these.


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

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




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

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

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


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

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

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

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



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




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

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

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


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

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






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

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

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


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

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

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




[JCBC-180] Allow for default value to append/prepend Created: 12/Dec/12  Updated: 01/Aug/13

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

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

Issue Links:
Dependency
depends on MB-7653 Allow for default value to append/pre... Open

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

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Moved to .next until this is clarified on the server side.




[JCBC-169] add overloaded methods for various types to the Query class Created: 06/Dec/12  Updated: 19/Jul/13

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

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


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

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




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

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

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

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

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

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

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

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

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

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




[JCBC-116] Implement the ObserveSet for better observing of replication/persistence Created: 18/Sep/12  Updated: 19/Jul/13

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

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





[JCBC-115] thoroughly test on_error arguments Created: 18/Sep/12  Updated: 19/Jul/13

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

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


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

 Comments   
Comment by Michael Nitschinger [ 09/Nov/12 ]
Mark,

Can you add this to your sdkd testsuite? Its hard to deal with this in unit tests (would require lots of mocking) and I assume you can shutdown nodes and verify the behavior is correct?

Thanks,
Michael
Comment by Michael Nitschinger [ 29/Nov/12 ]
We can do this in functional tests as well, there are easy ways to produce errors on the server.
Comment by Mark Nunberg [ 29/Nov/12 ]
Please share :)




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

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

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

Issue Links:
Dependency
depends on JCBC-117 mention that OperationFuture.get(tmo)... Reopened

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

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

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

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

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

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

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




[JCBC-108] observe loop implementation behind mutations should be adaptive to server persistence latencies Created: 11/Sep/12  Updated: 19/Jul/13

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

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


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




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

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

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


 Description   
Because of the codebase's legacy, the handling of the Bucket and Configuration is rather odd. It used to exist outside the client to serve a different purpose. At that time, not changing the client internals was desirable.

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




[JCBC-18] NPE if hostnames in server bootstrap list are mixed case Created: 12/Mar/12  Updated: 19/Jul/13

Status: Reopened
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1-dp4
Fix Version/s: .future
Security Level: Public

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


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

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




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

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

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


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

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

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

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




[JCBC-621] Improper error message in case of stale CAS. Created: 22/Jul/13  Updated: 03/Nov/14

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

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


 Description   
Getting an improper error message in case of stale CAS. Following is what has been tried :

1) Added a new key testStaleCAS" with a value. This op stores the cas value as cas1.
2) Invoked set operation on the same key. This time the cas changes to cas2.
3) Append operation is called on the key with the cas value of cas1.

The error message which is returned from the server is 'Data Exists for the key'.
Where as it should be something specific to the wrongly used cas value like 'Invalid use of Cas Id'.

 Comments   
Comment by Mike Wiederhold [ 30/Sep/13 ]
Trond,

This is the generic error generated by memcached for the EEXISTS error. Do you think there is a way we could make the error message more specific?
Comment by Trond Norbye [ 01/Oct/13 ]
Which client is this?
Comment by Trond Norbye [ 01/Oct/13 ]
It should be fixed in the client. the error text is going to be removed from the server at some point..
Comment by Deepti Dawar [ 01/Oct/13 ]
Hi Trond,

This is the Java Client, but its only delegating the message which is coming from the server.
Can you please kindly check and let me know what are you sending back from the server in this scenario.

Thanks !
Comment by Trond Norbye [ 01/Oct/13 ]
It is the text that is currently being sent back from the server, but will be removed rather than changed. The client should provide the text for the various return codes (and possibly localize them).
Comment by Don Pinto [ 03/Nov/14 ]
Micheal, any thoughts on this one? Also, moving this to Java Client library project.




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

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

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

Attachments: Text File aero-ebay.log    

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

Without DEBUG logging turned on, this shows up as

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

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

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

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

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

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

I've attached the log with DEBUG turned on.

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

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

Dan, thanks for raising this.
Comment by Michael Nitschinger [ 04/Nov/14 ]
In the next bugfix release let's see if we can get unit tests in. Things have improved in 2.0 but we want to formalize that to some degree.




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

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

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


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

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

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

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




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

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

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


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

First:

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


Second:

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

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




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

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

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

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

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

To repro:

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

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

Relevant code is:

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

When running the example, the response is consistently:

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



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

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

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

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

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

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




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

Status: Open
Project: