This is not the case during host replacement correct? On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan < jeremiah.jor...@gmail.com> wrote:
> 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 > >
