Hello,
We were investigating one HEAP DUMP in which FielsCaceImpl has occupied around
5GB. Upon further investigation, I got to know that
FieldCacheImpl$SortedDocValues occupies 90% of the memory where
FieldCacheImpl$CacheKey is "id".
When I checked the logs I was trying to find any query in
Hello,
I am seeing a performance issue in querying in one of the SOLR servers -
instance version 5.4.1.
Total number of documents indexed are 20K plus.
Data returned for this particular query is just as less as 22 documents
however it takes almost 2 minutes to get the results back.
Is there a
Thanks for looking into this @Erick Erickson.
What'd be the proper way to get David Smiley's attention on this issue? A
JIRA ticket?
As for the performance difference, we haven't had a chance to test it.
We're still in the dev phase for migrating to solr 8, so we'll run our
benchmarks afterward,
Possibly https://issues.apache.org/jira/browse/LUCENE-9286? I’m not quite sure
whether this only affects 8.5 or not.
Also: https://issues.apache.org/jira/browse/LUCENE-8920 and
https://issues.apache.org/jira/browse/LUCENE-9398 might be of interest.
I have no idea whether these are relevant or
Hi all,
sorry for not being clear in the first instance.
What I'm trying to say is, what happens when a core loads a library,
are the classes present in the library even available for other cores? I
think no.
But if there is some sort of encapsulation this should be clear in the
documentation.
In
Hi all,
I know that Solr allows loading classes by defining the directive
into the solrconfig.xml.
What it's not clear is if there is a separate (private?) classloader for
each core.
Is this correct?
Best regards,
Vincenzo
--
Vincenzo D'Amore
Hello everyone, I use the version of Solr-7.7.3.
The following error occurred during the index write phase, but after restarting
the Solr service, the file was deleted, and access to the index has also been
restored.
Has anyone ever encountered this mistake?
Caused by:
