I agree with every point about the delays inherent in a distributed system,
and how any "list" call should be treated by clients as point-in-time. And
I agree that the impact _should_ be minimal since diligent clients should
have error handling in these cases anyways.
But it still feels off to
Yeah, I'm sympathetic to that viewpoint. I was coming at this from
Walter's -- clients must be tolerant always. This mindset is
important when working on scalable distributed systems. But depending
on clients being so tolerant leads to being less friendly --
increasing the likelihood that they
If a program gets a list from a remote server, then expects that list to be
accurate when they make calls based on it, well, my kindest thought is
“charmingly naive”. Really, that is just bad code that hasn’t broken yet.
That is true even if it gets a list from Zookeeper. Things change while
Thanks for calling this out more explicitly; definitelyf worth discussing.
> If a client/caller/user lists collections and then loops them to take
some action on them, it needs to be tolerant of the collection not working;
may seem to not exist.
I'd go even a step further and say that users
https://issues.apache.org/jira/browse/SOLR-16909
> Collections LIST command should fetch ZK data, not cached state
I want to get further input from folks that changing the semantics is
okay. If the change is applied, LIST will be much faster but it will
return collections that have not yet been
