mem_all_nodes_input.log
mem_primary_node_failure.log
[JCBC-311] Expose the Server Error Code in the OperationStatus Created: 23/May/13 Updated: 23/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The Java SDK does not use the Error Code from the server side, as documented here:
http://blog.couchbase.com/handling-runtime-errors-ruby-python-and-c-clients It would be very useful for the developer to be able to use the same code in Java. We could use the OperationStatus to expose this enumeration. |
[JCBC-310] Create a getBulk() operation that returns CASValue object Created: 23/May/13 Updated: 23/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| 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 |
[JCBC-309] Catch ConcurrentModificationException in IO thread as safety net. Created: 23/May/13 Updated: 23/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | 1.1.7 |
| 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 | ||
[JCBC-304] Client leads to a deadlock when all the servers are unavailable Created: 21/May/13 Updated: 23/May/13 |
|
| 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: | Deepti Dawar | Assignee: | Deepti Dawar |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
Stack Trace :-
"pool-17-thread-8" prio=10 tid=0x00007fdea007c800 nid=0xacac waiting on condition [0x00007fdf168e6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007f8d383f0> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.jav a:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java: 1303) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236) at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getReceivedFuture(BucketUpdateResponseHandler.java:147) at com.couchbase.client.vbucket.BucketUpdateResponseHandler.getLastResponse(BucketUpdateResponseHandler.java:127) at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:212) at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:333) - locked <0x00000007f81cb9c0> (a com.couchbase.client.vbucket.ConfigurationProviderHTTP) at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:247) |
| Comments |
| Comment by Deepti Dawar [ 23/May/13 ] |
|
The usage of CountDownLatch here in BucketMonitor may not be quite justified in the case where the user application is calling this from a multi-threaded env in a non-synchronized manner. Here either our code needs to be intelligent enough to avoid deadlocks or the calling application needs to be aware of the same. Looking at the customer issue which lead to this, their usage of the CouchbaseClient instance seems incorrect. Matt, Can you please suggest ? |
[JCBC-305] Client does not recover with Memcached connection to the server and primary node goes down. Created: 21/May/13 Updated: 21/May/13 |
|
| 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: | Deepti Dawar | Assignee: | Deepti Dawar |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
mem_all_nodes_input.log
mem_primary_node_failure.log
|
| Description |
|
2013-05-21 12:59:04.158 ERROR net.spy.memcached.protocol.ascii.StoreOperationImpl: Error: SERVER_ERROR temporary failure
Deepti Exception 1 java.util.concurrent.ExecutionException: OperationException: SERVER: SERVER_ERROR temporary failure 2013-05-21 12:59:04.158 INFO net.spy.memcached.MemcachedConnection: Reconnection due to exception handling a memcached operation on {QA sa=/10.3.121.207:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000365cbc Flags: 0 Exp: 0 Data Length: 79, topWop=null, toWrite=0, interested=8}. This may be due to an authentication failure. OperationException: SERVER: SERVER_ERROR temporary failure at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:164) at net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.java:151) at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:537) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-05-21 12:59:04.159 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc. 2013-05-21 12:59:04.159 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/10.3.121.207:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000365cbc Flags: 0 Exp: 0 Data Length: 79, topWop=null, toWrite=0, interested=8}, attempt 22. 2013-05-21 12:59:04.159 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc. 2013-05-21 12:59:04.159 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000365cbc Flags: 0 Exp: 0 Data Length: 79 2013-05-21 12:59:04.160 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-05-21 12:59:04.160 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc. 2013-05-21 12:59:04.160 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000366cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:06.660 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000367cbc. 2013-05-21 12:59:06.661 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000367cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:09.163 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000368cbc. 2013-05-21 12:59:09.164 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000368cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:11.666 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000369cbc. 2013-05-21 12:59:11.667 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000369cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:14.168 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000370cbc. 2013-05-21 12:59:14.169 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000370cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:16.671 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000371cbc. 2013-05-21 12:59:16.672 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000371cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:19.174 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000372cbc. 2013-05-21 12:59:19.175 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000372cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:21.677 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000373cbc. 2013-05-21 12:59:21.678 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000373cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-05-21 12:59:24.179 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000374cbc. 2013-05-21 12:59:24.180 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000374cbc. |
| Comments |
| Comment by Deepti Dawar [ 21/May/13 ] |
|
In this case, server is stopped one by one on all the server nodes starting with the primary node. Even when the first node is brought up, the client does not recover. It recovers much after all the nodes are started and are active in the cluster. |
| Comment by Deepti Dawar [ 21/May/13 ] |
|
One more observation, the client is only trying to insert data to the server nodes. Even if the primary node fails, it should not wait for the recovery of this node, instead should point to the other active node of the cluster and add the data there.
Not sure of the behavior here. Matt, can you please help me in understanding what should be the correct behavior in this case. |
| Comment by Deepti Dawar [ 21/May/13 ] |
| When all nodes are given as input, then also the behavior remains the same or even worse. Now getting the ConcurrentExecutionException while cancelling the connection to the primary node when it goes down. Attatched is the log. |
[JCBC-308] Trouble in resubscribing to primary node via cbc, when all servers go down one by one. Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | .next |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Deepti Dawar | Assignee: | Deepti Dawar |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
cbc_server_all_nodes_failure.log
|
| Description |
|
PFA the logs.
|
[JCBC-307] Hybrid workload with rebalance scenario - error in accessing view Created: 21/May/13 Updated: 21/May/13 Resolved: 21/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
HYBRID_rb-2-out_1.1.6_views_access_error.log
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Attached is the log and following is the stack trace -
SDKD: May 10, 2013 1:32:51 AM com.couchbase.sdkd.cbclient.CommandResult warnAbout SDKD: WARNING: Unknown exception encountered (for operation) future warnings will be suppressed SDKD: java.lang.RuntimeException: Failed to access the view SDKD: at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:871) SDKD: at com.couchbase.sdkd.cbclient.ViewQueryCommandContext.execIter(ViewQueryCommandContext.java:252) SDKD: at com.couchbase.sdkd.cbclient.CommandContext.execute(CommandContext.java:374) SDKD: at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:168) SDKD: at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:189) SDKD: at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:245) SDKD: Caused by: java.util.concurrent.ExecutionException: OperationException: SERVER: error Reason: A view spec can not consist of merges exclusively. SDKD: at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:90) SDKD: at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:74) SDKD: at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:64) SDKD: at com.couchbase.client.CouchbaseClient.query(CouchbaseClient.java:864) SDKD: ... 5 more SDKD: Caused by: OperationException: SERVER: error Reason: A view spec can not consist of merges exclusively. SDKD: at com.couchbase.client.protocol.views.NoDocsOperationImpl.parseError(NoDocsOperationImpl.java:106) SDKD: at com.couchbase.client.protocol.views.ViewOperationImpl.handleResponse(ViewOperationImpl.java:68) SDKD: at com.couchbase.client.ViewNode$MyHttpRequestExecutionHandler.handleResponse(ViewNode.java:204) SDKD: at org.apache.http.nio.protocol.AsyncNHttpClientHandler.processResponse(AsyncNHttpClientHandler.java:417) SDKD: at org.apache.http.nio.protocol.AsyncNHttpClientHandler.inputReady(AsyncNHttpClientHandler.java:242) SDKD: at com.couchbase.client.http.AsyncConnectionManager$ManagedClientHandler.inputReady(AsyncConnectionManager.java:249) SDKD: at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:172) SDKD: at org.apache.http.impl.nio.DefaultClientIOEventDispatch.inputReady(DefaultClientIOEventDispatch.java:155) SDKD: at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:161) SDKD: at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:335) SDKD: at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315) SDKD: at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:275) SDKD: at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) SDKD: at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:542) SDKD: at java.lang.Thread.run(Thread.java:619) |
| Comments |
| Comment by Michael Nitschinger [ 21/May/13 ] |
|
Hey,
this is a duplicate (tracked somewhere else, but I dont remeber the exact ticket) More importantly, this is a bug on the server side, we can't do much about it at the moment. Anyway, closing this since we don't want to track it twice! |
[JCBC-231] Handle View Errors (Vbucket & Merge) appropriately Created: 02/Feb/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.7 |
| 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: |
|
||||||||
| Description |
|
During rebalance out it can happen that the view node is still able to service http connections, but fails with the following errors:
- error Reason: A view spec can not consist of merges exclusively. or - no_active_vbuckets Reason: Cannot execute view query since the node has no active vbuckets If this is happening, the client needs to deal with it. Appropriate solution needs still to be dicussed, but one approach could be to retry on a different node. Note that this needs to work for both async and sync calls. |
| Comments |
| Comment by Michael Nitschinger [ 02/Feb/13 ] |
| The corresponding server ticket can be found here: http://www.couchbase.com/issues/browse/MB-7661 |
[JCBC-306] Add a method that returns the list of design document for a bucket Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
It would be great to add a method to return the list of design document for a bucket.
We should do something like: List< DesignDocument > client.getDesignDocuments() |
[JCBC-300] Add as Example: Java/NoSQL Tricks Created: 28/Mar/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Karen Zeller | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
http://www.infoworld.com/d/application-development/how-teach-java-ee-app-new-nosql-tricks-215277
|
| Comments |
| Comment by Karen Zeller [ 09/May/13 ] |
|
I'm not sure i would take this request as high priority, but back in March, someone (I can't remember) sent me an email saying we should add this type of content to our doc set. I would just keep this in your queue for now. It might just be more informational/inspirational......My suspicions is this is a priority 2. |
[JCBC-204] document increment/decrement behavior with non-numeric value Created: 02/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | 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-11] Need more unit tests for couchbase-client Created: 03/Feb/12 Updated: 20/May/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.1 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Raghavan Srinivas | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
CouchbaseConnectionFactoryBuilder cfb = new CouchbaseConnectionFactoryBuilder();
cfb.setOpTimeout(10000); // wait up to 10 seconds for an operation to succeed cfb.setOpQueueMaxBlockTime(5000); // wait up to 5 seconds when trying to enqueue an operation For example, will fill up the funnel (the blocking queue) to the rim, but not overflow (immediately timeout). Once it's at the rim, it'll have to wait to wait until at least one operation flows out to add another operation. This *will* slow down the callers (their async calls will actually block on this internal queue), but that's okay in a bulk loader. However, there are no unit tests in couchbase-client to test this. |
[JCBC-15] add showtype-options to documentation Created: 23/Feb/12 Updated: 20/May/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| 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-89] re-enable optimization after error handling in binary optimized sets is fixed in dependent spymemcached Created: 31/Jul/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.7 |
| 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-18] NPE if hostnames in server bootstrap list are mixed case Created: 12/Mar/12 Updated: 20/May/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Matt Ingenthron |
| 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-61] Expose returned CAS value in CASResponse when available from binary protocol Created: 06/Jun/12 Updated: 20/May/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Customer request to add the capability to retrieve new cas value after a cas() operation to avoid a subsequent gets()
|
| Comments |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| This may already be implemented, need to check. |
[JCBC-108] observe loop implementation behind mutations should be adaptive to server persistence latencies Created: 11/Sep/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| 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-76] Replica read command Created: 12/Jul/12 Updated: 20/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| 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 |
|
Implement a simple replica read command
|
| Comments |
| Comment by Matt Ingenthron [ 29/Aug/12 ] |
| See http://www.couchbase.com/wiki/display/couchbase/Replica+Read for details on implementation. |
| Comment by Raghavan Srinivas [ 14/Sep/12 ] |
| This will be experimental functionality for 1.1 |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| Moving to .next until it is decided if this will make it into 1.2 or not. |
| Comment by Matt Ingenthron [ 14/Feb/13 ] |
| Michael: this has come up again recently so if possible we'd like to get it in a build for testing soon and see about adding it as experimental, if not supported, in 1.1.3. |
[JCBC-83] replace use of java assert in tests with junit assertions, including messages Created: 12/Jul/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Mike Wiederhold | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| Moving to 1.1.2 because its a smaller change. |
[JCBC-114] Command Futures never receive results after rebalance-out (or other sorts of topology/network changes) Created: 17/Sep/12 Updated: 20/May/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.7 |
| 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: |
|
||||||||
| 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 [ 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-115] thoroughly test on_error arguments Created: 18/Sep/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| 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-116] Implement the ObserveSet for better observing of replication/persistence Created: 18/Sep/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| 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-117] mention that OperationFuture.get(tmo) changes state when timeout has been reached Created: 24/Sep/12 Updated: 20/May/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.7 |
| 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: |
|
||||||||
| 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-113] code injection during development/debug causing IllegalStateException Created: 13/Sep/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1dp, 1.1dp2, 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Minor |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Caused by: java.lang.IllegalStateException: Shutting down
at net.spy.memcached.MemcachedConnection.checkState(MemcachedConnection.java:824) ~[spymemcached-2.8.4.jar:2.8.4] at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:640) ~[spymemcached-2.8.4.jar:2.8.4] at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:841) ~[spymemcached-2.8.4.jar:2.8.4] at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1003) ~[spymemcached-2.8.4.jar:2.8.4] at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1024) ~[spymemcached-2.8.4.jar:2.8.4] It happens everytime I change the code in debug mode (JVM code injection) From thread: http://www.couchbase.com/forums/thread/java-client-issue-after-code-injection |
| Comments |
| Comment by Michael Nitschinger [ 16/Nov/12 ] |
| Asked "cb" on the forums for more information to be able to reproduce the issue. |
| Comment by cb [ 23/Dec/12 ] |
|
I tested on v1.1 and there are still issues:
Caused by: java.lang.IllegalStateException: Shutting down at net.spy.memcached.MemcachedConnection.checkState(MemcachedConnection.java:825) ~[spymemcached-2.8.9.jar:2.8.9] at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:641) ~[spymemcached-2.8.9.jar:2.8.9] at net.spy.memcached.MemcachedClient.asyncGetAndTouch(MemcachedClient.java:1284) ~[spymemcached-2.8.9.jar:2.8.9] at net.spy.memcached.MemcachedClient.getAndTouch(MemcachedClient.java:955) ~[spymemcached-2.8.9.jar:2.8.9] at net.spy.memcached.MemcachedClient.getAndTouch(MemcachedClient.java:978) ~[spymemcached-2.8.9.jar:2.8.9] at models.AdminUserSession.findByKey(AdminUserSession.java:35) ~[classes/:na] |
| Comment by Michael Nitschinger [ 24/Dec/12 ] |
|
Hi cb,
thanks for responding. Would it be possible to help me out reproducing it? What kind of setup are you using? (OS, IDE, App Server) and so on? I never encountered this in my environments here... thanks very much! |
| Comment by cb [ 24/Dec/12 ] |
|
Play Framewok 1.0.4
Couchbase 2 GA Java Client 1.1 You can use the example app that you created in your Blog Post. (BTW - Still looking forward for the rest of the parts of this super good post!!) Change something in the code - while running in sbt like this: ~run (note the "~") which tells sbt to inject any change into the running process. Let me know if you can reproduce the bug. |
| Comment by Michael Nitschinger [ 24/Dec/12 ] |
|
You mean 2.0.4?
Are you running on 1.6 or 1.7 java? Or which scala version? On which operating system are you running it? Never came across this (neither while working on the blog posts nor working on it from other apps). |
| Comment by cb [ 24/Dec/12 ] |
|
sorry 2.0.4
Jave Version: Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909) Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode) OSX 10.8.2 |
[JCBC-151] Client does timeout on connect in specific java environments (was believed to be java7 related). Created: 21/Nov/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Flagged: |
Release Note
|
| Description |
|
People report that the Client does not work with 1.7. Here is a sample stack trace:
2012-11-20 00:29:11.228 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/127.0.0.1:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-11-20 00:29:11.240 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3f757322 2012-11-20 00:29:11.502 INFO com.couchbase.client.ViewConnection: Added localhost/127.0.0.1:8092 to connect queue 2012-11-20 00:29:11.505 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode 2012-11-20 00:29:11.647 INFO net.spy.memcached.auth.AuthThread: Authenticated to localhost/127.0.0.1:11210 2012-11-20 00:29:12.051 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection 2012-11-20 00:29:12.060 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: localhost/127.0.0.1:8092 - Session request successful 2012-11-20 00:29:17.111 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [localhost/127.0.0.1:8092(closed)] java.lang.RuntimeException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:68) at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:428) at Example1.main(Example1.java:43) Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:80) at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:65) ... 2 more 2012-11-20 00:30:12.168 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client 2012-11-20 00:30:12.177 INFO com.couchbase.client.ViewNode: Couchbase I/O reactor terminated Disconnected from the target VM, address: '127.0.0.1:65280', transport: 'socket' Process finished with exit code 0 Also See http://www.couchbase.com/forums/thread/java-asyncconnectionmanager-timed-out-waiting-operation-please-help-console-log-included And http://stackoverflow.com/questions/13466010/using-java-api-in-scala-to-query-views-in-couchbase-throws-timeout-exception?utm_source=twitterfeed&utm_medium=twitter |
| Comments |
| Comment by Quinn Slack [ 27/Nov/12 ] |
|
This doesn't appear to be strictly related to Java7. I was able to get similar code to work on Java7. I even simulated loading a Play2 environment with other JARs that could potentially cause conflicts. It's possible that my simulation of the Play2 environment was insufficient and that Play2 does other stuff...
Code at https://github.com/sqs/couchbase-scala-example. Run with: CBURL=http://localhost:8091/pools CBPASSWORD=mypassword sbt -Dconfig.file=conf/application.conf '~run' Here is the output on my system that shows it's on Java7 (openjdk) and that shows the expected output from the views: on java version 1.7.0_09 [info] play - Application started (Prod) 2012-11-27 01:34:27.115 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/127.0.0.1:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-11-27 01:34:27.120 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@6267e5a2 2012-11-27 01:34:27.147 INFO com.couchbase.client.ViewConnection: Added localhost/127.0.0.1:8092 to connect queue 2012-11-27 01:34:27.149 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode 2012-11-27 01:34:27.176 INFO net.spy.memcached.auth.AuthThread: Authenticated to localhost/127.0.0.1:11210 2012-11-27 01:34:27.282 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection 2012-11-27 01:34:27.288 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: localhost/127.0.0.1:8092 - Session request successful Res = List(com.couchbase.client.protocol.views.ViewRowNoDocs@4667820f, com.couchbase.client.protocol.views.ViewRowNoDocs@358bcae5, com.couchbase.client.protocol.views.ViewRowNoDocs@6cb59bd9, com.couchbase.client.protocol.views.ViewRowNoDocs@70afb51, com.couchbase.client.protocol.views.ViewRowNoDocs@61f98673) 2012-11-27 01:34:27.396 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client 2012-11-27 01:34:27.403 INFO com.couchbase.client.ViewNode: Couchbase I/O reactor terminated |
| Comment by Michael Nitschinger [ 27/Nov/12 ] |
| Are you running on jdk7 on mac? Also, when you use play 2.1 it should work. Play2-related issues more were because of netty version incompatibilities. |
| Comment by Quinn Slack [ 27/Nov/12 ] |
|
This is jdk7 on Arch Linux and Play 2.1-RC1.
I tried using a different netty, but no luck. What worked for me was moving calls to "new CouchbaseClient" out of static "object" initializers, since they appeared to be getting called in the Netty I/O thread (I got this exception in new CouchbaseClient: java.lang.IllegalStateException: await*() in I/O thread causes a dead lock or sudden performance drop. Use addListener() instead or call await*() from a different thread). |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| Hi Quinn, this issue is a different one! The issue described here is that people seem to find connection timeouts with java 7. |
| Comment by Quinn Slack [ 28/Nov/12 ] |
| They may be related--or may just have similar symptoms. I was not getting timeout exceptions, but I was seeing view requests hang indefinitely until I made the fix described above. |
| Comment by dragos [ 13/Mar/13 ] |
|
Hi Michael, can you help with this error ? I am trying to find a workaround or something to work. This is the only thing which is keeping us from using Couchbase. I also posted here : http://www.couchbase.com/forums/thread/couchbase-connectivity-problem-aws-vpc . As you can see in the times the timeout is received really fast. 2013-03-13 11:40:47.702 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/10.0.X.XXX:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2013-03-13 11:40:52.712 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@5cbfe9d 2013-03-13 11:40:52.840 INFO net.spy.memcached.auth.AuthThread: Authenticated to 10.0.X.XXX/10.0.X.XXX:11210 2013-03-13 11:40:57.860 INFO com.couchbase.client.ViewConnection: Added 10.0.X.XXX to connect queue 2013-03-13 11:40:57.863 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode 2013-03-13 11:40:58.070 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection 2013-03-13 11:40:58.077 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: /10.0.X.XXX:8092 - Session request successful 2013-03-13 11:41:03.113 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [10.0.X.XXX/10.0.X.XXX:8092] Exception in thread "main" java.lang.RuntimeException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:67) at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:475) at couchbase.training.view.poc.CouchbasePOC.main(CouchbasePOC.java:63) Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:85) at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:74) at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:64) |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hi dragos, can you please post the full code where you connect to couchbase? (including factories and such) Thanks! |
| Comment by dragos [ 13/Mar/13 ] |
|
Hi Mike, this is the POC client for Couchbase: package couchbase.training.view.poc; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.net.URI; import java.util.LinkedList; import java.util.List; import java.util.concurrent.TimeUnit; import org.apache.commons.io.IOUtils; import org.json.JSONException; import org.json.XML; import com.couchbase.client.CouchbaseClient; import com.couchbase.client.CouchbaseConnectionFactory; import com.couchbase.client.CouchbaseConnectionFactoryBuilder; import com.couchbase.client.protocol.views.ComplexKey; import com.couchbase.client.protocol.views.Query; import com.couchbase.client.protocol.views.Stale; import com.couchbase.client.protocol.views.View; import com.couchbase.client.protocol.views.ViewResponse; import com.couchbase.client.protocol.views.ViewRow; public class CouchbasePOC { public static void main(String[] args) throws FileNotFoundException, JSONException, IOException { System.out.println("Hello from CouchBase"); // Set the URIs and get a client final List<URI> uris = new LinkedList<URI>(); // Connect to localhost or to the appropriate URI(s) uris.add(URI.create("http://10.0.7.164:8091/pools")); final String mappedName="problems"; long start = System.currentTimeMillis(); CouchbaseConnectionFactoryBuilder m_couchbaseConnectionFactoryBuilder = new CouchbaseConnectionFactoryBuilder(); m_couchbaseConnectionFactoryBuilder.setMaxReconnectDelay(10000); m_couchbaseConnectionFactoryBuilder.setOpQueueMaxBlockTime(100); m_couchbaseConnectionFactoryBuilder.setOpTimeout(20000); m_couchbaseConnectionFactoryBuilder.setShouldOptimize(true); m_couchbaseConnectionFactoryBuilder.setViewTimeout(300000); CouchbaseConnectionFactory connFactory = m_couchbaseConnectionFactoryBuilder.buildCouchbaseConnection(uris, mappedName, ""); CouchbaseClient client = null; try { client = new CouchbaseClient(connFactory); } catch (IOException e) { System.err.println("IOException connecting to Couchbase: " + e.getMessage()); System.exit(1); } final View view = client.getView(mappedName, mappedName); final Query query = new Query(); final ComplexKey key = ComplexKey.of("problem",null,null,null,null); query.setKey(key); query.setStale( Stale.UPDATE_AFTER ); int counter=0; try { final ViewResponse result = client.query(view, query); for(ViewRow row : result) { counter++; System.out.println(row.getId()); } } catch(java.lang.VerifyError e) { System.out.println("Error: " + e.getMessage()); } System.out.println("time: " + (System.currentTimeMillis()-start) ); System.out.println("documents: " + counter ); client.shutdown(3, TimeUnit.SECONDS); System.exit(0); } } |
| Comment by dragos [ 13/Mar/13 ] |
| I hope you would not mind that i called you Mike and not Michael. |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hehe no worries. Can you do me a favor and remove the factory for a second and just use CouchbaseClient() without anything else? Let me know if the problem still persists or not! Thanks |
| Comment by dragos [ 13/Mar/13 ] |
|
Hi Michael, First i want to thank you for the quick feed-back. Your owesome !!! Before using the factory i used the CouchbaseClient(uris, bucketName, "") which is also timing out. I added the factory to be able increase the timeout times for the connection but still the same problem. |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hmm okay, so its not the factory (we had some issues with default values in the past, thats why I'm asking). Can you pin me down your operating system and exact java version you're using?Thanks for your help! |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Also, since you're so responsive (I hope we can pin this down finally!).. Can you run the same code with DEBUG log enabled (see https://code.google.com/p/spymemcached/wiki/Logging).. just use Logger.getLogger("com.couchbase.client").setLevel(Level.FINEST); instead of Logger.getLogger("net.spy.memcached").setLevel(Level.FINEST); Thanks! |
| Comment by dragos [ 13/Mar/13 ] |
|
This is my test environment for the client which will be similar for production. OS Ubuntu Server 11.10 x64 java -version result: java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) My network infrastructure is like this: In an AWS virtual private center (VPC) i have a subnet and in this subnet there are 2 machines. The client machine and the Couchbase server. The machines have identical OS and java version as mentioned above. I have open the ports and also checked the network ACL. The traffic is free to go,no restriction. If i am using a rest query with curl for the view i receive the result, the problem is only in the java SDK. If needed more information please ask. I will gladly offer it. |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hi Dragos,
yes, if you can please rerun the script with DEBUG logging enabled (see last comment).. Thanks very much in advance! |
| Comment by dragos [ 13/Mar/13 ] |
|
I've setted the logger to finest and this is the error log obtained. Also i tested again the connection with curl and no problemes. Mar 13, 2013 1:30:14 PM com.couchbase.client.CouchbaseProperties setPropertyFile INFO: Could not load properties file "cbclient.properties" because: File not found with system classloader. 2013-03-13 13:30:14.679 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2013-03-13 13:30:19.689 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@4e99353f 2013-03-13 13:30:19.810 INFO net.spy.memcached.auth.AuthThread: Authenticated to 10.0.7.164/10.0.7.164:11210 2013-03-13 13:30:24.828 INFO com.couchbase.client.ViewConnection: Added 10.0.7.164 to connect queue 2013-03-13 13:30:24.830 INFO com.couchbase.client.CouchbaseClient: viewmode property isn't defined. Setting viewmode to production mode 2013-03-13 13:30:25.025 INFO com.couchbase.client.http.AsyncConnectionManager: Opening new Couchbase HTTP connection 2013-03-13 13:30:25.033 INFO com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback: /10.0.7.164:8092 - Session request successful 2013-03-13 13:30:30.083 ERROR com.couchbase.client.ViewNode$EventLogger: Connection timed out: [10.0.7.164/10.0.7.164:8092] Exception in thread "main" java.lang.RuntimeException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:67) at com.couchbase.client.CouchbaseClient.getView(CouchbaseClient.java:475) at couchbase.training.view.poc.CouchbasePOC.main(CouchbasePOC.java:68) Caused by: java.util.concurrent.TimeoutException: Timed out waiting for operation at com.couchbase.client.internal.HttpFuture.waitForAndCheckOperation(HttpFuture.java:85) at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:74) at com.couchbase.client.internal.HttpFuture.get(HttpFuture.java:64) ... 2 more curl result curl http://10.0.7.164:8092/problems/_design/dev_problems/_view/problems?stale=false\&connection_timeout=60000\&limit=10\&skip=0 {"total_rows":0,"rows":[ ] } [4]+ Done |
| Comment by dragos [ 13/Mar/13 ] |
| I am available for next steps in debuging. With what can i help next ? |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hi, hmm no there should be more output (DEBUG), not just info... you need to copy this whole snippet before your code actually executes: // Tell spy to use the SunLogger Properties systemProperties = System.getProperties(); systemProperties.put("net.spy.log.LoggerImpl", "net.spy.memcached.compat.log.SunLogger"); System.setProperties(systemProperties); Logger.getLogger("com.couchbase.client").setLevel(Level.FINEST); //get the top Logger Logger topLogger = java.util.logging.Logger.getLogger(""); // Handler for console (reuse it if it already exists) Handler consoleHandler = null; //see if there is already a console handler for (Handler handler : topLogger.getHandlers()) { if (handler instanceof ConsoleHandler) { //found the console handler consoleHandler = handler; break; } } if (consoleHandler == null) { //there was no console handler found, create a new one consoleHandler = new ConsoleHandler(); topLogger.addHandler(consoleHandler); } //set the console handler to fine: consoleHandler.setLevel(java.util.logging.Level.FINEST); I guess you're running it from your IDE? |
| Comment by dragos [ 13/Mar/13 ] |
|
I am building the client on local IDE then uploading it to EC2 test machine. The snipped of code word and now i have a full log. Mar 13, 2013 1:53:10 PM com.couchbase.client.CouchbaseProperties setPropertyFile INFO: Could not load properties file "cbclient.properties" because: File not found with system classloader. Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP readToString FINE: Attempting to read configuration from URI: http://10.0.7.164:8091/pools Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP readToString FINE: Attempting to read configuration from URI: http://10.0.7.164:8091/pools/default?uuid=44b1e62dd7e65cd38ae7faaabe5ebb64 Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP readToString FINE: Attempting to read configuration from URI: http://10.0.7.164:8091/pools/default/buckets?v=120523822&uuid=44b1e62dd7e65cd38ae7faaabe5ebb64 Mar 13, 2013 1:53:11 PM net.spy.memcached.MemcachedConnection createConnections INFO: Added {QA sa=/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue Mar 13, 2013 1:53:11 PM com.couchbase.client.vbucket.VBucketNodeLocator fillNodesEntries FINE: Updating nodesMap in VBucketNodeLocator. Mar 13, 2013 1:53:16 PM com.couchbase.client.vbucket.VBucketNodeLocator fillNodesEntries FINE: Adding node with address 10.0.7.164:11210. Mar 13, 2013 1:53:16 PM com.couchbase.client.vbucket.VBucketNodeLocator fillNodesEntries FINE: Node added is {QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8}. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Done dealing with queue. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selecting with delay of 0ms Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selected 1, selected 1 keys Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Handling IO for: sun.nio.ch.SelectionKeyImpl@2c76e369 (r=false, w=false, c=true, op={QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8}) Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@2c76e369 Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection insertOperation FINE: Added Cmd: 10 Opaque: 1 to {QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=0, #iq=1, topRop=null, topWop=null, toWrite=0, interested=8} Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads FINE: Read 24 bytes Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads FINE: Completed read op: Cmd: 10 Opaque: 1 and giving the next 0 bytes Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleInputQueue FINE: Handling queue Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Done dealing with queue. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selecting with delay of 0ms Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: No selectors ready, interrupted: false Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Done dealing with queue. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selecting with delay of 0ms Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: No selectors ready, interrupted: false Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleInputQueue FINE: Handling queue Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Done dealing with queue. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selecting with delay of 0ms Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selected 1, selected 1 keys Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection insertOperation FINE: Added SASL auth operation to {QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL auth operation, toWrite=0, interested=4} Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Handling IO for: sun.nio.ch.SelectionKeyImpl@2c76e369 (r=false, w=true, c=false, op={QA sa=10.0.7.164/10.0.7.164:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=SASL auth operation, toWrite=0, interested=4}) Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Done dealing with queue. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selecting with delay of 0ms Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selected 1, selected 1 keys Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Handling IO for: sun.nio.ch.SelectionKeyImpl@2c76e369 (r=true, w=false, c=false, op={QA sa=10.0.7.164/10.0.7.164:11210, #Rops=1, #Wops=0, #iq=0, topRop=SASL auth operation, topWop=null, toWrite=0, interested=1}) Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads FINE: Read 37 bytes Mar 13, 2013 1:53:16 PM net.spy.memcached.auth.AuthThread$1 receivedStatus INFO: Authenticated to 10.0.7.164/10.0.7.164:11210 Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleReads FINE: Completed read op: SASL auth operation and giving the next 0 bytes Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Done dealing with queue. Mar 13, 2013 1:53:16 PM net.spy.memcached.MemcachedConnection handleIO FINE: Selecting with delay of 0ms Mar 13, 2013 1:53:21 PM com.couchbase.client.ViewConnection createConnections INFO: Added 10.0.7.164 to connect queue Mar 13, 2013 1:53:21 PM com.couchbase.client.CouchbaseClient <init> INFO: viewmode property isn't defined. Setting viewmode to production mode Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ConfigurationProviderHTTP subscribe FINE: Subscribing an object for reconfiguration updates com.couchbase.client.CouchbaseClient Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream FINEST: Channel state changed: [id: 0x2e273686] OPEN Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream FINER: Channel state change is not a disconnect. Event value is true and Channel State is OPEN. Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream FINEST: Channel state changed: [id: 0x2e273686, /10.0.7.213:55729 => /10.0.7.164:8091] BOUND: /10.0.7.213:55729 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream FINER: Channel state change is not a disconnect. Event value is /10.0.7.213:55729 and Channel State is BOUND. Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream FINEST: Channel state changed: [id: 0x2e273686, /10.0.7.213:55729 => /10.0.7.164:8091] CONNECTED: /10.0.7.164:8091 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler handleUpstream FINER: Channel state change is not a disconnect. Event value is /10.0.7.164:8091 and Channel State is CONNECTED. Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: STATUS: 200 OK Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: VERSION: HTTP/1.1 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: HEADER: Cache-Control = no-cache Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: HEADER: Content-Type = application/json; charset=utf-8 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: HEADER: Date = Wed, 13 Mar 2013 13:55:42 GMT Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: HEADER: Pragma = no-cache Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: HEADER: Server = Couchbase Server 2.0.0-1976-rel-enterprise Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: HEADER: Transfer-Encoding = chunked Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: CHUNKED CONTENT { Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: {"name":"problems","bucketType":"membase","authType":"sasl","saslPassword":"","proxyPort":0,"replicaIndex":false,"uri":"/pools/default/buckets/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","streamingUri":"/pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","localRandomKeyUri":"/pools/default/buckets/problems/localRandomKey","controllers":{"compactAll":"/pools/default/buckets/problems/controller/compactBucket","compactDB":"/pools/default/buckets/problems/controller/compactDatabases"},"nodes":[{"couchApiBase":"http://10.0.7.164:8092/problems","replication":0.0,"clusterMembership":"active","status":"healthy","thisNode":true,"hostname":"10.0.7.164:8091","clusterCompatibility":131072,"version":"2.0.0-1976-rel-enterprise","os":"x86_64-unknown-linux-gnu","ports":{"proxy":11211,"direct":11210}}],"stats":{"uri":"/pools/default/buckets/problems/stats","directoryURI":"/pools/default/buckets/problems/statsDirectory","nodeStatsListURI":"/pools/default/buckets/problems/nodes"},"ddocs":{"uri":"/pools/default/buckets/problems/ddocs"},"nodeLocator":"vbucket","autoCompactionSettings":false,"fastWarmupSettings":false,"uuid":"7675b7791efe17220792c2b41ff6c824","vBucketServerMap":{"hashAlgorithm":"CRC","numReplicas":1,"serverList":["10.0.7.164:11210"],"vBucketMap":[[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[ Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: Chunk length is: 3066 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: 0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: Chunk length is: 2048 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: ],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,- Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: Chunk length is: 3072 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: 1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1]]},"bucketCapabilitiesVer":"","bucketCapabilities":["touch","couchapi"]} Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketUpdateResponseHandler finerLog FINER: Chunk length is: 361 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.BucketMonitor logFiner FINER: Getting server list returns this last chunked response: {"name":"problems","bucketType":"membase","authType":"sasl","saslPassword":"","proxyPort":0,"replicaIndex":false,"uri":"/pools/default/buckets/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","streamingUri":"/pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824","localRandomKeyUri":"/pools/default/buckets/problems/localRandomKey","controllers":{"compactAll":"/pools/default/buckets/problems/controller/compactBucket","compactDB":"/pools/default/buckets/problems/controller/compactDatabases"},"nodes":[{"couchApiBase":"http://10.0.7.164:8092/problems","replication":0.0,"clusterMembership":"active","status":"healthy","thisNode":true,"hostname":"10.0.7.164:8091","clusterCompatibility":131072,"version":"2.0.0-1976-rel-enterprise","os":"x86_64-unknown-linux-gnu","ports":{"proxy":11211,"direct":11210}}],"stats":{"uri":"/pools/default/buckets/problems/stats","directoryURI":"/pools/default/buckets/problems/statsDirectory","nodeStatsListURI":"/pools/default/buckets/problems/nodes"},"ddocs":{"uri":"/pools/default/buckets/problems/ddocs"},"nodeLocator":"vbucket","autoCompactionSettings":false,"fastWarmupSettings":false,"uuid":"7675b7791efe17220792c2b41ff6c824","vBucketServerMap":{"hashAlgorithm":"CRC","numReplicas":1,"serverList":["10.0.7.164:11210"],"vBucketMap":[[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1],[0,-1]]},"bucketCapabilitiesVer":"","bucketCapabilities":["touch","couchapi"]} Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update FINEST: Received an update, notifying reconfigurables about a com.couchbase.client.vbucket.config.Bucketcom.couchbase.client.vbucket.config.Bucket@4cf3fdc4 Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update FINEST: It says it is problems and it's talking to /pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824 Mar 13, 2013 1:53:21 PM com.couchbase.client.CouchbaseConnection reconfigure FINE: Node 10.0.7.164/10.0.7.164:11210 will stay in cluster config after reconfiguration. Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.VBucketNodeLocator updateLocator FINE: Received updated configuration with insignificant changes. Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update FINEST: Received an update, notifying reconfigurables about a com.couchbase.client.vbucket.config.Bucketcom.couchbase.client.vbucket.config.Bucket@fadb83cf Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.ReconfigurableObserver update FINEST: It says it is problems and it's talking to /pools/default/bucketsStreaming/problems?bucket_uuid=7675b7791efe17220792c2b41ff6c824 Mar 13, 2013 1:53:21 PM com.couchbase.client.CouchbaseConnection reconfigure FINE: Node 10.0.7.164/10.0.7.164:11210 will stay in cluster config after reconfiguration. Mar 13, 2013 1:53:21 PM com.couchbase.client.vbucket.VBucketNodeLocator updateLocator FINE: Received updated configuration with insignificant changes. Mar 13, 2013 1:53:21 PM com.couchbase.client.http.AsyncConnectionManager processConnectionRequests INFO: Opening new Couchbase HTTP connection Mar 13, 2013 1:53:21 PM com.couchbase.client.http.AsyncConnectionManager$ConnRequestCallback completed INFO: /10.0.7.164:8092 - Session request successful Mar 13, 2013 1:53:21 PM com.couchbase.client.ViewNode$EventLogger connectionOpen FINE: Connection open: [/10.0.7.164:8092] Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionTimeout SEVERE: Connection timed out: [10.0.7.164/10.0.7.164:8092] Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionClosed FINE: Connection closed: [10.0.7.164/10.0.7.164:8092(closed)] |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hi, thanks for the log.. interestingly, there is nothing unusual in this.. I'll investigate further and come back to you if I need more info.. thanks so far! |
| Comment by dragos [ 13/Mar/13 ] |
| Thank you for spending time on this. Looking forward for a fix :) . |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
interestingly, the connection is open and then times out... INFO: /10.0.7.164:8092 - Session request successful Mar 13, 2013 1:53:21 PM com.couchbase.client.ViewNode$EventLogger connectionOpen FINE: Connection open: [/10.0.7.164:8092] Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionTimeout SEVERE: Connection timed out: [10.0.7.164/10.0.7.164:8092] Mar 13, 2013 1:53:26 PM com.couchbase.client.ViewNode$EventLogger connectionClosed FINE: Connection closed: [10.0.7.164/10.0.7.164:8092(closed)] this sounds highly suspicious to me, maybe this is a bug in apache httpcore-nio... |
| Comment by dragos [ 13/Mar/13 ] |
| The time out is displayed after 5 seconds. As you suggested i removed the factory and the detailed logged above i obtained with using CouchbaseClient(uris, mappedName, ""). Do you have some way of testing the httpCore-nio ? Should i try to look for latest version of httpCore-nio.. ? |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hi, yes you could try that.. I ran the test suite with 4.2.3 which is the latest one and there were no errors, so our code should work with it. You need to exchange the httpcore and httpcore-nio with the latest 4.2.3 jars I don't think this is 100% the issue, but it helps us get rid of one more factor! Thanks! Michael |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Okay, the 5 second period can come from this: HttpParams params = new SyncBasicHttpParams(); params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, 5000) .setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, 5000) .... SO_TIMEOUT is: Defines the socket timeout (SO_TIMEOUT) in milliseconds, which is the timeout for waiting for data or, put differently, a maximum period inactivity between two consecutive data packets). and CONNECTION_TIMEOUT is: Determines the timeout in milliseconds until a connection is established. Dragos, can it be the case that it takes more than 5 seconds to return a result when using curl or so? That would explain the "fail fast" timeout here.. not saying that these times are okay this way, just to find the root cause.. Thanks! |
| Comment by dragos [ 13/Mar/13 ] |
|
Hi Michael, I've made a test with httpcore-nio-4.2.jar and with httpcore-4.2.1.jar and your intuition is good. The httpcore is not the problem because the timeout is still there. With curl the results is back fast, in less then half a second. So the problem must be somewhere in the java SDK in the way the view is retrieved. |
| Comment by dragos [ 13/Mar/13 ] |
| I've moved the Couchbase server to the same machine as the client to have all in same environment for testing. Now all is working fine but it is not possible for our product to stay on the same machine as Couchbase server for obvious reasons. In production we will have more then one app machine which we will try to access the Couchbase cluster. |
| Comment by Michael Nitschinger [ 13/Mar/13 ] |
|
Hi Dragos, okay so its definitely something with those timeouts.. The thing is we can increase them for sure, but the question is if it would work for your application given the long network latency - and if your application stays performant that way. When you're running curl on a request, how long does it take? |
| Comment by dragos [ 14/Mar/13 ] |
|
The curl request is very fast (a few milliseconds, and less then 0.5 seconds i am sure) and the network latency it is not a problem. Some how the couchbase client is taking to much time connecting. When it need to connect to a network machine in the same lan it takes more then 10 seconds. I experimented this in EC2 environment and on my local machine with a VM. If couchbase is local with the test app, the couchbase client is connecting fast. Do you have any points on how a connection should be setup for couchbase client ? I am trying to use the factory builder and the connection factory from java sdk but still with no success. |
| Comment by Tim Smith [ 14/Mar/13 ] |
|
Dragos, I can think of two separate things to try. One is to increase the SO_TIMEOUT to 8000, CONNECTION_TIMEOUT to 12000. Identify what's being hit. Probably more effective would be to use Wireshark to capture all traffic on the client machine, and see what is really happening. Start the capture (with tshark command-line tool, for example), then run the test client, let it time out, then run the curl command, let it succeed, then stop the capture. Gzip the capture data and attach it to this issue. Tim |
| Comment by dragos [ 14/Mar/13 ] |
|
Hi Tim, I've started some load tests to be able to evaluate Couchbase, so this means i moved Couchbase server on the same machine as the load test client. I tried to use a pool of couchbase clients always connected to the server, and after a while the test failed because couldn't create more connections. From my initial research i seen that couchbase client is managing his own connection can you tell me how this is done or what are the policies of shutting down connections ? Can you point me to some best practices for couchbase client connectivity ? |
| Comment by Tim Smith [ 14/Mar/13 ] |
|
I will handle that question about connection pooling, etc., separately, since it is unrelated to this bug about timeouts. On this specific bug report, the current state as I understand it is that: curl returns very quickly with the correct results. The Java client times out after 5 seconds without returning the results. My suggestion is to set up a very simple Java client that performs a single view query, and to get a packet capture of both curl and the Java client, to identify what the two are doing differently and why the curl succeeds but the Java client fails. |
| Comment by Jahangir Zinedine [ 27/Mar/13 ] |
|
Hi Michael, Any update on this issue? I faced the same issue and here is my environment: JRuby 1.7.3 Oracle JDK 1.7(with 1.6 the same thing happened) Couchbase 2.0.1 Java SDK 1.1.3(with 1.1.4 the same thing happened) And latest netty and http-core and other jar files. Appreciate your help. Thanks, Jani |
| Comment by dragos [ 01/Apr/13 ] |
|
Hi All, Finally after a long time i found the workaround needed for the java client to not timeout. As has been suggested by the Couchbase team to use a host name for the Couchabase server i applied the same fix but to the client machine. Meaning on the client machine were the java Couchbase client was timing out ( in Amazon VPC ) we added a hostname for the Couchbase server. Our test URI from http://10.0.7.164:8091/pools has become http://couchbase:8091/pools. This workaround is also fixing a 10 seconds connectivity for the client. On Ubuntu the hostname file is at: /etc/hosts On Windows 7 the hostname file is at: C:\Windows\system32\drivers\etc\hosts Example of host name entry in client machine: 10.0.7.146 couchbase |
| Comment by Michael Nitschinger [ 02/Apr/13 ] |
|
Thanks very much dragos for tracking this down! Does this mean that in your environment after the change, you're not seeing any performance impact anymore? Everything works as expected and performant? Thanks! |
| Comment by dragos [ 02/Apr/13 ] |
|
Hi Michael, In this moment the client does not time out and the time taken by java couchbase client to connect takes around 1.5 seconds from 10 seconds which we can consider a normal behavior. As for performance with this workaround we can continue the POC and evaluate the performance. As a first impression i can say that we see a good speed but i will keep my reservation until final POC is tested and we can achieve a full load test. What i want to emphasize that this is a welcomed workaround but it is not a solution on a longer term for our cloud production site. In a scenario where we need to create new machines and maybe new couchbase clusters it involves manual or specific automatic changes to the hosts file and of course extra managing of this. Bottom line is that we are waiting the fix on the couchbase java sdk 1.1.5 which will make this workaround obsolete. Also i feel the need to mention that this workaround was found in collaboration with the Couchbase team which provided the basic information for the workaround to be found, so thank you guys. |
| Comment by Michael Nitschinger [ 02/Apr/13 ] |
|
Hi Dragos, I'm not sure if there is a thing that we can fix inside the client when this is a DNS/hostname resolution issue with the OS and amazon? We would definitely need to investigate further, but all that the client does is try to use the hostname/IP provided during bootstrap. If nothing comes back or the host can't be found, we can't do much about it. Anyway, I think we need to do some more investigation here to really see whats the problem. |
[JCBC-138] Java Client does not recover when only bootstrap node provided and failovered Created: 05/Nov/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp3, 1.1-dp4 |
| Fix Version/s: | 1.1.7 |
| 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 |
|
Within the current implementation, when the bootstrap node is failovered/removed (and only that one is provided in the list) it gets correctly removed from the SDK, but either a new try to get a different streaming connection fails or something else is wrong.
Even when the node is added back into the cluster no new view connection is created (most arguably because no map updates are received anymore). This issue may also be the cause for other bugs related to failover scenarios reported. |
[JCBC-164] Support CAS for delete operation Created: 04/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-beta |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | schp | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
It would be nice if the DELETE operation would support a CAS parameter, a feature which is available in e. g. the Ruby client library. Without the possibility for checking for a given CAS value it may happen that a DELETE removes a key-value pair which was just updated by an other thread.
|
| Comments |
| Comment by Michael Nitschinger [ 04/Dec/12 ] |
|
Thanks for your input!
I'll discuss this and then get back to you in this ticket! |
| Comment by Michael Nitschinger [ 19/Dec/12 ] |
| What do you think about this? |
| Comment by Matt Ingenthron [ 19/Dec/12 ] |
| I do think it makes sense, and it's in there actually for operations with durability requirements. |
[JCBC-166] sync up the getting started guide on the web page to the docs Created: 05/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| 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 |
|
http://www.couchbase.com/develop/java/current should be a perfect subset of the getting started in the docs repo
|
[JCBC-169] add overloaded methods for various types to the Query class Created: 06/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| 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-161] Remove Duplication in Observe checks Created: 03/Dec/12 Updated: 20/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The fix for |
| Comments |
| Comment by Michael Nitschinger [ 13/May/13 ] |
| http://review.couchbase.org/#/c/26261/ |
| Comment by Michael Nitschinger [ 13/May/13 ] |
| Note that the new mechanism was implemented in a different changeset, and by now we had both in place behind one after another. since the other one was more accurate, the general one will be removed in favor of the other one. |
[JCBC-196] append/incr/decr/add/replace should not require CAS value to be passed Created: 21/Jun/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs, library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
In the current implementation, there is no method for a non-CAS version of the append/prepend/incr/decr/add/replace operations. As per the memcached protocol, these operations do not require (but may be used with) a CAS id and requiring one greatly reduces the performance available by requiring a gets prior to the operation.
Perry |
| Comments |
| Comment by Raghavan Srinivas [ 22/Aug/12 ] |
|
The incr, decr, add and replace do have calls that do not require CAS Id. For the append and prepend methods
you could do something like this c.prepend(0, "prepend-key", "value"); which would not require a CAS to be supplied/fetched. Will this suffice for now? My suggestion would be to close this issue and open a separate issue for just append and prepend if it's still deemed a bug. |
| Comment by Michael Nitschinger [ 21/Dec/12 ] |
| http://review.couchbase.org/#/c/23486/ |
| Comment by Perry Krug [ 21/Dec/12 ] |
| This will need a docs update as well... |
| Comment by Perry Krug [ 06/Feb/13 ] |
| Michael, just to add here, I think it would be sufficient to document this rather than changing the API itself. Documenting that you can (and should!) pass 0 for the CAS value when using these operations. |
[JCBC-171] document how to set config options in xml config files, and all config options available Created: 06/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.0.3 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 80h | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | 80h | ||
| Description |
|
I can't find any info on our web site, docs, tutorials, etc. for how how to set config options for Java client usage in an xml config file. Need examples of that, and exhaustive reference of all the options that can go in a config, along the lines of what we have for the CouchbaseConnectionFactoryBuilder class at:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-ccfb.html Also, it's very confusing to have 1.1 docs with useful info that applies to 1.0 docs, too, but have the 1.0 docs not updated. For example, there's no mention in the 1.0 docs of any of the stuff that is mentioned on the 1.1 sdk-ccfb page, even though lots of that would be relevant to 1.0 too. |
[JCBC-173] flush will not work owing to MB-7381 Created: 07/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| 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 | ||
| Issue Links: |
|
||||||||||||||||
| Flagged: |
Release Note
|
||||||||||||||||
| Description |
|
During development of 1.1, RESTful flush was written, but it turns out that there is an issue with the server implementation of flush, and it requires Administrator level credentials. This makes it impractical for clients that don't have those credentials, like a default CouchbaseClient.
This means the flush implementation is done, but won't work for now. |
| Comments |
| Comment by Matt Ingenthron [ 07/Dec/12 ] |
| Using the ClusterManager interface, one can work around this issue for now if using the Administrator creds is acceptable. |
[JCBC-183] Many methods in api reference don't link to corresponding documentation page Created: 14/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Smith | 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-184] API reference should show return types Created: 14/Dec/12 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | 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-189] Views having odd timeout issues on some clusters Created: 18/Dec/12 Updated: 20/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| 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 | ||
| Attachments: |
failover-debug.args
fo-dbg.log.txt
vm-4nodes-2.ini
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
We're seeing really strange timeout issues which seem to affect only this specific cluster and only in terms of views. We've re-installed this cluster time and time again, and we've had similar configurations run successfully as well.
More details in comment.. |
| Comments |
| Comment by Mark Nunberg [ 18/Dec/12 ] |
| Just try to do this with a simple java script (i.e. connect and query the view) |
| Comment by Deepti Dawar [ 20/Dec/12 ] |
|
This issue persists when the view retrieval is ran from standalone java program as well.
I tried this on both the VMs - 10.3.3.203, 10.3.3.209. |
| Comment by Deepti Dawar [ 20/Dec/12 ] |
| Its working fine for server deployed on localhost. |
| Comment by Matt Ingenthron [ 02/Jan/13 ] |
| Michael: found out today that this is a large issue for SDKQE. Can you have a quick look at this in the next day? You may find the underlying issue. |
| Comment by Michael Nitschinger [ 03/Jan/13 ] |
| Please pass me the script as commented and then (or if you can't) please assign it back to me! Thanks |
| Comment by Michael Nitschinger [ 18/Jan/13 ] |
|
According to the posted logs, it looks like debugging was not turned on. Can you please run this again with debugging turned on? To get the full logs to STDOUT, use this before initializing the CouchbaseClient in The App:
// Tell spy to use the SunLogger Properties systemProperties = System.getProperties(); systemProperties.put("net.spy.log.LoggerImpl", "net.spy.memcached.compat.log.SunLogger"); System.setProperties(systemProperties); Logger.getLogger("com.couchbase.client").setLevel(Level.FINEST); //get the top Logger Logger topLogger = java.util.logging.Logger.getLogger(""); // Handler for console (reuse it if it already exists) Handler consoleHandler = null; //see if there is already a console handler for (Handler handler : topLogger.getHandlers()) { if (handler instanceof ConsoleHandler) { //found the console handler consoleHandler = handler; break; } } if (consoleHandler == null) { //there was no console handler found, create a new one consoleHandler = new ConsoleHandler(); topLogger.addHandler(consoleHandler); } //set the console handler to fine: consoleHandler.setLevel(java.util.logging.Level.FINEST); Would be great if we can get all the output so we can investigate where the timeouts come from. I'm sure with a debug log it will be much easier. Thanks! |
| Comment by Mark Nunberg [ 23/Jan/13 ] |
|
So this bug isn't such an "unknown" anymore, and has exposed itself in 1.1.0 as well as 1.1.1 and isn't limited to particular clusters - (it just seems that some clusters are more likely than others to trigger this bug).
However this still needs a lot of care and analysis |
| Comment by Michael Nitschinger [ 01/Feb/13 ] |
| This is "kinda" blocker. |
[JCBC-199] constructor documented as client method returning "(none)" Created: 02/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tim Smith | 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-201] All async ops should link to the Asynchronous Operations page Created: 02/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | 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-203] append/prepend are ASYNC, and can specify 0 for casunique Created: 02/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | 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-206] Need clear info and examples on proper error handling Created: 02/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tim Smith | 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: |
|
||||||||
| 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-205] docs for touch() should mention getAndTouch() Created: 02/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Tim Smith | 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-touch.html | ||
| Description |
|
It would be nice for the touch() docs to mention getAndTouch() as a common optimization:
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-retrieve-gat.html |
[JCBC-217] Create Source-Code Styleguide Created: 23/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.7 |
| 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-228] a no-args constructor and an init method are needed Created: 31/Jan/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Currently, the CouchbaseClient does a number of things that are not so pretty, like spinning up a thread from it's ctor. It would be better to add an additional, optional no-args constructor which expects an init method to be called with the other params needed, start thread, etc.
|
| Comments |
| Comment by Michael Nitschinger [ 31/Jan/13 ] |
| Assigning towards 1.1.2 but we can defer it to 1.1.3 as well. |
[JCBC-233] Write the Java on Windows with Eclipse installation instructions for essentials guide Created: 04/Feb/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | MC Brown | 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. |
[JCBC-234] Write the Java on Mac OS X using Eclipse section of the Essentials Guide Created: 04/Feb/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | MC Brown | 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. |
[JCBC-235] Write the Java on Linux using Eclipse section of the Essentials Guide Created: 04/Feb/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Major |
| Reporter: | MC Brown | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Write the Java on Linux using Eclipse section of the Essentials Guide
Needs to cover: Basic Installation/Setup of Eclipse Adding the Couchbase Java components to Eclipse Writing your first (small) app using Couchbase within Eclipse Submissions should be to MC, either through the couchbase/docs repo, or direct to MC in whatever format suits. Must include both the text and images. |
[JCBC-258] documentation needs to be much clearer about Query.setKey() requiring JSON encoded strings or use of ComplexKey Created: 06/Mar/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.3 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Neither the javadoc nor the existing documentation really cover the potential issues with setKey using a number or something that will autobox into a string value. This should be much clearer.
|
[JCBC-269] subsequent resubscribers should not run if a resubscriber is successful Created: 13/Mar/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.7 |
| 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-270] client does not handle failure of EPT node with memcached bucket Created: 13/Mar/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.7 |
| 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 | ||
| Environment: | 3 node cluster of 2.0, one memcached bucket authenticated, Couchbase Java Client 1.1.2 with required spymemcached 2.8.11 | ||
| Attachments: |
CBSE-472repro-2.txt
|
| Description |
|
When investigating a case, it seems that the dropped configuration when using a memcached bucket is never reestablished. I'm not sure if this is because we rely on timeouts (which we won't get in this case) or something else.
Steps to reproduce: 1. Set up three node cluster 2. Run a constant workload, starting off of one of the nodes (192.168.1.200 in my config) 3. Remove that node from the cluster Observed behavior: The client sees the config dropped, but doesn't reconfigure. Expected behavior: Client bootstraps off of one of the other nodes. Attached file shows the config log in this case. |
| Comments |
| Comment by Michael Nitschinger [ 14/Mar/13 ] |
|
Hey Matt, one quick update.. I don't know yet if its related, but you've been using the wrong netty version.. your logs show /Users/ingenthr/lib/netty-3.2.5.Final.jar' but the correct one is 3.5.5! Since netty handles the streaming connection, this may be related - I dont know yet. |
| Comment by Michael Nitschinger [ 15/Mar/13 ] |
|
Matt, with the change proposed in Can you try to repro with those two changes and if it still fails lets do a quick screen sharing. |
| Comment by Matt Ingenthron [ 18/Mar/13 ] |
| Indeed, I could not reproduce this one after moving to the right dependencies. |
[JCBC-237] Docs: Document how to use observe properly outside of the "wrapped" methods Created: 05/Feb/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | 1.1.7 |
| 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-248] ensure there is a floor to tuneables such that they can't be set so a client misbehaves Created: 15/Feb/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | 1.0.3, 1.1.0, 1.1.1, 1.1.2 |
| Fix Version/s: | 1.1.7 |
| 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-250] ClassCast Exception when using durability against memcached bucket Created: 20/Feb/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
1.1.5-sdk.log
1.1.6-sdk.log
|
| Description |
|
Apparently trying to use these operations:
CouchbaseClient.add(String key, int exp, String value, PersistTo req, ReplicateTo rep) Against a memcached bucket causes an exception even if "req" and "rep" are set to 0. From the user's perspective, they expect this to work. Is it a major undertaking to make the classes compatible from the client side, independent of the bucket types and then let the operation succeed/fail when it can or can't? java.lang.ClassCastException: com.couchbase.client.CouchbaseMemcachedConnection cannot be cast to com.couchbase.client.CouchbaseConnection at com.couchbase.client.CouchbaseClient.observePoll(CouchbaseClient.java:1708) at com.couchbase.client.CouchbaseClient.add(CouchbaseClient.java:1293) |
| Comments |
| Comment by Deepti Dawar [ 14/May/13 ] |
|
This problem has been fixed in the version 1.1.6. It was there till 1.1.5 but now has been fixed.
Please find the same log of run in 1.1.5 and 1.1.6 to strengthen the findings. Its good to close. Thanks ! |
[JCBC-276] Client does not detect silently dying Streaming Node Created: 20/Mar/13 Updated: 20/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4 |
| Fix Version/s: | 1.1.7 |
| 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 | ||
| Description |
|
When connected to the EPT/streaming node and the node is "frozen" or dies silently otherwise (doesn't force the closing of the chunked socket), the connection stays established.
This can easily be reproduced outside of the client by connecting the browser to the streaming URL and then freezing a VM. The browser will still "spin" and wait for new chunks to come up. The proposed solution is to have a netty handler in place that raises a exception when there is not traffic for N number of seconds (like 30) over the streaming connection. After this is detected, we have two possibilities: - reconnect completely, but this involves lots of overhead every 30 seconds. - send a HTTP HEAD packet and only if this doesnt work out reconnect. This means in the normal case we only have a HTTP HEAD request sent every 30 seconds, not much overhead. If this fails, we then trigger the reconfigure. Netty has a ReadTimeoutHandler to help with this. My POC already kinda works, I just need to find a way to properly distinguish the HEAD response on the ResponseHandler from regular chunks that arrive from the same channel. |
| Comments |
| Comment by Matt Ingenthron [ 20/Mar/13 ] |
| I had fixed this with couchbase buckets and we test for this in SDKQE. Is this possibly isolated to memcached buckets. |
| Comment by Michael Nitschinger [ 21/Mar/13 ] |
| Actually, this has been discovered while using Couchbase buckets. Let's chat about this, but I think thats a different issue and not related to it. |
| Comment by Matt Ingenthron [ 21/Mar/13 ] |
|
Sure, the solution previously was to have that threshold if we were getting unexpected failures. Once we pass that threshold, we'd try to re-subscribe. I'm not opposed to a heartbeat, but I don't think the HTTP HEAD is good, since the mochiweb erlang implementation is effectively the same as a GET. I'll reach you and chat through it. |
| Comment by Michael Nitschinger [ 21/Mar/13 ] |
|
Okay after talking this through with Matt, I reran the script to see if the proposed solution (increasing ops/s) fixed the problem. Interestingly, it turns out when doing set/get's it never hits our anticipated codepath but instead the get operations just time out, the threshold never gets increased and nothing happens. This is something we need to reinvestigate. |
[JCBC-291] Authentication failed on 5-th client Created: 17/Apr/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.7 |
| 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-287] Failover + Readd of Streaming Node against 1.8.1 fails Created: 18/Apr/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | 1.1.7 |
| 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-296] Document changing compression threshold Created: 06/May/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | 1.1.7 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mike Wiederhold | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| 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-282] Add new junit tests as per additions in the Test Plan Created: 09/Apr/13 Updated: 20/May/13 Resolved: 20/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Deepti Dawar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
Add new junit tests as per additions in the Test Plan
|
| Comments |
| Comment by Deepti Dawar [ 09/Apr/13 ] |
| Two tests added for connection refused and network un-reachable. |
| Comment by Deepti Dawar [ 20/May/13 ] |
| http://review.couchbase.org/#/c/25563/ |
[JCBC-266] NPE in ConfigurationProviderHTTP needs to be handled. Created: 12/Mar/13 Updated: 18/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
NPE in ConfigurationProviderHTTP needs to be handled.
This is seen at quite a lot of places. Please refer to the integration test results at : https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdHJBNHJ0eGZfbjBaenBSVGM2VS1oNlE#gid=0 Stack Trace : SDKD: Mar 12, 2013 1:55:39 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run SDKD: WARNING: Resubscribe attempt failed: SDKD: java.lang.NullPointerException SDKD: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:149) SDKD: at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:319) SDKD: at com.couchbase.client.CouchbaseConnectionFactory$Resubscriber.run(CouchbaseConnectionFactory.java:405) SDKD: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) SDKD: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) SDKD: at java.lang.Thread.run(Thread.java:619) SDKD: Mar 12, 2013 1:55:39 AM com.couchbase.client.CouchbaseConnectionFactory$Resubscriber run |
[JCBC-240] Add the total number of rows in the ViewResponce Created: 07/Feb/13 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
It will be great to have the total number of rows in the ViewResponse object when calling a view.
This is the value present in the JSON attribute "total_rows" of a response {"total_rows":1412,"rows":[ This enhancement request comes from the community forum: http://www.couchbase.com/forums/thread/recommend-including-totalrows-value-java-client-viewresponse-class |
| Comments |
| Comment by Michael Nitschinger [ 12/Mar/13 ] |
| http://review.couchbase.com/#/c/25027/ |
| Comment by Steffen Larsen [ 17/May/13 ] |
| PS: The SDK version that was used was 1.1.5 |
[JCBC-303] javadoc builds must include spymemcached Created: 14/May/13 Updated: 15/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase Java Client |
| Component/s: | infrastructure |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Phil Labee | Assignee: | Phil Labee |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| 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 [ 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? |
[JCBC-293] Clarification/Agreement on Javadocs Build Workaround Created: 01/May/13 Updated: 14/May/13 Resolved: 14/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Task | Priority: | Minor |
| Reporter: | Karen Zeller | Assignee: | Matt Ingenthron |
| Resolution: | Done | Votes: | 0 |
| Labels: | info-request | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
At this point, Phil needs clarification: if his workaround is OK, and clarify spymemcached is ours + what version we need to use....
Please assign to him to apply the workaround after you get a change to clarify. ----------- Sent via email by Dipti 4/31. ----------------------- Background: Hi Wayne, It is on jenkins@ubu-1702.hq.couchbase.com. You can access it on with the QA key, QAkey.pem. The ANT file is supposed to build javadocs and rdocs and the problem we are encountering is that we had included third parties libraries (spymemcached) and it the latest javadoc generation they were not included. Thanks, Karen ------- Wayne assigne to Phil and Phil investigates for several hours ---------------- From Phil: From: Philip Labee <Philip@couchbase.com> Date: Friday, April 19, 2013 2:07 PM To: Matt Ingenthron <matt@couchbase.com>, Michael Nitschinger <Michael.Nitschinger@couchbase.com> Cc: Karen Zeller <karen.zeller@couchbase.com>, Wayne Siu <Wayne@couchbase.com> Subject: building javadocs for couchbase-java-client Karen and I are following the directions for building the javadocs but it looks like these instructions are incomplete. Specifically they say to create a clean clone of couchbase-java-client and to run "ant docs" there, but the problem is that it only generates docs for our code, and misses all the net.spy.memcached docs because the spy.memcached source files are not in the build tree. I could easily clone the spy.memcached source files into ~jenkins and then symlink the src/main/java/net files into the sr/main/java directory of the client build dir, but there's no evidence that this is how it was done before. If you know how this was done in previous releases which do include the docs for spy.memcached, let me know and we'll update the instructions and generate a complete set of javadocs. If we don't discover a known solution we'll proceed with the cloning and the symlinking. If we don't want to include third-party docs in our doc-set then there's nothing more to do. net.spy.memcached docs included: http://www.couchbase.com/autodocs/couchbase-java-client-1.1.4c/index.html Not included: http://www.couchbase.com/autodocs/couchbase-java-client-1.1.5/index.html --Phil |
| Comments |
| Comment by Michael Nitschinger [ 05/May/13 ] |
|
Hey Matt, do you remember who built the C releases and the docs? I played around with doc generating, but couldn't find a way to package it just by specifying the spy docs in the classpath (and playing around with the javadoc command in our ant script). I'm sure there is a way to do this. |
| Comment by Phil Labee [ 14/May/13 ] |
|
resolution is not to work around the current process, but to fix it so that no workaround is required.
See JCBC-303 |
| Comment by Phil Labee [ 14/May/13 ] |
| Instead of a workaround, I'll fix the process and update the docs. |
[JCBC-256] New failures registered after the new change set added Created: 28/Feb/13 Updated: 14/May/13 Resolved: 14/May/13 |
|
| Status: | Closed |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
errors_latest_run.png
failures_latest_run.png
|
| Description |
|
The pass rate with the latest change set is only 92%
A lot of array index out of bounds exceptions are there. Please check. |
| Comments |
| Comment by Matt Ingenthron [ 28/Feb/13 ] |
| Can you please include some more detail? This doesn't have which exceptions, which tests, anything on the environment, etc. |
| Comment by Deepti Dawar [ 28/Feb/13 ] |
| The snapshot has some details you are looking for. If its not clear please do let me know. |
| Comment by Michael Nitschinger [ 28/Feb/13 ] |
|
can you please upload the full test results? Looks to me that spy isnt the correct version (master, not 2.11!). Also, can you give me the hashes of the latest git commits and or the java -jar output you're using? thanks! |
| Comment by Michael Nitschinger [ 28/Feb/13 ] |
| No, sorry about the latest comment.. after cleaning my cache I see the same. |
| Comment by Michael Nitschinger [ 28/Feb/13 ] |
| Okay I see what's going on, this -1 issue will be easy to fix. Expect a changeset soon. |
| Comment by Deepti Dawar [ 14/May/13 ] |
|
As per the latest results, this error has been fixed. The other issues are being addressed. Hence, closing out this issue. http://sdkbuilds.couchbase.com/job/java-snapshot-build/lastCompletedBuild/testReport/ |
[JCBC-267] Memcached bucket still fails with all workloads Created: 12/Mar/13 Updated: 14/May/13 Resolved: 10/May/13 |
|
| Status: | Closed |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Deepti Dawar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
assertion_error_mem_bkt.log
mem_bkt_base_raw_1.1.4.log
mem_bkt_failover_1.1.6_server1.8.1_working_fyn.log
mem_bkt_failover_1.1.6_server2.0.1_working_fyn.log
mem_bkt_faiover_1.1.6.log
mem_bkt_latest_run_1.1.4.log
mem_bkt_readd_1.1.6.log
mem_bkt_readd_1.1.6_server1.8.1_working_fyn.log
mem_bkt_readd_1.1.6_server2.0.1_working_fyn.log
mem_bkt_rebalance_1.1.6.log
mem_bkt_rebalance_1.1.6_server1.8.1_working_fyn.log
mem_bkt_rebalance_1.1.6_server2.0.1_working_fyn.log
memcached_bucket_basic_json.log
memcached_bucket_basic.log
memcached_bucket_failover.log
memcached_bucket_readd.log
memcached_bucket_rebalance.log
test_run.tar.gz
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
Attaching all the tests ran against memcached buckets.
1) Basic tests - the gets fail, whereas the sets pass. 2) Failover and readd - Here there are many assertion errors with the I/O being problematic 3) Rebalance - Here there are many assertion errors with the I/O being problematic In 2nd and 3rd cases, the probable cause may be the following - [SDKD(WARNING) 268.72 cbsdk.sdkd.local executor.py:66] Exception in thread "Memcached IO over {MemcachedConnection to /10.3.121.212:11210 /10.3.121.208:11210}" java.lang.AssertionError: Attempting to overwrite channel [SDKD(WARNING) 268.72 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.setChannel(TCPMemcachedNodeImpl.java:496) 4) Failover - Here there are failures in the rebalance phase, bt the rebound phase breaks in SDKD. Another SDKD issue is filed to take care of the same. We also need to investigate the SDKD code. There might be something wrong there in handling the memcached buckets. But, till now the issue looks more likely to be with the java sdk. |
| Comments |
| Comment by Michael Nitschinger [ 18/Mar/13 ] |
|
The AssertionError has reportedly been fixed ( |
| Comment by Deepti Dawar [ 18/Mar/13 ] |
|
Hi Michael, Please find the latest report. Other than the assertion errors, I am getting few exceptions with the setting up of view time outs. This has been tested with the latest merged code. Hence, Its not getting fixed with the fix for Please let me know if you have some findings to state otherwise. Regards, Deepti |
| Comment by Michael Nitschinger [ 18/Mar/13 ] |
|
Hi Deepti, please use HEAD instead of the 1.1.3 tag, it does not represent the latest changes. The output log shows this: [DEBUG 34.58 cbsdk.driver driver.py:48] INFO:0 @0 (OK) {'COMPONENTS': {'SPY': 'Spymemcached 2.8.12\n\nTree Version: 2.8.12\nLast Commit ID: 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de\n\nCompiled by michael@daschlbook.local on Fri Mar 1 01:15:26 CET 2013', 'SDK': 'Couchbase Java Client 1.1.3\n\nTree Version: 1.1.3\nLast Commit ID: eaff6b0e67af7665301aa749722c97023e6d653b\n\nCompiled by michael@daschlbook.local on Mon Mar 4 15:17:27 CET 2013'}, 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de is not the correct one. The correct one is: 053c653ebbbb5da14cb9398447acc40c1f63552d You can see that is was compiled on my machine on 04th March. Thanks, Michael |
| Comment by Deepti Dawar [ 26/Mar/13 ] |
|
Hi Michael, I have attached the log of run pertaining to the latest version. It still has the errors. 'COMPONENTS': { 'SDK': 'Couchbase Java Client 1.1.4\n\nTree Version: 1.1.4\nLast Commit ID: 0958708ab0425a8b91c3e32d7e07d577b50a92b8\n\nCompiled by michael@daschlbook.local on Wed Mar 13 09:31:34 CET 2013', 'SPY': 'Spymemcached 2.8.12\n\nTree Version: 2.8.12\nLast Commit ID: 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de\n\nCompiled by michael@daschlbook.local on Fri Mar 1 01:15:26 CET 2013'}} |
| Comment by Michael Nitschinger [ 26/Mar/13 ] |
|
Hi Deepti, I'm not sure what the purpose of this run was, because it still uses the old version (as you even mentioned in your comment): 'COMPONENTS': { 'SDK': 'Couchbase Java Client 1.1.4\n\nTree Version: 1.1.4\nLast Commit ID: 0958708ab0425a8b91c3e32d7e07d577b50a92b8\n\nCompiled by michael@daschlbook.local on Wed Mar 13 09:31:34 CET 2013', 'SPY': 'Spymemcached 2.8.12\n\nTree Version: 2.8.12\nLast Commit ID: 84ebf9ad0d0d8a64497d956f6e75bf74cd7883de\n\nCompiled by michael@daschlbook.local on Fri Mar 1 01:15:26 CET 2013'}} The version used is the 1.1.4 tag, compiled by me on 13th march. The fix for this is in MASTER (and was added there on march 16th). |
| Comment by Deepti Dawar [ 26/Mar/13 ] |
|
Alright Michael.
I think we are good with the fix for the scenarios of basic test and the test with failover and readd. There are no assertion errors for these two cases now. But in the case of failover and rebalance tests there are still errors existing. Please find the zip file for all the runs. I'll tell Saran to get back to customer with the latest build 1.1.4 and verify. Thanks ! |
| Comment by Michael Nitschinger [ 24/Apr/13 ] |
| Whats the status on this? |
| Comment by Deepti Dawar [ 25/Apr/13 ] |
|
As already stated, the failover and the rebalance cause an issue still. You can have a look at the logs in the attached zip file. |
| Comment by Deepti Dawar [ 09/May/13 ] |
| There is a marked improvement in these scenarios. But the tests are failing still. Please have a look at the latest attachments from the cbc version 1.1.6. |
| Comment by Deepti Dawar [ 10/May/13 ] |
|
Tested with the latest version of the client i.e. 1.16. All the scenarios are passing. Hence, closing the issue. |
[JCBC-302] Small issue in release note 1.1.6 Created: 13/May/13 Updated: 13/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.6 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
In the release note :
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-rn_1-1-6a.html Small typo: "(wthout the quotes) " should be "without" |
[JCBC-274] Jenkins test results failing. Created: 16/Mar/13 Updated: 13/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
git_build_description.png
issues_latest_run_jenkins.png
latest_build.png
|
||||
| Issue Links: |
|
||||
| Description |
|
When the jenkins job for java build is run with the latest source in Git and the tests are run, 6 tests are failing. Those are very obvious errors and can be fixed. Screenshot attached.
|
| Comments |
| Comment by Deepti Dawar [ 18/Mar/13 ] |
|
Michael, kindly check why the NPEs are coming in these results. Thanks Deepti. |
| Comment by Deepti Dawar [ 04/Apr/13 ] |
|
Please review few fixes at : http://review.couchbase.org/#/c/25482/ |
[JCBC-297] Release Java Client 1.1.6 Created: 07/May/13 Updated: 10/May/13 Resolved: 10/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Release the Java Client 1.1.6
|
[JCBC-299] ClassCastException in CouchbaseClient for the memcached connection Created: 09/May/13 Updated: 10/May/13 Resolved: 10/May/13 |
|
| Status: | Closed |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
mem_bkt_failover_1.1.6_server1.8.1_working_fyn.log
mem_bkt_failover_1.1.6_server2.0.1_working_fyn.log
mem_bkt_faiover_1.1.6.log
mem_bkt_readd_1.1.6.log
mem_bkt_readd_1.1.6_server1.8.1_working_fyn.log
mem_bkt_readd_1.1.6_server2.0.1_working_fyn.log
mem_bkt_rebalance_1.1.6.log
mem_bkt_rebalance_1.1.6_server1.8.1_working_fyn.log
mem_bkt_rebalance_1.1.6_server2.0.1_working_fyn.log
|
| Description |
|
For all the tests running on CouchbaseMemcachedConnection, ClassCastException occurs while casting the instance of the CouchbaseMemcachedConnection to CouchbaseConnection.
PFA the logs of run. |
| Comments |
| Comment by Deepti Dawar [ 10/May/13 ] |
|
As per the latest run using cbc-1.1.6 and server-1.8.1, 2.0.1, these scenarios are all working fine.
Hence, closing the issue. |
[JCBC-288] Query.setKey() does not parse properly string that starts with number but contains letter Created: 19/Apr/13 Updated: 10/May/13 Resolved: 10/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Tug Grall |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When a query is made with the setKey and this key starts with number but contains chars, our Query parser transforms this as Number, for example
"123ABC" will be sent as key=123 Note that the complex key and setKeys() are working properly. |
[JCBC-284] Create new methods (set/add/update) with no ttl (to be persisted "for ever" by default) Created: 12/Apr/13 Updated: 10/May/13 Resolved: 10/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Tug Grall |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
To improve the developer experience it is better to allow developers to do a
client.set("K","V") and this will be equivalent of a 0 TTL. This should be done for set,add,replace (all methods with a TTL) |
| Comments |
| Comment by Michael Nitschinger [ 15/Apr/13 ] |
| It's yours :) |
[JCBC-301] Strange Logic in CouchbaseClient observePoll method Created: 09/May/13 Updated: 09/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | .next |
| Fix Version/s: | None |
| 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-268] ReplicateTo.ZERO+PersistTo.ZERO should be handled specially so as not to impact performance Created: 12/Mar/13 Updated: 08/May/13 Resolved: 08/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.3 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When testing the durability constraints with ZERO for both replicate and persist, there is a noticeable drop in throughput due to the extra call to the server to check for these constraints.
Intuitively, since this is a "single" API that hides the functionality from the user, the user expects that supplying ZERO for both of these options should be the same speed as not supplying them at all. |
| Comments |
| Comment by Michael Nitschinger [ 08/May/13 ] |
| http://review.couchbase.org/#/c/26182 |
[JCBC-177] support a single null in a view query Created: 11/Dec/12 Updated: 08/May/13 Resolved: 08/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Matt Ingenthron | Assignee: | Deepti Dawar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
In ComplexKeyTest.java, there is a disabled test for handling a ComplexKey.of((Object[]) null); since it would NPE. This should be fixed.
It's not that likely someone will start a query with null, but it is possible. |
| Comments |
| Comment by Deepti Dawar [ 01/Apr/13 ] |
| http://review.couchbase.org/#/c/25415/ |
[JCBC-146] Paginator should support reduced views. Created: 13/Nov/12 Updated: 08/May/13 Resolved: 08/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Mike Wiederhold | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Comments |
| Comment by Michael Nitschinger [ 14/Nov/12 ] |
|
Depends on |
| Comment by Michael Nitschinger [ 21/Nov/12 ] |
| Now this can be implemented as well. |
[JCBC-241] Paginator object doesn't move onto next "page" correctly Created: 07/Feb/13 Updated: 08/May/13 Resolved: 08/May/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.6 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Perry Krug | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
paginator-java.diff
|
||||
| Issue Links: |
|
||||
| Description |
|
Customer found his own issue:
I had a look at the source code for the java driver and found the error there. It is in: com.couchbase.client.protocol.views.Paginator.getNextPage() Right after calculating the number of "remaining" keys, it sets the limit of the query to the remaining number of keys and re-runs the query. What is missing here is: q.setSkip(totalDocs); To actually start from the entry after the last entry on the current page. I have tried this and it works. But there is more code in this method and it is not very easy to follow so important to make sure that this fits. I am enclosing a diff. |
| Comments |
| Comment by Perry Krug [ 07/Feb/13 ] |
|
Update, but the bug still stands as described. It seems that my fix is not the correct one. The bug seem to be that although the Paginator specifies setStartkeyDocID, the query doesn't start from this key. I have debugged the Paginator class – and when resolving the next page it instructs the query to start from a specific doc id, e.g: Query: ?limit=50&startkey=144&skip=0&stale=false&startkey_docid=144 But as a result of this query I get: Got key: 1 Got key: 10 Got key: 100 Got key: 101 Got key: 102 Got key: 103 … Got key: 141 Got key: 142 Got key: 143 Every time. So the bug is in the Query context somewhere. Also – a note of inefficiency in the Paginator class: why perform two queries every time? One for the content of the "page" and one to find the row for the next page? Would be better to query for page + 1 and keep the last separate from the ViewResponse. So, what I can conclude is that when the Paginator bug is resolved it should work fine for us. The additional query for the last row could be an issue though, since it uses setSkip(). So could this be treated as a bug as well? |
[JCBC-247] ViewReponse: Provide a way to return the JSON as it is Created: 14/Feb/13 Updated: 07/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The Java API provide most of the time access to the JSON document (as string):
- get commands - view command using the ViewRow.getDocument When we call a view the result is a ViewResponse, but it is not possible to get the JSON document out of it, and the view engine returned a JSON doc. It could be interesting for some development, to be able to do a viewResponse.toJSON() that returns the exact result of the view. (this function may not be compliant with the includesDoc(true) option) The use case is simple, suppose I am creating a REST API and I would like to call the view and return the result to the user it would be good to do something like : @GET @Produces({ "application/json"}) @Path("/person/") public String getPersons( ) { View view = client.getView(PERSON_DSGN_DOC, PERSON_BY_NAME_VIEW); Query query = new Query(); ViewResponse viewResponse = client.query(view, query); return viewResponse.toJSON(); } Today I have to loop on each result and create a new object/document |
[JCBC-180] Allow for default value to append/prepend Created: 12/Dec/12 Updated: 07/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | .next |
| 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: |
|
||||||||
| 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-295] Spring Connector Guide Created: 02/May/13 Updated: 06/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Story | Priority: | Major |
| Reporter: | Karen Zeller | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | info-request | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Phase 1:
-Need intended user/audience from SME -Need suggested topics for TOC from SME |
| Comments |
| Comment by Michael Nitschinger [ 05/May/13 ] |
|
Hi Karen, let's put this on hold for now. We may think about moving the documentation to the springsource environment (alongside with the code), but we need to work this out. I want to avoid duplicate work for this! |
| Comment by Karen Zeller [ 06/May/13 ] |
| This is not currently work in progress. |
[JCBC-244] Sample Application : fix the welcome file and gitignore Created: 12/Feb/13 Updated: 02/May/13 |
|
| Status: | In Progress |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Minor |
| Reporter: | Tug Grall | Assignee: | Tug Grall |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
1- the Welcome auto redirect in Jetty does not work correctly.
2- Update the gitignore to handle IDE and OS |
| Comments |
| Comment by Michael Nitschinger [ 26/Mar/13 ] |
| Hey tug, is this still ongoing? |
| Comment by Michael Nitschinger [ 15/Apr/13 ] |
| Tug, did you fix this recently? |
[JCBC-294] OOME on ViewResponse for very large view Created: 02/May/13 Updated: 02/May/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Tug Grall | 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. |
[JCBC-286] Copyedit MichaelN blog on Java SDK Internals Created: 16/Apr/13 Updated: 26/Apr/13 Resolved: 26/Apr/13 |
|
| Status: | Closed |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Karen Zeller | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Couchbase Java SDK Internals
============================ ## Motivation This blog post is intended to be a very detailed and informative article for those who already have used the Couchbase Java SDK and want to know how the internals work. This is not a introduction on how to use the Java SDK and we'll cover some fairly advanced topics on the way. Normally, when talking about the SDK we mean everything that is needed to get you going (Client library, documentation, release notes,...). In this article though, the SDK refers to the Client library (code) unless stated otherwise. As always, if you have feedback please let me/us know! ## Introduction First and foremost, its important to understand that the SDK wraps and extends the functionality of the [spymemcached]() (called "spy") memcached library. One of the protocols used internally is the memcached protocol, and a lot of functionality can be reused. On the other hand, once you start to peel off the first layers of the SDK you will notice that some components are somewhat more complex because of the fact that spy provides more features than the SDK needs in the first place. The other part is to remeber that a lot of the components are intervoven, so you always need to get the dependency right. Most of the time, we release a new spy version at the same date with a new SDK, because new stuff has been added or fixed. So, aside from reusing the functionality provided by spy, the SDK mainly adds two blocks of functionality: automatic cluster topology management and since 1.1 (and 2.0 server) support for Views. Aside from that it also provides admnistrative facilities like bucket and design document management. To understand how the client operates, we'll dissect the whole process in different life cycle phases of the client. After we went through all three phases (bootstrap, operation and shutdown) you should have a clear picture of whats going on under the hood. Note that there is a separate blog post in the making about error handling, so we won't cover that here in greater detail. ## Phase 1: Bootstrap Before we can actually start serving operations like `get()` and `set()`, we need to bootstrap the `CouchbaseClient` object. The important part that we need to accomplish here is to initially get a cluster configuration (which contains the nodes and vBucket map), but also to establish a streaming connection to receive cluster updates in (near) real-time. We take the list of nodes passing during bootstrap and iterate over it. The first node in the list that can be contacted on port 8091 is used to walk the RESTful interface on the server. This means that going from the provided `http://host:port/pools` URI we eventually follow the links to the bucket entity. All this happens inside a `ConfigurationProvider`, which is in this case the `com.couchbase.client.vbucket.ConfigurationProviderHTTP`. If you want to poke around on the internals, look for `getBucketConfiguration` and `readPools` methods. A (successful) walk can be illustrated like this: 1: GET /pools 2: look for the "default" pools 3: GET /pools/default 4: look for the "buckets" hash which contains the bucket list 5: GET /pools/default/buckets 6: parse the list of buckets and extract the one provided by the application 7: GET /pools/default/buckets/<bucketname> Now we are at the configuration page that we need. On this JSON response, you'll find all useful details that gets also be used inside the Client SDK (for example `streamingUri`, `nodes` and `vBucketServerMap`). The config gets parsed and stored. Before we move on, let's quickly discuss the strange `pools` part inside our REST walk: The concept of a resource pool to group buckets was concepted for Couchbase Server, but never fully implemented. Still, the REST API is implemented that way and therefore all client SDKs have to deal with it. That said, while we could theoretically just go directly to `/pools/default/buckets` and skip the first few queries, the feature might come back at some time and that way the SDK is architected more future-proof. Back to our bootstrap phase. Now that we have a valid cluster config which contains all the nodes (and their hostnames or ip addresses), we can establish connections to them. Aside from establishing the data connections, we also need to instantiate a streaming connection to one of them. For simplicity reasons, we just establish the streaming connection to the node from the list where we got our initial configuration. This gets us to a valid point upfront: if you have lots of CouchbaseClient objects running on many nodes and they all get bootstrapped with the same list, they may end up connecting to the same node for the streaming connection. Therefore, to distribute the load a little better I recommend shuffling the array before it gets passed in to the CouchbaseClient object. When you only have a few CouchbaseClient objects connected to your cluster, that won't be a problem at all. The streaming connection URI is taken from the config we got previously, and normally looks like this: streamingUri: "/pools/default/bucketsStreaming/default?bucket_uuid=88cae4a609eea500d8ad072fe71a7290" If you point your browser to this address, you will also get the updates streamed in real-time. Since the streaming connection needs to be established all the time and potentially blocks a thread, this is done in the background handled by different threads. We are using the NIO framework [Netty]() for this task, which provides a very handy way of dealing with asynchronous operations. If you want to start digging into this part, keep in mind that all read operations are completely separate from write operations, so you need to deal with handlers that take care of what comes back from the server. Aside from some wiring needed for Netty, the business logic can be found in `com.couchbase.client.vbucket.BucketMonitor` and `com.couchbase.client.vbucket.BucketUpdateResponseHandler`. We also try to reestablish this streaming connection if the socket gets closed (for example if this node gets rebalanced out of the cluster). To actually shuffle data to the cluster nodes, we need to open various sockets to them. Note that there is absolutely no connection pooling needed inside the client, because we manage all sockets proactively. Aside from the special streaming connection to one of the severs (which is opened against port 801), we need to open the following connections: - Memcached Socket: Port 11210 - View Socket: Port 8092 Note that port 11211 is not used inside the client SDKs, but used to connect vanilly memcached clients that are not cluster aware. Using this inherits some overhead, so the SDK will be faster in general. So as a rule of thumb, if you have a 10 node cluster running, one CouchbaseClient object open about 21 (2*10 + 1) client sockets. These are directly managed, so if a node gets removed or added the numbers will change accordingly. Now that all sockets have been opened, we are ready to perform regular cluster operations. As you can see, there is a lot of overhead involved when the CouchbaseClient object gets bootstrapped. Because of this fact, we strongly discourage you from either creating a new object on every request or running a lot of CouchbaseClient objects in one application server. This only adds unnecessary overhead and load on the application server and adds on the total sockets opened against the cluster. ## Phase 2: Operations When the SDK is bootstrapped, it allows to run operations against the attached cluster. For the purpose of this blog post, we need to distinguish between operations that get executed against a stable cluster and one that is currently experiencing some form of intability (be it planned because of adding nodes or unplanned because of a node failure). Let's tackle the regular operations first. ### Operations against a stable cluster While not directly visible in the first place, inside the SDK we need to distinguish between memcached operations and View operations. All operations that have a uniqe key in their method signature can be treaded as memached operations. All of them eventually end up getting funneled through spy. View operations on the other hand are implemented completely inside the SDK itself. Both View and memcached operations are asynchronous. Inside spy, there is one thread (call the I/O thread) dedicated to deal with IO operations. Note that in hight-traffic environments, its not unusual that this thread is always active. It uses the non-blocking Java NIO mechanisms to deal with traffic, and loops around "selectors" that get notified when data can either be written or read. If you profile your application and you'll see that this thread spends most of its time waiting on a `select` method, it means that it is idling there waiting to be notified for new traffic. The concepts used inside spy to deal with this are common Java NIO knowledge, so you may want to look into the NIO internals first before digging into that code path. Good starting points are the `net.spy.memcached.MemcachedConnection` and `net.spy.memcached.protocol.TCPMemcachedNodeImpl` classes. Note that inside the SDK, we override the `MemcachedConnection` to hook in our own reconfiguration logic. This class can be found inside the SDK at `com.couchbase.client.CouchbaseConnection` and for memcached-type buckets in `com.couchbase.client.CouchbaseMemcachedConnection`. So if a memcached operations (like `get()`) gets issued, it gets passed down until it reaches the IO thread. The IO thread will then put it on a write queue towards its target node. It gets written eventually and then the IO thread adds information to a read queue so the responses can be mapped accordingly. This approach is based on futures, so when the result actually arrives, the Future is marked as completed, the result gets parsed and attached as Object. The SDK only uses the memcached binary protocol, altough spy would also support ASCII. The binary format is much more efficient and some of the advanced operations are only implemented there. You may wonder how the SDK knows to which node to send the operation? Since we already have the up-to-date cluster map, we can hash the key and then based on the node list and vBucketMap determine which node to access. The vBucketMap not only contains the master node of the array, but also zero to three replica nodes. Look at this (shortened) example: vBucketServerMap: { hashAlgorithm: "CRC", numReplicas: 1, serverList: [ "192.168.56.101:11210", "192.168.56.102:11210" ], vBucketMap: [ [0,1], [0,1], [0,1], [1,0], [1,0], [1,0] //..... }, The `serverList` contains our nodes, and the `vBucketMap` has pointers to the `serverList` array. We have 1024 vbuckets, so only some of them are shown here. You can see from looking at it that all keys that has into the first vbucket have its master node at index 0 (so the `.101` node) and its replica at index 1 (so the `.102` node). Once the cluster map changes and the vBuckets move around, we just need to update our config and know all the time where to point our operations towards. View operations are handled differently. Since views can't be sent to a specific node (because we don't have a way to hash a key or something), we round-robin between the connected nodes. The operation gets assigned to a `com.couchbase.client.ViewNode` once it has free connections and then executed. The result is also handled through futures. To implement this functionality, the SDK uses the third party Apache HTTP Commons (NIO) library. The whole View API hides behind port 8092 on every node and is very similar to [CouchDB](). It also contains a RESTful API, but the structure is a little bit different. For example, you can reach a design document at `/<bucketname>/_design/<designname>`. It contains the View definitions in JSON: { language: "javascript", views: { all: { map: "function (doc) { if(doc.type == "city") {emit([doc.continent, doc.country, doc.name], 1)}}", reduce: "_sum" } } } You can then reach down one level further like `/<bucketname>/_design/<designname>/_view/<viewname>` to actually query it: {"total_rows":9,"rows":[ {"id":"city:shanghai","key":["asia","china","shanghai"],"value":1}, {"id":"city:tokyo","key":["asia","japan","tokyo"],"value":1}, {"id":"city:moscow","key":["asia","russia","moscow"],"value":1}, {"id":"city:vienna","key":["europe","austria","vienna"],"value":1}, {"id":"city:paris","key":["europe","france","paris"],"value":1}, {"id":"city:rome","key":["europe","italy","rome"],"value":1}, {"id":"city:amsterdam","key":["europe","netherlands","amsterdam"],"value":1}, {"id":"city:new_york","key":["north_america","usa","new_york"],"value":1}, {"id":"city:san_francisco","key":["north_america","usa","san_francisco"],"value":1} ] } Once the request is sent and a response gets back, it depends on the type of View request to determine on how the response gets parsed. It makes a difference, because reduced View queries look different than non-reduced. The SDK also includes support for spatial Views and they need to be handled differently as well. The whole View response parsing implementation can be found inside the `com.couchbase.client.protocol.views` namespace. You'll find abstract classes and interfaces like `ViewResponse` in there, and then their special implementations like `ViewResponseNoDocs`, `ViewResponseWithDocs` or `ViewResponseReduced`. It also makes a different if `setIncludeDocs()` is used on the Query object, because the SDK also needs to load the full documents using the memcached protocol behind the scenes. This is also done while parsing the Views. Now that you have a basic understanding on how the SDK distributes its operations under stable conditions, we need to cover an important topic: how the SDK deals with cluster topology changes. ### Operations against a unstable cluster Note that there is a separate blog post upcoming dealing with all the scenarios that may come up when something goes wrong on either the cluster or the SDK, so this post deals more with the internals and what needs to be done inside the SDK. As mentioned earlier, the SDK receives topology updates through the streaming connection. Leaving the special case aside where this node actually gets removed or fails, all updates will come in near real-time (because in a eventually consistent architecture, it may take some time until the cluster updates get populated to that node). The chunks that come in over the stream look exactly like the ones we've seen when reading the initial configuration. After those chunks have been parsed, we need to check if the changes really affect the SDK (since there are many more parameters than the SDK needs, it won't make sense to listen to all of them). All changes that affect the topology and/or vBucket map are considered as important. If nodes get added or removed (be it either through failure or planned), we need to open or close the sockets. This process is called "reconfiguration". Once such a reconfiguration is triggered, lots of actions need to happen in various places (spy needs to handle its sockets, view nodes need to be managed and new configuration needs to be updated). The SDK makes sure that only one reconfiguration can happen at the same time through locks so we don't have any race conditions going on. The Netty-based `BucketUpdateResponseHandler` triggers the `CouchbaseClient#reconfigure` method, which then starts to dispatch everything. Depending on the bucket type used (i.e. memcached type buckets don't have Views and therefore no ViewNodes), configs are updated and sockets closed. Once the reconfiguration is done, it can receive new ones. During planned changes, everything should be pretty much controlled and no operations should fail. If a node is actually down and not reachable, those operations will be cancelled. Reconfiguration is tricky because the topology changes while operations are flowing through the system. Finally, let's cover some differences between Couchbase and Memcache type buckets. All the vBucket part that you've been reading previously only applies to Couchbase buckets. Memcache buckets are pretty basic and are treated that way. Since you don't have vBuckets, all tha the Client has to do is to manage the nodes and their sockets. Also, a different hashing algorithm is used (Ketama) by default to determine the target node for each key. Also, memcache buckets don't have views, so you can't use the View API and it doesn't make much sense to keep View sockets around. So to clarify the previous statement, if you are running against a memcache bucket, for a 10 node cluster you'll only have 11 open connections. Phase 3: Shutdown ----------------- Once the `CouchbaseClient#shutdown()` method is called, no more operations are allowed to be added onto the `CouchbaseConnection`. Aside from that, until the timeout is reached, the client wants to make sure that all operations went through accordingly. All sockets for both memcached and View connections are shut down once there are no more operations in the queue (or they get dropped). Note tha that the `shutdown` methods on those sockets are also used when a node gets removed from the cluster during normal operations, so it's basically the same, but just for all attached nodes at the same time. Summary ------- After reading this blog post, you should have a much more clear picture on how the client SDK works and why its architected the way it is. We have lots of enhancements planned for future releases, mostly enhancing the direct API experience. Note that this blog post didn't cover how errors are handled inside the SDK, this will be published in a separate blog post (because there is also lots of information to cover). |
| Comments |
| Comment by Karen Zeller [ 16/Apr/13 ] |
|
Input/Clarification-Needed/Edits:
-remember => remember -admnistrative => administrative -we went => we go -Note that there is a separate blog post in the making about error handling, so we won't cover that here in greater detail. => link to it from this blog, or if it does not yet exist, say it will be coming in x timeframe. -The first node in the list that can be contacted on port 8091 is used to walk the RESTful interface on the server. => you might want to add that one you create the connection, the client can automatically handle node failure and adapt by going to another node in the cluster. -Now we are at the configuration page that we need => at the REST endpoint we need. -that gets also be used => that you can also use from -concepted => designed -but never fully implemented. Still, the REST API is implemented that way and therefore all client SDKs have to deal with it. => Product Marketing/PM probably wants us to put a positive spin on this. Suggestion => and is still in the process of being implemented, therefore the SDKs provide an abstraction layer so that you as a developer do not have to worry about it. -the feature might come back at some time. Same point as prior. Suggestion => the API is subject to change so…. -This gets us to a valid point upfront: => This gets us to an important point to keep in mind…. -they may end up connecting to the same node for the streaming connection => describe problem that can occur here -the updates streamed => the cluster topology updates streamed -(which is opened against port 801) => default is 8091 -vanilly memcached clients (bad association: didn't that guy try to kill himself for lip synching?) => generic memcached clients -that are not cluster aware. => Add "This means that these generic clients do not get updated cluster topologies." -adds on the total sockets => adds the total sockets … resulting in a performance problem…. -it allows to run => it enables your application to run -and one => and operations on a cluster that…. -intability => instability -uniqe => unique -memached -> memcached -hight=> high-traffic -and you'll see => you'll see -its => it's -you may want to look into the NIO internals first => cross reference to good third party info you can recommend on topic -altough => although -to which node => where -The vBucketMap not only contains the master node of the array, but also zero to three replica nodes => change to information for master node, but also the information for zero to three…. -vbuckets => vBuckets -## Phase 2: Operations => would break this section and the one sub-subsection into just two at the same header level: 1) Read/Writes Ops on Stable Cluster, 2) View Ops on Stable Cluster. Same approach for unstable cluster sections. -The whole View response parsing implementation can be found inside the `com.couchbase.client.protocol.views` namespace. => cross-reference that part of your Javadoc -or the SDK, so => SDK. So -(because => . This is because + remove ) -(spy needs => convert into regular sentence -and not reachable, => and cannot be reached -All the vBucket part => replace part with information -Memcache buckets are pretty basic and are treated that way. => ….do not have vBucket and behave like a single container for cached data….. -Aside from that, until the timeout is reached, => Until the timeout is reached, -tha that => that -its architected the way it is => it is designed…. -Note that this blog post didn't cover how errors are handled inside the SDK, this will be published in a separate blog post (because there is also lots of information to cover). => Note that this blog post didn't cover how errors are handled inside the SDK; this will be published in a separate blog post because there is also lots of information to cover. |
[JCBC-280] Provision for auth failure in case of calling createBucket in the same txn twice and adding updateBucket functionality Created: 04/Apr/13 Updated: 26/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Deepti Dawar | Assignee: | Deepti Dawar |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
There are three ways using which we are creating connection in the java client to the server.
1) ClusterManager 2) BucketTool Both of these classes internally call the ClusterManager.createBucket for creation of the bucket. Now if I am using all the three instances of the above classes in a single function, the bucket information is overridden without any checks. Ideally using any of the connection classes if I have created a SASL bucket with some information like bucket name = 'SaslBucket', bucket password = 'password', I should not be allowed to change the password using instance of another class. There should be auth failure error being returned the second time client tries to connect to the same bucket. Server supports this because there is an Edit Bucket functionality at the server for the same. There should be a means of distinction in the request that we want to create the bucket or update. In case of bucket creation duplicity should be checked where as in case of update this should be allowed as is. Also, the expectation is that, the user might update the bucket information if he requires to change the password or other details, by explicitly calling updateBucket method which is currently not available. |
| Comments |
| Comment by Deepti Dawar [ 05/Apr/13 ] |
|
Alright.
Consider the following piece of code : public void testCreateSaslBktBadPswd() throws Exception { manager.createNamedBucket(BucketType.COUCHBASE, "bucket1", 100, 0, "password", false); List<URI> uris = new LinkedList<URI>(); uris.add(URI.create("http://" + TestConfig.IPV4_ADDR + ":8091/pools")); new CouchbaseConnectionFactory(uris, "bucket1", "password12"); new CouchbaseClient(uris, "bucket1", "password123"); BucketTool bt = new BucketTool(); bt.createSaslBucket("bucket1", BucketType.COUCHBASE, 1, 2, true); } Here, using cluster manager instance, we create a SASL bucket i.e. bucket1 with password as password. Next you would see the usage of CouchbaseConnectionFactory instance which is trying to manipulate the same bucket, bucket1. It overrides the password to password12. Here it internally calls createBucket again without checking whether such a bucket already exists or not. Another attempt is made to connect using the CouchbaseClient instance. The bucket password is again changed. Similarly, the bucket tool instance also does the same. Instead, there should be auth failure error being returned the second time client tries to connect to the same bucket. Also, the expectation is that, the user might update the bucket information if he requires to change the password or other details, by explicitly calling updateBucket method which is currently not available. |
| Comment by Michael Nitschinger [ 24/Apr/13 ] |
|
Is this still an issue?
|
| Comment by Deepti Dawar [ 25/Apr/13 ] |
| You mean there has been a fix entered for this ? |
| Comment by Michael Nitschinger [ 25/Apr/13 ] |
|
No, because I think the ticket is somewhat misleading. The Factory and the Client have nothing to do with Bucket creation. The Manager should be used for clients and the bucket tool is an internal tool used in our testing environment. I still don't get whats the problem here? Just pick one of these depending on the thing you want to do. |
| Comment by Deepti Dawar [ 25/Apr/13 ] |
|
The problem here is that, lets say there are two users - User 1 and User 2. User 1 created the instance using CouchbaseConnectionFactory and provided a password to the default bucket as 'password' User 2 created the instance using CouchbaseClient and provided a password as 'password2' As both internally go and create the bucket, don't you think the two users are overriding each other's bucket information ? Shouldn't the second user be returned an auth failure for the same ? |
| Comment by Michael Nitschinger [ 25/Apr/13 ] |
|
Hi Deepti, I'm not sure I can follow you. Neither CouchbaseConnectionFactory nor the CouchbaseClient class creates a bucket by any means. The user has to explicitly use the Manager to create a bucket! And the BucketTool uses the Manager underneath as well, it just provides some convenience methods. |
| Comment by Deepti Dawar [ 25/Apr/13 ] |
|
Ok. I see that the conflict is between - manager.createNamedBucket bucketTool.createSaslBucket both of which call the same createBucket method. |
| Comment by Michael Nitschinger [ 25/Apr/13 ] |
|
Ok so now that we pinned that down. Can you please 1) clarify whats the issue between those methods and what needs to be fixed 2) update the title and description of the ticket to reflect those changes? Thanks! |
[JCBC-292] Missing documentation about delete method with durability option Created: 25/Apr/13 Updated: 25/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Task | Priority: | Trivial |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The Delete chapter of the documentation does not mention the methods with durability parameter (persistedto and replicatedto)
http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-update-delete.html#table-couchbase-sdk_java_delete We need to put the same type of content that the one used for the store operation: http://www.couchbase.com/docs/couchbase-sdk-java-1.1/couchbase-sdk-java-set-durability.html may be "join/merge" the store and delete? |
[JCBC-290] Support for publishing view from dev to prod Created: 22/Apr/13 Updated: 22/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| 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: 22/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| 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-285] Memcached connection disconnects in case of single node server instance. Created: 16/Apr/13 Updated: 22/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Minor |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | needs-info | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
CouchbaseTest.java
|
| Description |
|
When I tried to establish a Memcached Connection with a single node server - either 1.8.1 or 2.0.1, following errors were received :
2013-04-16 18:27:01.247 INFO net.spy.memcached.MemcachedConnection: Added {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue Created a MemcachedClient with port 11211 2013-04-16 18:27:01.251 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1ffb3754 2013-04-16 18:27:01.263 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000001cbc. 2013-04-16 18:27:01.266 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:27:01.267 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 1. 2013-04-16 18:27:01.268 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:27:01.268 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000001cbc Flags: 0 Exp: 0 Data Length: 52 Deepti Exception 1 java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException: Cancelled 2013-04-16 18:27:01.269 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000002cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:03.772 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000003cbc. 2013-04-16 18:27:05.271 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=2, #iq=0, topRop=null, topWop=Cmd: add Key: Emp0000000002cbc Flags: 0 Exp: 0 Data Length: 52, toWrite=0, interested=0} 2013-04-16 18:27:05.273 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@30b42a7e 2013-04-16 18:27:05.275 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000003cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:27:05.278 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000003cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8}, attempt 2. 2013-04-16 18:27:05.279 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000003cbc Flags: 0 Exp: 0 Data Length: 52 Deepti Exception 1 java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException: Cancelled 2013-04-16 18:27:05.281 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:27:05.281 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000004cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:07.783 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000005cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:10.286 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000006cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:12.788 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000007cbc. 2013-04-16 18:27:13.281 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=4, #iq=0, topRop=null, topWop=Cmd: add Key: Emp0000000004cbc Flags: 0 Exp: 0 Data Length: 52, toWrite=0, interested=0} 2013-04-16 18:27:13.283 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1a23b006 2013-04-16 18:27:13.286 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000007cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:27:13.289 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=2, #Wops=0, #iq=0, topRop=Cmd: add Key: Emp0000000007cbc Flags: 0 Exp: 0 Data Length: 52, topWop=null, toWrite=0, interested=8}, attempt 3. 2013-04-16 18:27:13.291 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: add Key: Emp0000000007cbc Flags: 0 Exp: 0 Data Length: 52 Deepti Exception 1 java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException: Cancelled 2013-04-16 18:27:13.292 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:27:13.293 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000008cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:15.796 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000009cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:18.298 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for Emp0000000010cbc. Deepti Exception 1 java.lang.RuntimeException: Timed out waiting for operation 2013-04-16 18:27:29.302 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=3, #iq=0, topRop=null, topWop=Cmd: add Key: Emp0000000008cbc Flags: 0 Exp: 0 Data Length: 52, toWrite=0, interested=0} 2013-04-16 18:27:29.304 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3bb59c1b 2013-04-16 18:27:29.306 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:27:29.306 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 4. 2013-04-16 18:27:29.307 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:27:59.338 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:27:59.340 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@7685dfcf 2013-04-16 18:27:59.342 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:27:59.344 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 5. 2013-04-16 18:27:59.346 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:28:29.376 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:28:29.378 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@606145c5 2013-04-16 18:28:29.380 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:28:29.382 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 6. 2013-04-16 18:28:29.384 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:28:59.414 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:28:59.416 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@15fac189 2013-04-16 18:28:59.417 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:28:59.419 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 7. 2013-04-16 18:28:59.420 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:29:29.451 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:29:29.453 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@6520b476 2013-04-16 18:29:29.454 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:29:29.456 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 8. 2013-04-16 18:29:29.457 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:29:59.485 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:29:59.487 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3ebbe4b0 2013-04-16 18:29:59.488 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:29:59.490 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 9. 2013-04-16 18:29:59.491 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:30:29.521 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:30:29.523 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@14220a0c 2013-04-16 18:30:29.524 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:30:29.526 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 10. 2013-04-16 18:30:29.527 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:30:59.557 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:30:59.559 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@2d64ff8f 2013-04-16 18:30:59.561 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:30:59.562 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 11. 2013-04-16 18:30:59.564 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version 2013-04-16 18:31:29.582 INFO net.spy.memcached.MemcachedConnection: Reconnecting {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} 2013-04-16 18:31:29.584 INFO net.spy.memcached.MemcachedConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@59799a64 2013-04-16 18:31:29.585 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8} java.io.IOException: Disconnected unexpected, will reconnect. at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:430) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:915) 2013-04-16 18:31:29.587 WARN net.spy.memcached.MemcachedConnection: Closing, and reopening {QA sa=/127.0.0.1:11211, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: version, topWop=null, toWrite=0, interested=8}, attempt 12. 2013-04-16 18:31:29.588 WARN net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl: Discarding partially completed op: Cmd: version Memcached connection is trying to re-distribute the data on other nodes in a cluster which is why the connection is not getting established. |
| Comments |
| Comment by Michael Nitschinger [ 16/Apr/13 ] |
| Can you please post the code you used to initialize? |
| Comment by Deepti Dawar [ 17/Apr/13 ] |
| You can test this using the attached java file. |
| Comment by Michael Nitschinger [ 19/Apr/13 ] |
|
You need to authenticate correctly in order to connect to a bucket like this: AuthDescriptor authDescriptor = new AuthDescriptor(new String[]{"PLAIN"}, new PlainCallbackHandler("cache", "cache")); ConnectionFactory fact = new ConnectionFactoryBuilder() .setProtocol(ConnectionFactoryBuilder.Protocol.BINARY) .setAuthDescriptor(authDescriptor) .build(); MemcachedClient client = new MemcachedClient(fact, Arrays.asList(new InetSocketAddress("127.0.0.1", 11210))); client.set("foo", 0, "value"); System.out.println(client.get("foo")); client.shutdown(); |
| Comment by Michael Nitschinger [ 19/Apr/13 ] |
| also make sure to use binary with sasl. |
| Comment by Deepti Dawar [ 22/Apr/13 ] |
|
Its working fine after the authentication, but don't you think the behavior should be in sync for the single node and the 4 nodes cluster. Before handling the authentication, I was able to connect to only a 4 node cluster. Why is that so ? |
[JCBC-65] Client constructor blocks or deadlocks Created: 14/Jun/12 Updated: 17/Apr/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Martin Scott | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OS: Windows 7 64bit
JDK: 1.6.0_31 also 1.6.0_33 64 bit Couchbase enterprise edition running on 3 nodes all Ubuntu 10.04 64bit server (VMware images) |
||
| Attachments: |
log.txt
|
| Description |
|
I am evaluating the couchbase product and hit a brick wall immediately when running through the simple hello world example.
I have a 3 node cluster running couchbase enterprise 1.8.2 on ubuntu 10.04 64 bit VMware images. All three are running in VMWare player instances on Windows 7 64bit. When I try to run the Main example on Windows 7 using Java6 (64 bit) the code blocks somewhere in the Client constructor. The result is the logging below. 2012-06-14 14:07:46.313 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.150:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 14:07:46.316 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.151:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 14:07:46.319 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.152:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 14:07:59.843 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@24a4e2e3 2012-06-14 14:08:52.983 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@21ec6696 2012-06-14 14:08:52.987 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@27431340 I have also tried debugging but the code blocks in the constructor at client = new CouchbaseClient(uris, "default", ""); The program never completes. This works fine in a Linux environment with the following output received 2012-06-14 04:58:50.693 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.150:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 04:58:50.703 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.151:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 04:58:50.708 INFO com.couchbase.client.CouchbaseConnection: Added {QA sa=/192.168.186.152:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue 2012-06-14 04:58:50.830 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@1bc74f37 2012-06-14 04:58:50.834 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@3a21b220 2012-06-14 04:58:50.843 INFO com.couchbase.client.CouchbaseConnection: Connection state changed for sun.nio.ch.SelectionKeyImpl@732b3d53 2012-06-14 04:58:51.135 INFO com.couchbase.client.CouchbaseConnection: Shut down Couchbase client Set Succeeded Synchronous Get failed Asynchronous Get Succeeded: Hello World! Is there a JDK for windows 7 or a configuration setting that can be used to prevent this? |
| Comments |
| Comment by Raghavan Srinivas [ 14/Jun/12 ] |
|
Thanks for giving the Java client library a spin.
Were you able to connect to a single windows 7 node? I suspect it might be a firewall/networking issue and if you can use the netstat command (or the appropriate command on windows 7)? You may also want to follow the instructions noted in http://www.couchbase.com/docs/couchbase-manual-1.8/couchbase-bestpractice-cloud.html Changing IP addresses might be a cause for this. Finally, a more detailed log would be useful, if the network troubleshooting does not help. Please refer to http://www.couchbase.com/wiki/display/couchbase/Couchbase+Java+Client+Library for logging tips. |
| Comment by Martin Scott [ 14/Jun/12 ] |
|
Apologies that should read
Couchbase Version: 1.8.0 enterprise edition (build-55) |
| Comment by Martin Scott [ 14/Jun/12 ] |
| Detailed logging up to the point when the client hangs |
| Comment by Raghavan Srinivas [ 14/Jun/12 ] |
|
Thanks for the Log. I took a real quick look.
Were you able to follow the steps in http://www.couchbase.com/docs/couchbase-manual-1.8/couchbase-bestpractice-cloud.html and use the ip address that you are able to connect to (via the admin console)? |
| Comment by Alex Ma [ 14/Jun/12 ] |
|
Hi Martin,
Can you verify connectivity from the JDK on your windows box? This is what my connection code looks like: // Connection details for Couchbase List<URI> uris = new LinkedList<URI>(); uris.add(URI.create("http://10.4.2.3:8091/pools")); CouchbaseClient client = null; try { client = new CouchbaseClient(uris, "default", ""); } catch (Exception e) { System.err.println("except: connect: " + e.getMessage()); System.exit(-1); } This will create a persistent connection to 8091 on 10.4.2.3 as well as connections to 11210 on every node in the cluster. ssh'ing to 10.4.2.3 and running netstat - you should see something like whats below: netstat -nat|grep 10.32.3.50 tcp 0 0 10.4.2.3:11210 10.32.3.50:65437 ESTABLISHED tcp 0 0 10.4.2.3:8091 10.32.3.50:65442 ESTABLISHED tcp 0 304 ::ffff:10.4.2.3:22 ::ffff:10.32.3.50:65516 ESTABLISHED can you confirm this in your environment? thanks -Alex. |
| Comment by Martin Scott [ 18/Jun/12 ] |
|
Hi, thanks for the responses.
Here is the netstat output from my Windows client TCP 192.168.186.1:139 0.0.0.0:0 LISTENING InHost TCP 192.168.186.1:51008 192.168.186.150:22 ESTABLISHED InHost TCP 192.168.186.1:53281 192.168.186.150:8091 TIME_WAIT InHost TCP 192.168.186.1:53284 192.168.186.150:11210 ESTABLISHED InHost TCP 192.168.186.1:53285 192.168.186.151:11210 ESTABLISHED InHost TCP 192.168.186.1:53286 192.168.186.152:11210 ESTABLISHED InHost TCP 192.168.186.1:53292 192.168.186.150:8091 ESTABLISHED InHost and from the first node in the cluster with the client and other nodes. tcp 0 0 192.168.186.150:41317 192.168.186.150:11210 ESTABLISHED tcp 0 0 192.168.186.150:35883 192.168.186.151:11210 ESTABLISHED tcp 0 0 192.168.186.150:11210 192.168.186.151:38013 ESTABLISHED tcp 0 0 192.168.186.150:21100 192.168.186.152:46834 ESTABLISHED tcp 0 0 192.168.186.150:11210 192.168.186.1:53284 ESTABLISHED tcp 0 0 192.168.186.150:57559 192.168.186.151:22 TIME_WAIT tcp 0 0 192.168.186.150:8091 192.168.186.1:53292 ESTABLISHED tcp 0 48 192.168.186.150:22 192.168.186.1:51008 ESTABLISHED tcp 0 0 192.168.186.150:11210 192.168.186.150:41317 ESTABLISHED tcp 0 0 192.168.186.150:42433 192.168.186.152:11210 ESTABLISHED tcp 0 0 192.168.186.150:11210 192.168.186.150:56214 ESTABLISHED tcp 0 0 192.168.186.150:56214 192.168.186.150:11210 ESTABLISHED tcp 0 0 192.168.186.150:11210 192.168.186.152:39222 ESTABLISHED tcp 0 0 192.168.186.150:21100 192.168.186.151:60945 ESTABLISHED I downloaded the source jars from the maven repo and debugging shows the client hanging at the getLatch().await() line below. There doesn't appear to be any thread calling the countDown method on the latch before or after this is called. private ChannelFuture getReceivedFuture() { try { getLatch().await(); } catch (InterruptedException ex) { finerLog("Getting received future has been interrupted."); } return receivedFuture; } Martin. |
| Comment by Martin Scott [ 18/Jun/12 ] |
|
The stack trace where the client blocks
Thread [main] (Stepping) BucketUpdateResponseHandler.getReceivedFuture() line: 147 BucketUpdateResponseHandler.getLastResponse() line: 127 BucketMonitor.startMonitor() line: 183 ConfigurationProviderHTTP.subscribe(String, Reconfigurable) line: 243 CouchbaseClient.<init>(CouchbaseConnectionFactory, boolean) line: 158 CouchbaseClient.<init>(CouchbaseConnectionFactory) line: 125 CouchbaseClient.<init>(List<URI>, String, String) line: 77 Main.main(String[]) line: 67 |
| Comment by sean diamond [ 23/Jan/13 ] |
|
I am having this exact same problem. Using windows 7 64 bit trying to connect to ubuntu.
I am using 32 bit os on linux and couchbase server 2.0. I am also using the lastest java client version 1.1 Same Issue as described below. The only workaround is to not use windows, if my java client is running on linux then it will work with no issues, it just deadlocks on the windows machine. |
| Comment by Tug Grall [ 17/Apr/13 ] |
|
I am reopening the issue as we see this error again on some environment:
- Yuval - http://www.couchbase.com/issues/browse/JCBC-65 ... Let me know if you prefer me to create a new issue for 1.1.x |
[JCBC-283] Document how best to use expiry with times >30 days Created: 12/Apr/13 Updated: 12/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| 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: 08/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.5 |
| Fix Version/s: | None |
| 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-278] ConnectionFactoryBuilder has wrong default settings Created: 02/Apr/13 Updated: 03/Apr/13 Resolved: 03/Apr/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.4 |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Task | Priority: | Blocker |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The Builder uses wrong failure mode and default hash, they differ from instantiating the factory directly. This causes inconsistencies and also EPT node failures not to be detected properly.
|
| Comments |
| Comment by Frank Weigel [ 03/Apr/13 ] |
| WIll changing hash affect customers upgrading? (i.e. not finding old data) |
[JCBC-279] Docs: Cross-link bulk loading and blocking queue documentation with async commands Created: 02/Apr/13 Updated: 02/Apr/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | docs |
| Affects Version/s: | 1.1.4 |
| Fix Version/s: | None |
| 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-277] Provide warnings when dependencies don't match expected versions Created: 26/Mar/13 Updated: 26/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.4 |
| Fix Version/s: | None |
| 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 |
|
Recent issues with netty dependencies would be easier caught if we had logging when dependencies are mismatched from what we expect.
|
[JCBC-4] building shippable artifacts under CI Created: 12/Jan/12 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | .next |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Deepti Dawar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
This is simply generating the JAR files under CI.
|
| Comments |
| Comment by Deepti Dawar [ 26/Mar/13 ] |
|
This has been handled in the jenkins job : http://sdkbuilds.couchbase.com/job/java-snapshot-build/ |
[JCBC-1] ensure building under CI Created: 05/Jan/12 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | infrastructure |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | .next |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Deepti Dawar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Comments |
| Comment by Deepti Dawar [ 26/Mar/13 ] |
|
This has been handled in the jenkins job : http://sdkbuilds.couchbase.com/job/java-snapshot-build/ |
[JCBC-35] Exception during reconfiguring of client Created: 23/Apr/12 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.0.2 |
| Fix Version/s: | 1.1-beta |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Marcus Nylander | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
couchbase-client 1.0.2
java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Linux 2.6.18-238.19.1.el5 #1 SMP Sun Jul 10 08:43:41 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux |
||
| Attachments: |
log.txt
|
| Description |
|
Multiple different stackstraces below also see the following right before it starts to fail:
"Node exepcted to receive data is inactive. This could be due to afailure within the cluster. Will check for updated configuration. Key without a configured node is: akey12324234" Then it's fails a number of times and Failed to reconfigure client, staying with previous configuration. java.lang.IllegalArgumentException: TODO: refactor this at com.couchbase.client.vbucket.config.CacheConfig.getVbucketsCount(CacheConfig.java:55) at com.couchbase.client.vbucket.config.DefaultConfig.compareTo(DefaultConfig.java:145) at com.couchbase.client.vbucket.VBucketNodeLocator.updateLocator(VBucketNodeLocator.java:133) at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:120) at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:176) at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54) at java.util.Observable.notifyObservers(Observable.java:142) at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:257) at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:187) at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:243) at com.couchbase.client.vbucket.ConfigurationProviderHTTP.finishResubscribe(ConfigurationProviderHTTP.java:215) at com.couchbase.client.CouchbaseConnectionFactory.checkConfigUpdate(CouchbaseConnectionFactory.java:182) at com.couchbase.client.CouchbaseConnection.addOperation(CouchbaseConnection.java:165) at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639) at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:835) at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:997) Failed to reconfigure client, staying with previous configuration. java.lang.IllegalArgumentException: TODO: refactor this at com.couchbase.client.vbucket.config.CacheConfig.getVbucketsCount(CacheConfig.java:55) at com.couchbase.client.vbucket.config.DefaultConfig.compareTo(DefaultConfig.java:145) at com.couchbase.client.vbucket.VBucketNodeLocator.updateLocator(VBucketNodeLocator.java:133) at com.couchbase.client.CouchbaseConnection.reconfigure(CouchbaseConnection.java:120) at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:176) at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54) at java.util.Observable.notifyObservers(Observable.java:142) at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:257) at com.couchbase.client.vbucket.BucketMonitor.replaceConfig(BucketMonitor.java:307) at com.couchbase.client.vbucket.BucketUpdateResponseHandler.messageReceived(BucketUpdateResponseHandler.java:81) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) at com.couchbase.client.vbucket.BucketUpdateResponseHandler.handleUpstream(BucketUpdateResponseHandler.java:194) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.unfoldAndfireMessageReceived(ReplayingDecoder.java:513) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:497) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:434) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:340) at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:272) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:192) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) |
| Comments |
| Comment by Matt Ingenthron [ 11/Oct/12 ] |
| This may have been fixed in configuraton changes in 1.0.3, but that should be verified. |
| Comment by Michael Nitschinger [ 28/Nov/12 ] |
| http://review.couchbase.org/#/c/22878/ |
| Comment by Michael Nitschinger [ 29/Nov/12 ] |
| fixed and pushed to master, will be available in in dp5/beta. |
| Comment by Michael Nitschinger [ 26/Mar/13 ] |
| Already fixes back in time, don't know why it is open. |
[JCBC-232] Javadoc jar files should be renamed to be compliant with IDEs Created: 04/Feb/13 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | infrastructure |
| Affects Version/s: | 1.1.0, 1.1.1 |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Tug Grall | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
IntelliJ Idea won't automatically download couchbase-client-*-javadocs.jar or spymemcached-*-javadocs.jar from http://files.couchbase.com/maven2/ because they have an "s" at the end of "javadoc".
I don't know whether any other IDE's have trouble with this, but the standard appears to be "XXX-javadoc.jar" instead of "XXX-javadocs.jar". The executable and source jars download fine. Can this be changed for a future version? See : http://www.couchbase.com/forums/thread/java-sdk-javadoc-maven-download-problem |
[JCBC-135] Using Couchbase inside netty server fails Created: 25/Oct/12 Updated: 26/Mar/13 Resolved: 26/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Mike Wiederhold | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Flagged: |
Release Note
|
| Description |
|
See this forum question for a description of the issue as well as the fix for it:
http://www.couchbase.com/forums/thread/using-couchbaseclient-inside-netty-server |
| Comments |
| Comment by Michael Nitschinger [ 16/Nov/12 ] |
| http://review.couchbase.com/#/c/22589/ |
| Comment by Michael Nitschinger [ 16/Nov/12 ] |
|
I could reproduce this issue by instantiating a couchbase server inside a handler. If you instantiate the connection outside it works. Here is the code to reproduce it:
when you run it in the IDE and telnet to localhost 8080 it will die and throw the exception: package com.couchbase.nettyexample; import com.couchbase.client.CouchbaseClient; import java.io.IOException; import java.net.InetSocketAddress; import java.net.URI; import java.util.Arrays; import java.util.concurrent.Executors; import org.jboss.netty.bootstrap.ServerBootstrap; import org.jboss.netty.channel.ChannelHandlerContext; import org.jboss.netty.channel.ChannelPipeline; import org.jboss.netty.channel.ChannelPipelineFactory; import org.jboss.netty.channel.Channels; import org.jboss.netty.channel.MessageEvent; import org.jboss.netty.channel.SimpleChannelUpstreamHandler; import org.jboss.netty.channel.socket.nio.NioServerSocketChannelFactory; /** * Hello world! * */ public class App { private final int port = 8080; private CouchbaseClient client; public void run() throws IOException { ServerBootstrap bootstrap = new ServerBootstrap( new NioServerSocketChannelFactory( Executors.newCachedThreadPool(), Executors.newCachedThreadPool() ) ); bootstrap.setPipelineFactory(new ChannelPipelineFactory() { public ChannelPipeline getPipeline() throws Exception { return Channels.pipeline(new EchoServerHandler()); } }); bootstrap.bind(new InetSocketAddress(port)); } public static void main(String[] args) throws IOException { new App().run(); } class EchoServerHandler extends SimpleChannelUpstreamHandler { private CouchbaseClient client; public EchoServerHandler() throws IOException { this.client = new CouchbaseClient( Arrays.asList(URI.create("http://localhost:8091/pools")), "default", "" ); this.client.set("received", 0, "foo"); } @Override public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) { System.out.println("Received Message"); System.out.println(client.get("received")); } } } |
| Comment by Michael Nitschinger [ 26/Mar/13 ] |
| will be available in 1.1.5. |
[JCBC-275] Slow performance in virtualized environments Created: 18/Mar/13 Updated: 20/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | None |
| 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-271] Adding a node to an existing cluster causes issues with a running memcached bucket Created: 13/Mar/13 Updated: 16/Mar/13 Resolved: 16/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | 3 node cluster of 2.0, one memcached bucket authenticated, Couchbase Java Client 1.1.2 with required spymemcached 2.8.11 | ||
| Attachments: |
CBSE-472repro.txt
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Description |
|
When adding a node to a cluster, I'd observed a number of AssertionErrors and some very odd errors about connections being null.
This popped up when I wasn't expecting an issue, so I'm a bit surprised. The scenario I think is: Steps to reproduce: 1. Have two nodes running (.200 and .201 in my case here) 2. Add another node (.202 in my case here) See the logs for what detail is available. |
| Comments |
| Comment by Michael Nitschinger [ 15/Mar/13 ] |
| This is the same root cause, the channel gets overriden on add. |
| Comment by Michael Nitschinger [ 15/Mar/13 ] |
| http://review.couchbase.com/#/c/25171/ |
| Comment by Matt Ingenthron [ 16/Mar/13 ] |
| Yes, that fixed the issue. I had some issues on adding that node back, but there was a problem at the cluster side. |
[JCBC-273] Unknown Host Exception should be caught Created: 15/Mar/13 Updated: 15/Mar/13 |
|
| 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: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Encountered these errors while running on Jenkins. These need to be handled.
Stack Trace : [junit] Testcase: testMessageReceived took 0.173 sec [junit] Testsuite: com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest [junit] 2013-03-15 04:07:54.268 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogus:8091/pools ...skipping [junit] java.net.UnknownHostException: bogus [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) [junit] at java.net.Socket.connect(Socket.java:546) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:240) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338) [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935) [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876) [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801) [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit] at java.lang.reflect.Method.invoke(Method.java:616) [junit] at junit.framework.TestCase.runTest(TestCase.java:168) [junit] at junit.framework.TestCase.runBare(TestCase.java:134) [junit] at junit.framework.TestResult$1.protect(TestResult.java:110) [junit] at junit.framework.TestResult.runProtected(TestResult.java:128) [junit] at junit.framework.TestResult.run(TestResult.java:113) [junit] at junit.framework.TestCase.run(TestCase.java:124) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232) [junit] at junit.framework.TestSuite.run(TestSuite.java:227) [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) [junit] 2013-03-15 04:07:54.724 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogustoo:8091/pools ...skipping [junit] java.net.UnknownHostException: bogustoo [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) [junit] at java.net.Socket.connect(Socket.java:546) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:240) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338) [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935) [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876) [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801) [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit] at java.lang.reflect.Method.invoke(Method.java:616) [junit] at junit.framework.TestCase.runTest(TestCase.java:168) [junit] at junit.framework.TestCase.runBare(TestCase.java:134) [junit] at junit.framework.TestResult$1.protect(TestResult.java:110) [junit] at junit.framework.TestResult.runProtected(TestResult.java:128) [junit] at junit.framework.TestResult.run(TestResult.java:113) [junit] at junit.framework.TestCase.run(TestCase.java:124) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232) [junit] at junit.framework.TestSuite.run(TestSuite.java:227) [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.991 sec [junit] ------------- Standard Error ----------------- [junit] 2013-03-15 04:07:54.268 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogus:8091/pools ...skipping [junit] java.net.UnknownHostException: bogus [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) [junit] at java.net.Socket.connect(Socket.java:546) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:240) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338) [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935) [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876) [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801) [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit] at java.lang.reflect.Method.invoke(Method.java:616) [junit] at junit.framework.TestCase.runTest(TestCase.java:168) [junit] at junit.framework.TestCase.runBare(TestCase.java:134) [junit] at junit.framework.TestResult$1.protect(TestResult.java:110) [junit] at junit.framework.TestResult.runProtected(TestResult.java:128) [junit] at junit.framework.TestResult.run(TestResult.java:113) [junit] at junit.framework.TestCase.run(TestCase.java:124) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232) [junit] at junit.framework.TestSuite.run(TestSuite.java:227) [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) [junit] 2013-03-15 04:07:54.724 WARN com.couchbase.client.vbucket.ConfigurationProviderHTTP: Connection problems with URI http://bogustoo:8091/pools ...skipping [junit] java.net.UnknownHostException: bogustoo [junit] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:175) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) [junit] at java.net.Socket.connect(Socket.java:546) [junit] at sun.net.NetworkClient.doConnect(NetworkClient.java:173) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:409) [junit] at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) [junit] at sun.net.www.http.HttpClient.<init>(HttpClient.java:240) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:321) [junit] at sun.net.www.http.HttpClient.New(HttpClient.java:338) [junit] at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935) [junit] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876) [junit] at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801) [junit] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readToString(ConfigurationProviderHTTP.java:417) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.readPools(ConfigurationProviderHTTP.java:210) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.getBucketConfiguration(ConfigurationProviderHTTP.java:147) [junit] at com.couchbase.client.vbucket.ConfigurationProviderHTTPDownNodeTest.testGetBucketConfiguration(ConfigurationProviderHTTPDownNodeTest.java:67) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit] at java.lang.reflect.Method.invoke(Method.java:616) [junit] at junit.framework.TestCase.runTest(TestCase.java:168) [junit] at junit.framework.TestCase.runBare(TestCase.java:134) [junit] at junit.framework.TestResult$1.protect(TestResult.java:110) [junit] at junit.framework.TestResult.runProtected(TestResult.java:128) [junit] at junit.framework.TestResult.run(TestResult.java:113) [junit] at junit.framework.TestCase.run(TestCase.java:124) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:232) [junit] at junit.framework.TestSuite.run(TestSuite.java:227) [junit] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) |
| Comments |
| Comment by Michael Nitschinger [ 15/Mar/13 ] |
| Why should it be caught? The UnknownHostException is semantically 100% spot on. |
| Comment by Deepti Dawar [ 15/Mar/13 ] |
| If it is not caught, it should be handled in the junit test such that the junit test should expect that exception otherwise the test fails. |
[JCBC-272] removing non-bootstrap node with memcached bucket okay, but adding the same node results in failures Created: 13/Mar/13 Updated: 15/Mar/13 Resolved: 15/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.5 |
| Security Level: | Public |
| Type: | Bug | Priority: | Critical |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | Client 1.1.2 with required spymemcached 2.8.11. Server 2.0.0 with a single authenticated memcached bucket. Assertions enabled. | ||
| Issue Links: |
|
||||||||
| Description |
|
From the attached log, one will see first the removal of a node (click remove -> click rebalance), and things are generally okay.
Following that, you'll see the node added (via the config wizard, joining to node 192.168.1.200), and one configuration received, but nothing actually used yet. Following that, you'll see the node rebalanced in with a set of assertion errors and then workload ceases. Notably: 2013-03-13 19:29:03.924 INFO com.couchbase.client.CouchbaseMemcachedConnection: Reconnecting {QA sa=/192.168.1.201:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: 0 Opaque: 139891 Key: pool-25-thread-1:48454, topWop=null, toWrite=0, interested=1} Exception in thread "Memcached IO over {MemcachedConnection to /192.168.1.200:11210 /192.168.1.202:11210 /192.168.1.201:11210}" java.lang.AssertionError: Attempting to overwrite channel |
| Comments |
| Comment by Deepti Dawar [ 14/Mar/13 ] |
|
In this scenario, I am encountering something like this : [INFO 33.11 cbsdk.scenario failover.py:198] Sleeping for 60 seconds after failover [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM net.spy.memcached.MemcachedConnection handleIO [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] INFO: Reconnecting due to exception on {QA sa=/10.3.2.57:11210, #Rops=1, #Wops=0, #iq=0, topRop=Cmd: 0 Opaque: 5552 Key: SimpleKey__REP_149, topWop=null, toWrite=0, interested=1} [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] java.io.IOException: Disconnected unexpected, will reconnect. [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:526) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:454) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158) [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM net.spy.memcached.MemcachedConnection queueReconnect [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] WARNING: Closing, and reopening {QA sa=/10.3.2.57:11210, #Rops=1, #Wops=0, #iq=1, topRop=Cmd: 0 Opaque: 5552 Key: SimpleKey__REP_149, topWop=null, toWrite=0, interested=1}, attempt 0. [SDKD(WARNING) 33.12 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM net.spy.memcached.protocol.TCPMemcachedNodeImpl setupResend [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] WARNING: Discarding partially completed op: Cmd: 0 Opaque: 5552 Key: SimpleKey__REP_149 [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM com.couchbase.sdkd.cbclient.CommandResult warnAbout [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] WARNING: Unknown exception encountered (for operation) future warnings will be suppressed [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] java.lang.RuntimeException: Cancelled [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:169) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:132) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.PendingCommand.onReady(PendingCommand.java:55) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.OperationCollector.submitSync(OperationCollector.java:114) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.OperationCollector.submit(OperationCollector.java:131) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.GetCommandContext.doOneCommand(GetCommandContext.java:64) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.CommandContext.execIter(CommandContext.java:276) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.cbclient.CommandContext.execute(CommandContext.java:311) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:135) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:156) [SDKD(WARNING) 33.13 cbsdk.sdkd.local executor.py:66] at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:212) [SDKD(WARNING) 33.16 cbsdk.sdkd.local executor.py:66] Mar 14, 2013 2:17:37 AM com.couchbase.client.CouchbaseMemcachedConnection reconfigure [SDKD(WARNING) 33.17 cbsdk.sdkd.local executor.py:66] INFO: Scheduling Node /10.3.2.57:11210for shutdown. |
[JCBC-252] Rebound phase encounter assertion errors with memcached connection Created: 25/Feb/13 Updated: 12/Mar/13 Resolved: 12/Mar/13 |
|
| Status: | Closed |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
assertion_errors_still_reproducible.txt
scenario_passing.log
|
| Description |
|
Failover one node and add it back while the couchbase server is getting started.
The workload that is applied is the GetSetWorkload. Many assertion errors are appearing in the rebound phase related to state of MemcachedConnection. |
| Comments |
| Comment by Mark Nunberg [ 25/Feb/13 ] |
| The log says this is using the 1.1.1 SDK. The current version is 1.1.2 |
| Comment by Deepti Dawar [ 12/Mar/13 ] |
|
Finding with the latest version attached.
The scenario passes fine with this version. Hence, closing the issue. |
[JCBC-261] Warmup Backoff breaks Memcache Buckets Created: 11/Mar/13 Updated: 12/Mar/13 Resolved: 12/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.3 |
| Fix Version/s: | 1.1.4 |
| Security Level: | Public |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Michael Nitschinger | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
A recent change regarding warmup backoff breaks compat with memcache type buckets.
|
[JCBC-265] ConfigurationProviderMock fails during test. Created: 12/Mar/13 Updated: 12/Mar/13 Resolved: 12/Mar/13 |
|
| Status: | Resolved |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | 1.1.4 |
| Security Level: | Public |
| Type: | Bug | Priority: | Minor |
| Reporter: | Deepti Dawar | Assignee: | Michael Nitschinger |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
Hi Michael,
This issue is reproducible as below : java.lang.AssertionError: Could not verify the init of a memcache bucket at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at com.couchbase.client.CouchbaseClientMemcachedBucketTest.testMemcacheBucketInitialization(CouchbaseClientMemcachedBucketTest.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) |
| Comments |
| Comment by Michael Nitschinger [ 12/Mar/13 ] |
| This is already up on review: http://review.couchbase.com/#/c/25101/ |
[JCBC-264] create a unit test for ensuring couchbase client configuration works with memcached bucket type Created: 11/Mar/13 Updated: 11/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | Public |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Michael Nitschinger |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
With a recent bug, we had the config's lack of warmup throwing off the configuration provider. This should be unit-testable since we have unit tests for the configuration provider.
|
| Comments |
| Comment by Matt Ingenthron [ 11/Mar/13 ] |
| Opened on the wrong project. I'll fix it. |
[JCBC-263] memcached connection fails with "Attempting to overwrite channel" Created: 11/Mar/13 Updated: 11/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.2 |
| Fix Version/s: | None |
| 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 | ||
| Environment: |
This is a "run of the mill" memcached instance. I have not particularly been able to reproduce it though - nevertheless I am placing it in here so that it may be noted.
Server version is 2.0.0 |
||
| Description |
|
In this case, multiple CouchbaseClient objects are being connected. At the 14th instance, this is printed to the screen and the application hangs.
[SDKD(WARNING) 5.49 cbsdk.sdkd.remote remote.py:266] WARNING: URIs: [http://10.2.1.102:8091/pools?#] [SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM com.couchbase.sdkd.cbclient.Handle makeViewTimeout [SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] WARNING: [SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection createConnections [SDKD(WARNING) 5.51 cbsdk.sdkd.remote remote.py:266] INFO: Added {QA sa=/10.2.1.102:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection createConnections [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Added {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} to connect queue [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM com.couchbase.client.CouchbaseClient <init> [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: viewmode property isn't defined. Setting viewmode to production mode [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@6d79953c [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO [SDKD(WARNING) 5.53 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@4934ce4a [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=8}, attempt 1. [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection handleIO [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting due to failure to connect to {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0} [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] java.net.ConnectException: Could not send noop upon connect! This may indicate a running, but not responding memcached instance. [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:439) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:247) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}, attempt 1. [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] WARNING: Closing, and reopening {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0}, attempt 3. [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.MemcachedConnection queueReconnect [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] INFO: The channel or socket was null for {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0} [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] Exception in thread "SDK Handle-14" java.lang.NullPointerException [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.queueReconnect(MemcachedConnection.java:589) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.reconfigure(CouchbaseMemcachedConnection.java:132) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseClient.reconfigure(CouchbaseClient.java:273) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.ReconfigurableObserver.update(ReconfigurableObserver.java:54) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at java.util.Observable.notifyObservers(Observable.java:159) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.BucketMonitor.setBucket(BucketMonitor.java:258) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.BucketMonitor.startMonitor(BucketMonitor.java:188) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.vbucket.ConfigurationProviderHTTP.subscribe(ConfigurationProviderHTTP.java:288) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:246) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.SdkdConfig.getClient(SdkdConfig.java:99) [SDKD(WARNING) 5.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.cbclient.Handle.<init>(Handle.java:159) [SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.executeCommand(SdkServer.java:104) [SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.handleRequest(SdkServer.java:189) [SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] at com.couchbase.sdkd.server.SdkServer.run(SdkServer.java:245) [SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:20 PM net.spy.memcached.auth.AuthThread$1 receivedStatus [SDKD(WARNING) 5.59 cbsdk.sdkd.remote remote.py:266] INFO: Authenticated to /10.2.1.102:11210 [SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.MemcachedConnection attemptReconnects [SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=1, #iq=0, topRop=null, topWop=Cmd: 10 Opaque: 55, toWrite=0, interested=0} [SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.MemcachedConnection handleIO [SDKD(WARNING) 13.55 cbsdk.sdkd.remote remote.py:266] INFO: Connection state changed for sun.nio.ch.SelectionKeyImpl@79884a40 [SDKD(WARNING) 13.56 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:28 PM net.spy.memcached.auth.AuthThread$1 receivedStatus [SDKD(WARNING) 13.56 cbsdk.sdkd.remote remote.py:266] INFO: Authenticated to /10.2.1.101:11210 [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] Mar 8, 2013 5:39:36 PM net.spy.memcached.MemcachedConnection attemptReconnects [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] INFO: Reconnecting {QA sa=/10.2.1.101:11210, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] Exception in thread "Memcached IO over {MemcachedConnection to /10.2.1.102:11210 /10.2.1.101:11210}" java.lang.AssertionError: Attempting to overwrite channel [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.setChannel(TCPMemcachedNodeImpl.java:496) [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.protocol.TCPMemcachedNodeImpl.registerChannel(TCPMemcachedNodeImpl.java:484) [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.attemptReconnects(MemcachedConnection.java:680) [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:262) [SDKD(WARNING) 21.55 cbsdk.sdkd.remote remote.py:266] at com.couchbase.client.CouchbaseMemcachedConnection.run(CouchbaseMemcachedConnection.java:158) |
[JCBC-262] Transcoder error not reported correctly Created: 11/Mar/13 Updated: 11/Mar/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1.3 |
| Fix Version/s: | None |
| 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-3] running integration tests under CI Created: 12/Jan/12 Updated: 11/Mar/13 Resolved: 11/Feb/13 |
|
| Status: | Closed |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | .next |
| Security Level: | Public |
| Type: | Task | Priority: | Major |
| Reporter: | Matt Ingenthron | Assignee: | Deepti Dawar |
| Resolution: | Fixed | Votes: | 0 |
| Labels: |