cbc_server_all_nodes_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-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-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-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-304] Client leads to a deadlock when all the servers are unavailable Created: 21/May/13 Updated: 24/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: | Matt Ingenthron |
| 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 ? |