Closed GoogleCodeExporter closed 8 years ago
Pardon my ignorance but it seems "simple" to implement, at least for the
mutate() call -- i.e. not for mutateWithDefault().
It seems all that is needed is a asyncMutate() function:
private Future<Long> asyncMutate(Mutator m, String key, int by, long def, int exp)
throws OperationTimeoutException {
final CountDownLatch latch=new CountDownLatch(1);
final OperationFuture<Long> rv=new OperationFuture<Long>(latch,
operationTimeout);
addOp(key, opFact.mutate(m, key, by, def, exp, new OperationCallback() {
public void receivedStatus(OperationStatus s) {
// XXX: Potential abstraction leak.
// The handling of incr/decr in the binary protocol
// Allows us to avoid string processing.
rv.set(new Long(s.isSuccess()?s.getMessage():"-1"));
}
public void complete() {
latch.countDown();
}}));
return rv;
}
Then we can trivially add asyncIncr() and asyncDecr():
public Future<Long> asynIncr(String key, int by) throws OperationTimeoutException {
return asyncMutate(Mutator.incr, key, by, 0, -1);
}
public Future<Long> asyncDecr(String key, int by) throws OperationTimeoutException {
return asyncMutate(Mutator.decr, key, by, 0, -1);
}
Of course mutate() itself would be implemented in terms of asyncMutate():
private long mutate(Mutator m, String key, int by, long def, int exp)
throws OperationTimeoutException {
try
{
return asyncMutate(m, key, by, def, exp).get(operationTimeout,
TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
throw new RuntimeException("Interrupted waiting for value", e);
} catch (ExecutionException e) {
throw new RuntimeException("Exception waiting for value", e);
} catch (TimeoutException e) {
throw new OperationTimeoutException("Timeout waiting for value", e);
}
}
Now asyncMutateWithDefault() that's a bit more complicated.
No?
Original comment by nbrac...@gmail.com
on 28 Aug 2008 at 7:18
You're right, it's the with-default that's the issue. That's the only way it
makes
sense to use incr/decr to me.
I implemented it in the binary protocol in such a way that it can be done in a
single
request, but before that, the multiple round trip thing had to happen.
Original comment by dsalli...@gmail.com
on 29 Aug 2008 at 6:58
This is implemented as of 6e2dbb3aac1a2980bc2252670467e219d803a3d8 -- Thanks to
Kristian Eide
Original comment by dsalli...@gmail.com
on 2 Oct 2008 at 7:04
I was clearly out of my head when I closed this bug. Apologies.
Original comment by dsalli...@gmail.com
on 10 Oct 2008 at 5:06
nbrachet: I'd like to credit you for this change. Can you send me a name and
email
address to dustin@spy.net?
Original comment by dsalli...@gmail.com
on 18 Oct 2008 at 11:44
This is fixed in my async-mutate branch. I'll apply it to stable either once I
get
information to credit nbrachet, or early next week.
Original comment by dsalli...@gmail.com
on 18 Oct 2008 at 11:56
Original comment by dsalli...@gmail.com
on 18 Oct 2008 at 11:57
pushed
Original comment by dsalli...@gmail.com
on 19 Oct 2008 at 12:08
Original issue reported on code.google.com by
dsalli...@gmail.com
on 19 Mar 2008 at 4:52