As long as we are correctly storing such things in the system tables and reading them out of the system tables when we do not have the information from gossip yet, it should not be a problem. (As far as I know GPFS does this, but I have not done extensive code diving or testing to make sure all edge cases are covered there)
-Jeremiah > On Oct 16, 2018, at 11:56 AM, sankalp kohli <kohlisank...@gmail.com> wrote: > > Will GossipingPropertyFileSnitch not be vulnerable to Gossip bugs where we > lose hostId or some other fields when we restart C* for large > clusters(~1000 instances)? > > On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa <jji...@gmail.com> wrote: > >> We should, but the 4.0 features that log/reject verbs to invalid replicas >> solves a lot of the concerns here >> >> -- >> Jeff Jirsa >> >> >>> On Oct 16, 2018, at 4:10 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> >> wrote: >>> >>> We have had PropertyFileSnitch for a long time even though >> GossipingPropertyFileSnitch is effectively a superset of what it offers and >> is much less error prone. There are some unexpected behaviors when things >> aren’t configured correctly with PFS. For example, if you replace nodes in >> one DC and add those nodes to that DCs property files and not the other DCs >> property files - the resulting problems aren’t very straightforward to >> troubleshoot. >>> >>> We could try to improve the resilience and fail fast error checking and >> error reporting of PFS, but honestly, why wouldn’t we deprecate and remove >> PropertyFileSnitch? Are there reasons why GPFS wouldn’t be sufficient to >> replace it? >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
