FAQ - Why are some java client methods not atomic by design?

The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.

FAQ - Why are some java client methods not atomic by design?

Detail

In the Aerospike Java client asynchronous API there are two methods, NettyEventLoops.next() and 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?

Answer

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.

Notes

Keywords

JAVA ASYNC EVENT LOOP ATOMIC

Timestamp

July 2021