Closed yarosman closed 3 years ago
The EventLoop argument to async commands exists because there are cases where a group of commands need to be placed on the same eventloop. This is advantageous because shared data between these commands can be accessed without the use of atomics. Forcing round-robin eventloop distribution will not work for this use case.
I'm considering adding the following code to each async command that performs round-robin distribution as a default when the EventLoop argument is null.
if (eventLoop == null) {
eventLoop = cluster.eventLoops.next();
}
Would that suffice?
@BrianNichols Yes, I think it will be enought. And what do you mean: "This is advantageous because shared data between these commands can be accessed without the use of atomics."? Can you show examples ?
A simple example is running 3 async commands and then performing an action when all commands complete. The implementation requires a shared counter to count each command completion. That shared counter can use an non-atomic increment (count++) when all 3 async commands are run in the same event loop.
Java client 5.0.3 released.
https://www.aerospike.com/download/client/java/notes.html#5.0.3
From official documentation https://www.aerospike.com/docs/client/java/usage/async/index.html for using aerospike client in async mode you should define
EventLoop
in client policy, and after that call directlyeventLoops.next()
Why under the hood aerospike can't use
eventLoops
fromClientPolicy
? And I have to do it by myself