In the Aerospike Java client asynchronous API there are two methods,
NioEventLoops.next() where incrementing the event iterator is not atomic and there is a code comment to state that this behaviour is by design, why is that?
When the Aerospike Java client was written, one of the guiding principles was to provide an optimized default implementation and allow for a separate, user defined, atomic event loop iterator.
Perfect event loop distribution requires that all commands take the same amount of time to complete. The commands processed by an event loop within the Aerospike Java client may take substantially different amounts of time to execute. A single read, for example, may take much longer than a batch read or a write. This means that the event loop distribution is inherently imperfect.
In testing, a non-atomic counter for incrementing event loops, results showed that only 4 out of 10,000 increments chose the same event loop, which has an effectively negligible effect on event loop distribution compared to the variation in command execution time.
When a group of asynchronous commands are executed from the same thread, the non-atomic counter consistently chooses the next event loop correctly.
If a situation arose where multiple instances of the same command need to be distributed across disparate event loops, this is possible with the following general approach:
- Divide total number of commands (T) by number of event loops (N) to get a number of commands per event loop (B).
- Initiate max concurrent seed commands (C) across the N event loops. The non atomic counter will work correctly here as the seed commands are all emanating from the same thread.
- Each command listener will get a call back in their respective thread. When this occurs, issue exactly one more command on the same event loop as the callback.
- Repeat process until B commands have been issued to that event loop.
- The Java client API Reference can be found here
JAVA ASYNC EVENT LOOP ATOMIC