I don’t recall, but it makes sense.  That would be a pretty janky database.

It’s a race around the client seeing the collection and seeing it in full.
It wouldn’t be as bad if the full collection state was just written out
rather than the super legacy related, build it up piece by piece, but even
if that wasn’t the case, it would still be an issue, just less of one. You
could just hide the wait code in the client call, but you almost certainly
have to involve the client. The server can’t know when the client is sure
to see/have the latest full state for the operation, and the clients next
operation is likely to depend on that.

- MRM


On Tue, Feb 6, 2024 at 8:22 PM Gus Heck <gus.h...@gmail.com> wrote:

> Ah, unless someone fixed it since the last time Mark Miller ranted about
> it, it's rooted in the fact that the call to create a collection returns to
> the user before the collection is ready to use. IIRC the rant said
> something like "what database would return from CREATE TABLE before the
> table was created? None! But we do just that with create Collection"... or
> something like that.
>
>
> On Tue, Feb 6, 2024 at 4:56 PM David Smiley <dsmi...@apache.org> wrote:
>
> > Hey... about about that click-bait title; ehh? :-D
> >
> > I've noticed that basically any SolrCloudTestCase will create a
> > collection and then call waitForState.  I think this is dumb; do we
> > ask our clients to do the same?  Then why should our tests do this?  I
> > can understand some tests may have specialized requirements -- fine.
> > But I think mostly we copy-paste this practice and not consider why
> > we're even doing this in the first place.  This has been a code smell
> > to me.  The only reason I can think of, and that which I actually
> > found in production today on a massive cluster, is that the
> > CloudSolrClient's state is out-of-date and CSC fails to consider that
> > it doesn't actually know the most up-to-date state, and fails a
> > request to send to the collection that it just created.
> > https://issues.apache.org/jira/browse/SOLR-17153
> > Feedback welcome.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >
>
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>

Reply via email to