I'm indexing the content I have and after upgrade my Solr instance to solr 4 I'm facing some OutOfMemories. The exception thrown is:
INFO org.apache.solr.update.UpdateHandler - start commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
ERROR o.a.solr.servlet.SolrDispatchFilter - null:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
at org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:469)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:297)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:250)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:166)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.OutOfMemoryError: Java heap space
Is there some known bug or something I could test to get rid of it?
Within this upgrade two things changed:
solr version (from 3.4 to 4.0);
lucene match version (from LUCENE_34 to LUCENE_40).
Seems to be running out of memory when accessing logs, at a glance. That may not be particularly meaningful, with an 'Out of Memory' error, of course, but worth a shot, particularly after seeing this complaint regarding SOLR 4.0 logging. Particularly so if this is occuring during an index rebuild of some form, or heavy load of updates.
So try disabling the update log, which I believe can be done by commenting out:
<updateLog>
<str name="dir">${solr.data.dir:}</str>
</updateLog>
in solrconfig.xml.
EDIT:
Another (possibly better) approach to this, taking another glance at it, might be to commit more often. The growth of the update log seems to be directly related to having a lot of queued updates waiting for commit.
If you do not have autocommit enabled, you might want to try adding it in your config, something like:
<autoCommit>
<maxTime>15000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
There's a good bit of related discussion and recommendation to be found on this thread.
I ran into the same problem today and after reading #femtoRgon's suggested thread, I changed the following in the solrconfig.xml
<autoCommit>
<maxTime>15000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
to
<autoCommit>
<maxDocs>15000</maxDocs>
<openSearcher>false</openSearcher>
</autoCommit>
It no longer gives me that error. So it commits every 15,000 docs. Which in my case is frequent enough not to run into memory issues. In my MacBook Pro it took few minutes to index ~4m documents containing product information (so short documents).
Related
I'm responsible for upgrading our Lucene indexes from 4.5.1 to 8.x. Thanks to the unofficial Lucene Upgrader I was able to do this, so now I'm testing this index in Solr 8.11.2.
When I launch the standard *:* search through the Admin interface, the return message told me about a NullPointerException:
java.lang.NullPointerException
at org.apache.solr.legacy.LegacyNumericUtils.prefixCodedToLong(LegacyNumericUtils.java:191)
at org.apache.solr.schema.TrieField.toObject(TrieField.java:154)
at org.apache.solr.schema.TrieDateField.toObject(TrieDateField.java:94)
at org.apache.solr.schema.TrieDateField.toObject(TrieDateField.java:86)
at org.apache.solr.schema.TrieField.write(TrieField.java:280)
at org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:125)
At first, I had no idea how to debug this, and googling it didn't return anything relevant. Then I got the idea of commenting the date fields in schema.xml. This still got me a NPE, but now it comes from a regular TrieField:
java.lang.NullPointerException
at org.apache.solr.legacy.LegacyNumericUtils.prefixCodedToLong(LegacyNumericUtils.java:191)
at org.apache.solr.schema.TrieField.toObject(TrieField.java:150)
at org.apache.solr.schema.TrieField.write(TrieField.java:280)
at org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:125)
Surely there's a better way to debug this than to comment every field? Or is there something I'm missing?
P.S.: Reindexing is not an option. We have several customers where indexing literally takes weeks, if not months.
How does a Solr CDCR target cluster handle commits? The commit settings are the same as on the CDCR source, where the Solr admin UI shows freshly indexed documents with hardly any delay. Both settings are
<autoCommit>
<maxTime>${solr.autoCommit.maxTime:15000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
with the ${solr*maxTime} unset as far as I can tell. (I am a bit surprised anyway, given the settings, that I see results shortly after indexing on the source cluster:-(
Yet on the target cluster, I seem to never get a commit, certainly not within 15 seconds as the default suggests. I know the data is available, since it appears right after a manual commit.
Any idea how to configure the target to actually perform any commits?
I was facing same issue. Adding softcommit to 15s helped me:
curl -X POST -H 'Content-type: application/json' -d '{"set-property":{"updateHandler.autoSoftCommit.maxTime":1500}}' http://localhost:8983/solr/<yourcollection>/config
I found in some forum hint to restart server, did not help me.
I am using SOLR with sitecore, on production environment, I am getting a lot of errors in SOLR log, but sites are working fine, I have 32 solr cores, and I am using Solr version 4.10.3.0 with Sitecore 8.1 update 2, below is sample of these errors, any one can explain to me these errors :
Most of the errors are self-descriptive, like this one:
undefined field: "Reckless"
tells that the field in question is not defined in the solr schema. Try to analyze the queries you system is accepting and the system sending these in.
The less obvious one:
Overlapping onDeckSearchers=2
is warning about warming searchers, in this case 2 of them concurrently. This means, that there were commits to the Solr index in a quick succession, each of which triggered a warming searcher. The reason it is wasteful is that even though the first searcher has warmed up and is ready to serve queries, it will be thrown away as the new searcher warms up and is ready to serve.
I'm was trying to run multiple queries in a single go then I came across something called MultiRequestHandler. I had put request handler in the solrconfig.xml file and restarted the solr.
<requestHandler name="/multi" class="solr.MultiRequestHandler"/>
I'm getting the error
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
Error loading class 'solr.MultiRequestHandler'
My version of Solr is 5.4.0. Does my version of Solr doesnot support MultiRequestHandler?
There never was a MultiRequestHandler added to Solr. The ticket tracking its addition were resolved as Won't fix.
The patch is available on Github, but hasn't been updated in three years - so it might not apply cleanly to 5.4.x.
Newer versions of Solr do however have Streaming Expressions, which could be what you're looking for.
Having issues in Soft Auto commit (Near Real Time). Am using solr 4.3 on tomcat . The index size is 10.95 GB. With this configuration it takes more than 60 seconds to return the indexed document. When adding documents to solr and searching after soft commit time, its returning 0 hits. Its taking long before the document actually starts showing up, even more than the autoCommit interval.
<autoCommit>
<maxTime>15000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>1000</maxTime>
</autoSoftCommit>
Machine is ubuntu 13 / 4 cores / 16GB RAM. Given 6gb to Solr running over tomcat.
Can somebody help me with this?
If you are adding new document using solr client, try using commitWithin, its more flexible over autoSoftCommit.One more thing make sure the u have update log is enabled in solrconfig.xml and get handler as well.You can get more details here-http://wiki.apache.org/solr/NearRealtimeSearch