[
https://issues.jboss.org/browse/ISPN-5962?page=com.atlassian.jira.plugin....
]
Dan Berindei updated ISPN-5962:
-------------------------------
Attachment: CompletableFutureBenchmarks.java
I wrote a JMH benchmark to measure the difference between {{CompletableFuture.get()}},
{{CompletableFuture.get(timeout, unit)}}, and {{CountDownLatch.await()}}. The test appears
to show a significant difference between all 3 when the CPU is saturated, with
{{CompletableFuture.get()}} being the slowest.
{noformat}
Benchmark Mode Cnt Score
Error Units
CompletableFutureBenchmarks.completableFutureGetBusy thrpt 20 157501.654 ±
8227.728 ops/s
CompletableFutureBenchmarks.completableFutureGetSleeping thrpt 20 6337.177 ±
37.172 ops/s
CompletableFutureBenchmarks.completableFutureTimedGetBusy thrpt 20 178088.683 ±
7661.149 ops/s
CompletableFutureBenchmarks.completableFutureTimedGetSleeping thrpt 20 6331.961 ±
29.550 ops/s
CompletableFutureBenchmarks.countDownLatchAwaitBusy thrpt 20 194923.024 ±
7048.457 ops/s
CompletableFutureBenchmarks.countDownLatchAwaitSleeping thrpt 20 6326.857 ±
28.239 ops/s
{noformat}
However, the difference between the two {{CompletableFuture}} methods disappears
completely in some runs...
{noformat}
Benchmark Mode Cnt Score
Error Units
CompletableFutureBenchmarks.completableFutureGetBusy thrpt 20 173977.615 ±
7435.750 ops/s
CompletableFutureBenchmarks.completableFutureGetSleeping thrpt 20 6340.609 ±
21.529 ops/s
CompletableFutureBenchmarks.completableFutureTimedGetBusy thrpt 20 172650.973 ±
6382.962 ops/s
CompletableFutureBenchmarks.completableFutureTimedGetSleeping thrpt 20 6314.509 ±
30.036 ops/s
{noformat}
Implementation of RpcManagerImpl.invokeRemotely causes high CPU
usage
---------------------------------------------------------------------
Key: ISPN-5962
URL:
https://issues.jboss.org/browse/ISPN-5962
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 8.1.0.Beta1
Reporter: Sanne Grinovero
Assignee: Pedro Ruivo
Attachments: CompletableFutureBenchmarks.java
The method
{{org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(Collection<Address>,
ReplicableCommand, RpcOptions)}} is implemented by blocking on a {{CompletableFuture}},
but this then stalls on {{java.util.concurrent.CompletableFuture.waitingGet(boolean)}} by
spending a significant amount of CPU time by spinning.
When implementing RPC calls and having to wait for remote operations, spinning is
probably not a good idea. Could we try implementing this in some way to hint towards a
more pessimistic lock?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)