We are using a ReplicatedMap in a Hazelcast client. Client and server are both version 4.2.1.
The map is quite small (<10 entries, each value less than 100 bytes). The client only reads from the map, which is updated infrequently on the server.
We expected ReplicatedMap.get to be non-blocking, but during a long running performance test, we started getting warnings like the one below from vertx (which monitors for blocked threads). The first error came after 6 hours, so it is not easily reproduced.
Is there any way to do a non-blocking get? Or do we need to add an EntryListener, which maintains a ConcurrentHashmap?
Clarification: The real issue here is not blocking vertx (which can be solved by moving the call to a Vertx worker verticle), but rather avoiding delaying the lookup. The business requirement is that we process messages in 50 ms or less, so even if we moved the call to a worker, we would be unable to fulfill that.
[vertx-blocked-thread-checker] WARN io.vertx.core.impl.BlockedThreadChecker - Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 12777 ms, time limit is 2000 ms
io.vertx.core.VertxException: Thread blocked
at jdk.internal.misc.Unsafe.park(Native Method) ~[?:?]
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:323) ~[?:?]
at com.hazelcast.spi.impl.AbstractInvocationFuture.manageParking(AbstractInvocationFuture.java:693) ~[hazelcast-4.2.1.jar!/:4.2.1]
at com.hazelcast.spi.impl.AbstractInvocationFuture.get(AbstractInvocationFuture.java:615) ~[hazelcast-4.2.1.jar!/:4.2.1]
at com.hazelcast.client.impl.spi.ClientProxy.invokeOnPartition(ClientProxy.java:188) ~[hazelcast-4.2.1.jar!/:4.2.1]
at com.hazelcast.client.impl.spi.ClientProxy.invoke(ClientProxy.java:182) ~[hazelcast-4.2.1.jar!/:4.2.1]
at com.hazelcast.client.impl.proxy.ClientReplicatedMapProxy.get(ClientReplicatedMapProxy.java:214) ~[hazelcast-4.2.1.jar!/:4.2.1]
at my.package.StateGetter.getState(StateGetter.java:44) ~[classes!/:1.5.189]
ReplicatedMap entries are replicated on all members of the cluster. A client still needs to perform a remote call to a member to fetch the entry. For your requirements, I think the best way to achieve predictable latency is to setup a near cache on your client. This way entries will be cached locally on the client and only updated whenever necessary.