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

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

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


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

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




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

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

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


 Description   
Hi,

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

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

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

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

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

Richards Peter.




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

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

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

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

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

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

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

Is there a desired behavior? What's the scenario?
Comment by Abhishek Singh [ 10/Oct/14 ]
Hi Matt,

>> 1) It is still relevant. Are you indicating there's a bug you've seen?

I'm following up, since Jeff is out for few days. Attached a sample program *App.java*

SDK log: https://s3.amazonaws.com/customers.couchbase.com/abhishek/6570-sdk.log

client settings:

```
builder.setFailureMode(FailureMode.Redistribute)
builder.setTimeoutExceptionThreshold(10);
builder.setOpTimeout(50);
````

Test Scenario:

1. Have a 4 node CB cluster.
2. Start the sample program against the cluster. Stop CB on the node where the key in program mapped to.
3. Let the program run for couple of minutes.
4. Start CB back up(optional).

Log snippet:

```
Consecutive failures :596
In case of error couchbase takes 51 milliseconds
2014-10-09 21:33:28.173 INFO com.couchbase.client.CouchbaseConnection: Node for key "my-first-document" is not active (yet). Queueing up for retry and checking for stale configuration.
Consecutive failures :597
In case of error couchbase takes 51 milliseconds
2014-10-09 21:33:28.224 INFO com.couchbase.client.CouchbaseConnection: Node for key "my-first-document" is not active (yet). Queueing up for retry and checking for stale configuration.
2014-10-09 21:33:28.235 INFO com.couchbase.client.CouchbaseConnection: Reconnecting {QA sa=10.4.2.115/10.4.2.115:11210, #Rops=0, #Wops=589, #iq=0, topRop=null, topWop=Cmd: 0 Opaque: 23941 Key: my-first-document, toWrite=0, interested=0}
```

Expectation was node-115 to be deemed down after 10 timeouts and post that requests should fail fast instead of waiting till timeout value, observation was operations against the down node went forever.




Generated at Wed Oct 22 17:46:32 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.