On 24/01/2023 08.01, David Smiley wrote:
BTW, I don't think Solr/SolrCloud *internally* does something that would
trigger the ID field to be in the fieldCache and thus benefit from
docValues. If I'm wrong, I'd like to know. It would take sorting on the
field or using one of a variety of feature
On 03/01/2023 03.54, Shawn Heisey wrote:
Some features like grouping appear to require docValues to work at all.
If some shards have docValues and some don't, those features are likely
to break horribly, or at least not return expected results.
You're probably right in saying that this will br
ore on the approach? How does Solr Cloud maintain
different schema when update mixture of old and new documents in the same
segment?
Thanks, and happy new year!
- Wei
On Fri, Dec 23, 2022 at 8:21 AM Bram Van Dam wrote:
Greetings,
We ran into a pretty hairy problem on 7.7. TL;DR; we had to enable
Greetings,
We ran into a pretty hairy problem on 7.7. TL;DR; we had to enable
docValues on the unique key field in a large SolrCloud instance, without
being able to reindex old data.
This kind of worked, by specifying different config sets in
core.properties for different shards, where new s
yList size to, say, Math.min(1024,n)
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jun 9, 2022 at 11:34 AM Bram Van Dam wrote:
Howdy,
We've noticed that enabling larger transaction logs causes the memory
requirements for Solr to increa
Howdy,
We've noticed that enabling larger transaction logs causes the memory
requirements for Solr to increase: Solr consumes large amounts of memory
at startup.
After procuring a heap dump, this seems to be because Solr initializes
ArrayLists in UpdateLog::getVersions with size
maxNbTransa
On 10/12/2021 11.10, Uwe Schindler wrote:
In general the sysprop "log4j2.formatMsgNoLookups=true" fix is the only correct
fix (maybe add it to the bootstrap class of solr). Updating log4j is not really needed.
This prevents any of those shit. There's no reason ever to parse ${} escapes in log
Heads up:
Seems like there's a pretty severe remote code execution vulnerability
[1] in Log4J. Basically any application that uses log4j and that allows
user input to be injected into a logging string is susceptible. This
probably includes Solr.
Further interesting discussion on Hacker News
