[JCBC-222] prioritized disk write queue - java client Created: 28/Jan/13 Updated: 31/Jan/13 |
|
| Status: | Open |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | None |
| Fix Version/s: | .next |
| Security Level: | Public |
| Type: | Improvement | Priority: | Major |
| Reporter: | Alex Ma | Assignee: | Matt Ingenthron |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
ability for the client to specify that a write should be prioritized and the server to fast track that write to disk ahead of whatever might be in the disk write queue. Especially important during the case of rebalance where they may be a million+ items in the queue and the write needs to be prioritized for whatever purpose.
Should be able to work with observe operations as well as observe+xdcr(http://www.couchbase.com/issues/browse/MB-7614) |
[JCBC-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 ? |
[JCBC-18] NPE if hostnames in server bootstrap list are mixed case Created: 12/Mar/12 Updated: 12/Jun/13 |
|
| Status: | Reopened |
| Project: | Couchbase Java Client |
| Component/s: | library |
| Affects Version/s: | 1.1-dp4 |
| Fix Version/s: | 1.1.8 |
| 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 |