Francesco Nigro
Francesco Nigro
**Expected behavior** Restarting `Atomix` configured to use N raft nodes, bit still not connected to any nodes, should not leak any `Atomix` instance. **Actual behavior** `DefaultRaftServer::shutdown()` is not closing it's...
**Expected behavior** BlockingAtomicLock should notifies for state changes. **Actual behavior** BlockingAtomicLock isn't implementing DistributedPrimitive::addStateChangeListener and removeStateChangeListener, hence won't be able to add/remove (and, by consequence, notify) listeners. **Environment** - Atomix:...
In this scenario: - 2 nodes started (a and b) - a became leader - b stop - a stop - 2 nodes re-started (a and b) - a is...
A failed attempt to became leader leave a node in a state that makes it automatically eligible for the leadership: only withdrawing, in case of a failed attempt, turns it...
I have recently fallen into https://www.semanticscholar.org/paper/Brief-Announcement%3A-Jiffy%3A-A-Fast%2C-Memory-Wait-Free-Adas-Friedman/cd837a3f38878541c31acee3409c4481f98481d6 and I see that the algorithm they have used is the same of JCTools XADD queues (mpsc in particular). The main difference seems that...
It would be nice to expose some "silent" version of offers that won't try to awake the consumer (it can both fail fast or just offer the element if not...
https://github.com/JCTools/JCTools/wiki/Getting-Started-With-JCTools (that's great ;)) isn't mentioning the blocking consumer q and its killer applications.
I see that there are no direct fields that are going to be modified between the 2 layers of padding of the counters....it's necessary? Just loading the load[] field probably...
Due to https://github.com/netty/netty/pull/10530 I have used a copy on write approach with the existing IdentityHashMap: I believe a smarter approach would use the rehashing/compacting phases of a such maps on...