These are chat archives for atomix/atomix

19th
Jan 2018
Jordan Halterman
@kuujo
Jan 19 2018 02:04
@johnou the aggressiveness of the timeouts is somewhat intentional. False positives are expected. Timeouts are always handled gracefully inside Raft clients. Normally they’ll try to select another node and retry. They’re only really problematic if the number of retries are exhausted and an operation fails. Then it becomes a matter of tuning the thresholds.
There has to be some balance between timing out and retrying requests quickly and avoiding too many timeouts. When a request is lost for some reason, later requests can be blocked for consistent reasons until the lost request is discovered and retried. That’s the reason for the use of aggressive timeouts.
consistency*
Jordan Halterman
@kuujo
Jan 19 2018 02:10
Probably need to play with the numbers though
Johno Crawford
@johnou
Jan 19 2018 07:17
Makes sense, thanks for the explanation!
Johno Crawford
@johnou
Jan 19 2018 08:37
@ChristerF iirc there is a map change event listener
Johno Crawford
@johnou
Jan 19 2018 09:57
Could that be adapted to an entry processor?
Christer Fahlgren
@ChristerF
Jan 19 2018 18:47
@johnou - I don't think so, EntryProcessors are best described as "stored procedures" in Java that you send to the entry to be executed atomically, the side effect of any potential mutation of the entry is then replicated.
This is included in JSR107 (JCache)