I go into a bunch of this silliness in the presentation I put together on
the Overseer. I’ll look into sharing it.
ZkStateReader is obviously not in the Overseer class, but it’s all one
communication system; it’s de facto Overseer code and only slightly better
than the Overseer class.
A state upd
>
> how to set COMMIT_ACTIVE_KEY and COMMIT_KEY_ID or PARAM_KEY_ID in
> SolrQueryRequest req dynamically ?
> If Keys are set to req object before calling
> EncryptionRequestHandler.handleRequestBody(SolrQueryRequest req,
> SolrQueryResponse rsp), this module will work.
Indeed the EncryptionReques
Thanks for your reply too, Jan. You mention important points.
> If frontend devs are to maintain it and we want to attract frontend
professionals, then stick to industry standard React or similar.
This is something that troubled me a lot. Following the industry-standards
would probably be the saf
Hi everyone,
The Change log for Solr 9.7 looks pretty good already with the Lucene
upgrade and a bunch of other fixes, improvements, and features.
I'd like to start the release process next *Tuesday, July 23 *unless there
are objections or reasons to wait.
-Anshum
Would per-replica state (PRS) help with that? That slices by replica, not
collection, but it should allow finer-grained locking.
https://searchscale.com/blog/prs/
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Jul 16, 2024, at 9:03 AM, David Smiley
Would per-replica state (PRS) help with that? That slices by replica, not
collection, but it should allow finer-grained locking.
https://searchscale.com/blog/prs/
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Jul 16, 2024, at 9:03 AM, David Smiley
At work, in a scenario when a node starts with thousands of cores for
thousands of collections, we've seen that core registration can
bottleneck on ZkStateReader.forceUpdateCollection(collection) which
synchronizes on getUpdateLock, a global lock (not per-collection). I
don't know the history or s
I did run nightlies as well. There were some failures but the console
never printed my "nocommit". This is just a quick experiment I'm
doing to help me understand some things.
I'm inclined to add comments to say that calling getRealtimeSearcher
will "nearly always" return an existing one without
I'm not currently looking at any code, but if the idea is that you put in
that assert and ran the nightly or none nightly tests, I wouldn't come to
the conclusion that that code path is never hit unless you've walked
through all of the possible concurrency potential around it in the code.
- MRM
SolrCore.getRealtimeSearcher returns the existing searcher if there is
one, or otherwise creates one. I did a little experiment to "assert
false" where it creates one. It never tripped! On any commit, that
searcher is installed as the realtime searcher, and furthermore a
searcher is created on c
10 matches
Mail list logo
