We have a 4 slaves on Windows 2008 environment on tomacat and replication was working fine for some time and it started failing on one of the nodes i see following errors at first look it looks like permission issue but i compared two nodes and they seem to be same and nothing changed on this node.
SEVERE: SnapPull failed
org.apache.solr.common.SolrException: Unable to rename: D:\solr\core0\conf\compoundwords-de.txt to: D:\solr\core0\conf\compoundwords-de.txt.20120703165100
SEVERE: SnapPull failed
org.apache.solr.common.SolrException: Failed to create temporary config folder: conf.20120705004320
I even tried restarting the node to remove any pending locks but it did not resolve the issue anything i can do to troubleshoot the issue and find the real cause.
I was facing the same issue:
SEVERE: SnapPull failed
org.apache.solr.common.SolrException: Failed to create temporary config folder: conf.20120705004320
I happened to notice this error in tomcat's catalina.out after trying to figure out why the Solr admin UI is showing files being transferred during replication, but the index version and gen on the slave do not get updated after replication. In fact, in my case, the slave's version and gen were higher than what were on master (Solr 4.2.1)!
The trouble was the owner of the parent dir of solr conf dir (the one containing schema.xml, solrconfig.xml. etc.,). Solr wants to create a temporary conf dir named like conf.20120705004320 exactly at the same place where conf dir is located.
Once I changed the owner of the parent folder to tomcat6 replication started working fine. I used the command chown -R tomcat6:tomcat6 /var/solr where /var/solr is my ${solr.home}. The slave's version and gen started following the masters' after this fix.
I finally go this resolved after some troubleshooting we found that there was a failed java update since then the replication started failing. Here is what we did to resolve this
Reinstall JRE again
Tried restarting Solr, and removed all index files but it did not work
We went ahead deleted the core and setup the core again and it started working like before
Related
I just started to learn solr with official documentation and during the first exercise "Index Techproducts Example Data" I failed due to following error: " Failed to create collection 'techproducts' due to: Underlying core creation failed while creating collection: techproducts".
I tried to change java version from 13 to 8 but it didn't helped.
Here is link to the documentation: https://lucene.apache.org/solr/guide/8_5/solr-tutorial.html#exercise-1
Stacktrace from solr Admin console
Collection: techproducts operation: create failed:org.apache.solr.common.SolrException: Underlying core creation failed while creating collection: techproducts
at org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:304)
at org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:263)
at org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:504)
at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I had run into similar situation while following Solr
's official tutorial as following
➜ solr-8.7.0 ERROR: Failed to create collection 'techproducts' due to: Underlying core creation failed while creating collection: techproducts
And problem solved my turning off my vpn. I guess the vpn routing probably messed up with solr's localhost setting somehow.
I had the same Underlying core creation failed... error too. Using Java 11, Windows 10.
The log file was ${solr-home}\example\cloud\node1\logs\solr.log. Inside it had:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://192.168.1.16:7574/solr: Error CREATEing SolrCore 'techproducts_shard1_replica_n1': Unable to create core [techproducts_shard1_replica_n1] Caused by: no segments* file found in LockValidatingDirectoryWrapper(NRTCachingDirectory(MMapDirectory#{solr_home}\example\cloud\node2\solr\techproducts_shard1_replica_n1\data\index lockFactory=org.apache.lucene.store.NativeFSLockFactory#16326253; maxCacheMB=48.0 maxMergeSizeMB=4.0)): files: [write.lock] at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:681) ~[?:?]
at (etc. etc.)e
But this was the second time I launched solr. The first time it timed out trying to contact one of the nodes and the tutorial script aborted. But the nodes were still running. I killed them off using the windows task manager and not by using solr stop. So I suspect I left an instable mess behind and the second time the tutorial ran it crashed into this mess.
I erased everything and started over from unzipping and this third time there were no timeouts and the tutorial completed without error.
File: /opt/solr/server/etc/jetty.xml
(1) Name="requestHeaderSize" set Property name "solr.jetty.request.header.size" default="81920"
(2) Name="responseHeaderSize"> set Property name="solr.jetty.response.header.size" default="81920"
(3) Restart Solr
Hm, tried this, still getting the exact same error.
After Change:
[Set name="requestHeaderSize"][Property name="solr.jetty.request.header.size" default="81920" /][/Set]
[Set name="responseHeaderSize"][Property name="solr.jetty.response.header.size" default="81920" /][/Set]
I stopped everything and retried, then I had Windows Firewall prompt me for 'SAP Machine' authorization for java 11 message, I accepted it, and retried. Then it worked. Seems Windows Firewall related.
My first instance:
sudo bin/solr start -p 8983 -s ../coaps
My second instance:
sudo bin/solr start -p 8984 -s ../newcoaps
Using the python http utility I verified connections:
http :8983/solr/
http :8984/solr/
I can ping my first one with :8983/solr/samos/admin/ping/ but I can NOT ping the other one because the core located in ../newcoaps is not added upon startup.
The ../newcoaps directory looks like this before I started up Solr:
ls -R ../newcoaps/
../newcoaps/:
samos solr.xml
../newcoaps/samos:
conf data
../newcoaps/samos/conf:
schema.xml solrconfig.xml
../newcoaps/samos/data:
I copied the files in here directly from my other instance, which is running smoothly. Everything is default except for several fields I defined.
In the web browser, I see that the second instance has no cores, so I tried to add it manually but I get this response:
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused by: Can't find resource 'synonyms.txt' in classpath or '/opt/solr/newcoaps/samos'
What is going on here and why is that file important enough to prevent me from adding this core? What steps can I take to figuring out a solution to this problem?
Your schema (schema.xml) is referencing the synonyms.txt file (in a SynonymFilter definition). Remove the filter from the configuration if you're not expanding synonyms, or create an empty file named synonyms.txt to allow the core to start up.
As a possible explanation: If you started the first node without a schema.xml present the first time, it might have switched to using the managed schema functionality instead of reading the schema.xml, but when starting the second node with the schema present, it'll try to read and parse it.
Thanks in advanced,
am tried to setup two solr servers in tomcat7 (ubuntu). Below here is the steps i followed,
create to context file inside tomcat7 localhost directory
/tomcat7/Catalina/localhost/solr.xml
/tomcat7/Catalina/localhost/solr-cc.xml
create two seperate solr instances
/etc/solr-4.6.a/solr.war & index directories
/etc/solr-4.6.b/solr.war & index directories
Server started fine and am able to see both solr admin pages, but when i tried to index data, am using dataimport handler (put separate configuration entries in two servers), first instance /solr is running fine, but the second one /solr-cc throws below exception:
Full Import failed:
org.apache.solr.handler.dataimport.DataImportHandlerException: Properties is not writable. Delta imports are supported by data config but will not work. Processing Document # 1
at org.apache.solr.handler.dataimport.DataImporter.checkWritablePersistFile(DataImporter.java:426)
at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:410)
at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:476)
at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:457)
I tried more then an hour to fix but failed, I gave all the file permission as 777 to index and solr config files directories.
Any help would be appreciated!!
Please make sure your dataimport.properties file is writable by tomcat user(I assume tomcat7), you could change the owner on all the files from conf folder to tomcat.
Let me know if it worked.
I am deploying Solr 4.3.0 in Tomcat 7.
Everything works fine but DataImportHandler. I can go to the
http://localhost:8080/solr/#/collection1/dataimport//dataimport
screen and see the dataimport options load at the UI.
Still, I can see any of my entities load in the "entity" combo box. Inside the configuration box, at the right side I can see the error below.
Apache Tomcat/7.0.41 - Error
report
525D76;}--> HTTP Status 500 - Filter execution threw an exception
noshade="noshade">type Exception reportmessage
Filter execution threw an exceptiondescription
The server encountered an internal error that prevented it from
fulfilling this request.exception
javax.servlet.ServletException: Filter execution threw an
exception root cause
java.lang.NoClassDefFoundError: org/apache/log4j/spi/LoggingEvent
org.apache.solr.logging.log4j.EventAppender.append(EventAppender.java:35)
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
org.apache.log4j.Category.callAppenders(Category.java:206)
org.apache.log4j.Category.forcedLog(Category.java:391)
org.apache.log4j.Category.log(Category.java:856)
org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:498)
org.apache.solr.common.SolrException.log(SolrException.java:119)
org.apache.solr.servlet.ResponseUtils.getErrorInfo(ResponseUtils.java:58)
org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:691)
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
note The full stack trace of the root cause is
available in the Apache Tomcat/7.0.41 logs.Apache Tomcat/7.0.41
Problem is that I have the "log4j-1.2.16.jar" loaded in the classpath (it's on Tomcat lib dir).
Anyone have stepped in this problem?
Try following the steps outlined in Using the example logging setup in containers other than Jetty. I have encountered this same error when running Solr 4.3 until I followed these steps to configure logging.
After changing the directory, did you change the directory path in solrconfig.xml file.
I just want to make sure after the making changes in configuration file, did you restart the tomcat and solr server?
You need to copy the slf4j-log4j12-1.6.6.jar from the ext of Solr into the lib folder.
You also need to put the logging.properties file there.
We are using solr4.3 with master/slave setup, today I got the following error and solr stopped responding. What could be causing this,
Caused by: org.apache.solr.common.SolrException: Index locked for write for core XXX
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:821)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:618)
at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:949)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:984)
at org.apache.solr.core.CoreContainer$2.call(CoreContainer.java:597)
at org.apache.solr.core.CoreContainer$2.call(CoreContainer.java:592)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
... 1 more
Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked for write for core XX at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:484)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:745)
... 13 more
Delete file write.lock in folder /data/index/ for your core then restart tomcat. It will work.
It seems the index has been locked during indexing.
Usually there would be a write.lock file within the index which needs to be removed to get it back.
The conditions can occur if the indexing breaks in between or other issues which may cause to lock file to be still in the index.
Check Forum
The write lock is due to the fact that an IndexWriter is always open
in Solr even on the slaves.
Check for the Index Lock options which can handle the condition within configuration.
[An archived copy of the original link:
https://web.archive.org/web/http://docs.lucidworks.com/display/solr/IndexConfig+in+SolrConfig ]
If you are using Rails,
just add into solr.xml this line
<lockType>simple</lockType>
its works for me)
In some times this occurs because current user dont have permission in directory.
Try using root and using -force for start solr.
In my case this error occured when i try to create a new core in the path containing the index of an existing core e.g
/data/index/
This happened because i had changed the solrconfig.xml index data directory to move the default path to another location i called:
<dataDir>/data/index/</dataDir>
So reusing the solrconfig.xml to create a new core causes the error. Changing this to:
<dataDir>${solr.data.dir}/${solr.core.name}</dataDir>
Causes the index of a new core to be created in a path related to its core name and so write.lock permission issues with the index of an exisitng core are not encountered during the creation of the new core
Try to use : container.shutdown() after the indexing, it works if you want to update/search again without removing the file "write.lock".
check if the permissions are for root and change the permissions of the core files
Most likely this is due to files having the wrong ownership. Check permissions and ownerships.
If you still encounter error having done the above tasks, you may want to see the below;
Delete file write.lock in folder /data/index/ for your core then restart Tomcat Server.
Restart Tomcat Server in Linux:
<Tomcat Root>/bin>./catalina.sh stop
<Tomcat Root>/bin>./catalina.sh start