onyx

FYI: alternative Onyx :onyx: chat is at <https://gitter.im/onyx-platform/onyx> ; log can be found at <https://clojurians-log.clojureverse.org/onyx/index.html>
2018-09-22T14:51:38.000100Z

thanks @lmergen , that helped a lot! one other question, it appears the the onyx GC fn is being called on every replica in the cluster. is that the correct approach? From the docs, it sounds like you want to call the fn on one replica and it would trigger GC on all the peers. I also see some errors in our logs originating from the GC fn in the stack trace related to ZooKeeper

2018-09-22T14:53:01.000200Z

i believe the GC is mostly about cleaning up the distributed log -- since all peers should have the same "view" of the log, it makes sense that it's executed on all peers

2018-09-22T14:54:08.000100Z

what - i think - actually happens is that a simple entry is written in the log, "perform gc" -- all peers read this, and since GC is completely deterministic, at the end of the operations they all still have one consistent view of the (now GC'ed) log

2018-09-22T14:54:31.000100Z

this is a bit of a consequence of the masterless design

2018-09-22T14:56:27.000100Z

I think I get it, it would get executed on all peers by onyx itself, but should only be triggered once in the cluster, is that right? I think we may be writing the special “perform gc” to the log several times, if that makes sense

2018-09-22T15:05:32.000100Z

@lmergen appreciate the help. we are scaling up and this system that has been somewhat reliable for about a year is starting to have issues as we scale.

2018-09-22T15:05:45.000100Z

yes that's correct

2018-09-22T15:06:33.000100Z

i don't think it's too much of a problem to write too much GC, apart from wasted CPU cycles

2018-09-22T15:15:15.000100Z

ok. thanks. Either way, we have an easy way to get that to run on one replica, so might as well get eliminate that as a cause.