Yes, lowering the member timeout is one approach I’ve seen taken for applications that demand ultra low latency. These workloads need to provide not just low “average” or even p99 latency, but put a hard limit on the max value.
When you do this you need to ensure coherency across at all aspects of timeouts (eg client read timeouts and retries). You need to ensure that GC pauses don’t cause instability in the cluster. For example, if a GC pause is greater than the member timeout, you should go back and re-tune your heap settings to drive down GC. If you are running in a container of VM you need to ensure sufficient resources so that the GemFIre process is never paused. All this presupposes a stable and performant network infrastructure. Anthony On Nov 21, 2020, at 1:40 PM, Mario Salazar de Torres <mario.salazar.de.tor...@est.tech<mailto:mario.salazar.de.tor...@est.tech>> wrote: So, what I've tried here is to set a really low member-timeout, which results the server holding the secondary copy becoming the primary owner in around <600ms. That's quite a huge improvement, but I wanted to ask you if setting this member-timeout too low might carry unforeseen consequences.
