Hi, I’ve noticed that all the Github async examples for the Java client use two synchronized methods: waitTillComplete() and notifyComplete().
For my application, I’ve created a Spring repository with a method that creates new command object instances, within each of which I replicate this usage from the examples. However, under load (e.g. 200 tps w/ records in the 1 MB range), I am seeing this method – which is more-or-less a basic async client.get(policy, listener, key) call – averaging around 20-30 ms response time, and about 20 ms for the wait() method.
This seems a lot higher than I expected to see, particularly for the wait() call. I suspect this is due to the use of the synchronized methods, and I am wondering if it is both safe and faster to refactor my code to avoid their use, probably by instead implementing an RxJava reactive adapter to the Aerospike listeners.
I am still wrapping my head around multithreading with Java as well as familiarizing myself with the nuances of the Aerospike client, so I am I thinking about this correctly? Has anyone tried this?
Yes! It will be safe and faster to remove the waitTillComplete()/notifyComplete() paradigm from your application. Notice that the async benchmarks do not use this paradigm at all.
The only reason waitTillComplete()/notifyComplete() exists is because the examples/test framework is inherently synchronous. For examples, we thought intertwined messages from async commands running in parallel might be confusing to the user. For test, junit requires all assertions to be performed before the calling test method completes. This requires us to wait till async command(s) completes for each test.
We can’t change tests, but I think we could remove waitTillComplete()/notifyComplete() from the async examples. We will look into it.
Hi, I use the Async client with Kotlin + Coroutines + RxJava. But pure Java w/ RxJava would work as well. I am able to write 20-50K TPS of larger records, 256K - 1MB range. If you use the waitTillComplete method they block your java thread on the async. Instead you need to use a Listener that integrates with your other async code.
RxJava is a good choice. The learning curve can be a bit steep here. I am not using the Spring repository.