These are chat archives for atomix/atomix
@qorpus on the first example, does the
lock() call ever complete?
I'm actually rewriting the threading model right now. All Copycat/Atomix events are currently completed on the same thread, and if a thread is blocked then they're completed on a backup thread. This is what ZooKeeper does as well, and it's necessary to enforce order on clients, e.g. to ensure the user sees a lock event before an unlock event and vice versa. But I think there are some bugs with how it's implemented.
In ONOS, I rewrote the threading model to use a separate logical thread per-resource-partition because we were seeing timeouts from the threading model. Eventually, that threading model will make its way back into Atomix in a few months.
But that doesn't explain the last example. We were actually just recently working on the
DistributedLock and found there are some issues with it in certain environments. I wrote a lot more thorough tests for our lock wrapper, and a few of them failed consistently on our Jenkins server. I haven't been able to reproduce those issues in an environment that allows me to debug the issue, but I suspect there's something wrong with the lock implementation.
io.atomix.copycatand sending the logs? We abandoned the pessimistic lock in ONOS in favor of more improvements to transactions, but I suspect this is still a problem I'm going to have to solve. I just need the logs to do it.