With Solr 4.x, http://localhost:8983/solr/admin/cores returns an XML description of loaded cores, which indicates the file path location of the instanceDir.
...
<lst name="collection1">
<str name="name">collection1</str>
<bool name="isDefaultCore">true</bool>
<str name="instanceDir">C:\solr\solr-4.10.1\example\solr\collection1\</str>
...
On my Windows 7 PC, this is presented as a full path, but others have reported this as relative path. What factors can cause this value to be presented as a relative path, and is there a way to force this to be presented as a full path?
Can you please confirm if you have set solr.home. Please check this Solr Wiki for more details. I hope setting solr.home should resolve the issue.
You can add it as JVM argument
java -Dsolr.solr.home=/your/solr/home/path/here -jar start.jar
Incase of Tomcat, you can also do as below
export JAVA_OPTS="$JAVA_OPTS -Dsolr.solr.home=/your/solr/home/path/here"
Thanks
Related
I've installed zookeeper 3.7.1 and Solr 9.1 on three EC2s running Ubuntu 22.04.1 LTS in a solcrloud deployment. The zoo.cfg is as follows:
tickTime=2500
dataDir=/zookeeper
clientPort=2181
maxClientCnxns=80
initLimit=10
syncLimit=5
server.1=10.9.9.x:2888:3888
server.2=10.9.10.y:2888:3888
server.3=10.9.13.z:2888:3888
4lw.commands.whitelist=*
The Solr deployment is almost straight out of the box. The solr.xml is unmodified. Here is the section:
<solrcloud>
<str name="host">${host:}</str>
<int name="hostPort">${solr.port.advertise:0}</int>
<str name="hostContext">${hostContext:solr}</str>
<bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>
<int name="zkClientTimeout">${zkClientTimeout:30000}</int>
<int name="distribUpdateSoTimeout">${distribUpdateSoTimeout:600000}</int>
<int name="distribUpdateConnTimeout">${distribUpdateConnTimeout:60000}</int>
<str name="zkCredentialsProvider">${zkCredentialsProvider:org.apache.solr.common.cloud.DefaultZkCredentialsProvider}</str>
<str name="zkACLProvider">${zkACLProvider:org.apache.solr.common.cloud.DefaultZkACLProvider}</str>
<str name="zkCredentialsInjector">${zkCredentialsInjector:org.apache.solr.common.cloud.DefaultZkCredentialsInjector}</str>
<bool name="distributedClusterStateUpdates">${distributedClusterStateUpdates:false}</bool>
<bool name="distributedCollectionConfigSetExecution">${distributedCollectionConfigSetExecution:false}</bool>
</solrcloud>
The config in /etc/default/solr.in.sh is as follows:
SOLR_JETTY_HOST="0.0.0.0"
ZK_HOST="10.9.9.x:2181,10.9.13.y:2181,10.9.10.z:2181"
SOLR_JAVA_MEM="-Xms2G -Xmx4G"
SOLR_PID_DIR="/srv/apps_data/solrcloud"
SOLR_HOME="/srv/apps_data/solrcloud/data"
LOG4J_PROPS="/srv/apps_data/solrcloud/log4j2.xml"
SOLR_LOGS_DIR="/srv/apps_data/solrcloud/logs"
SOLR_PORT="8983"
# The following lines added by ./solr for enabling BasicAuth
SOLR_AUTH_TYPE="basic"
SOLR_AUTHENTICATION_OPTS="-Dsolr.httpclient.config=/srv/apps_data/solrcloud/data/basicAuth.conf"
I enabled basic authentication and everything looks good in all three Admin UIs. Zookeeper status is good and the three servers are now deployed in solrcloud mode. The security section is as follows:
So far so good.
I next create a config using an authenticated request using the basic authentication credentials, http://solr:solr#10.9.9.x:8983/solr/admin/configs?action=UPLOAD&name=calls with a zip file containing the two files
managed-schema.xml
solrconfig.xml
When I look at it under the zookeeper tree, /configs/calls, I see a little annotation {"trusted":true}. This all seems good so far.
The problem comes when trying to create a collection. I use the collections API V1, with 3 shards and 2 replicas, using the async approach
http://solr:solr#10.9.9.x:8983/solr/admin/collections?action=CREATE&name=calls&numShards=3&replicationFactor=2&collection.configName=calls&async=123456
"1234562330250161386315": {
"responseHeader": {
"status": 0,
"QTime": 0
},
"STATUS": "failed",
"msg": "Error CREATEing SolrCore 'calls_shard1_replica_n1': Unable to create core [calls_shard1_replica_n1] Caused by: solr.XSLTResponseWriter"
},
What am I missing here? My research indicates that the issue with the XSLTResponseWriter arises because of a lack of trust or authentication. What is the correct way to configure Solr 9.1 to allow collections to be created?
Any help will be greatly appreciated!!
I figured out the issue. In the release notes for 9.0, it makes the sort of passing comment
To improve security, XSLTResponseWriter has been moved to the
scripting Module instead of shipping as part of Solr core. This
module needs to be enabled explicitly.
In other words, solr won't work in cloud mode AT ALL until the out-of-the-box configuration is corrected. The required change needs to be made in /etc/default/solr.in.sh for my deployment on ubuntu, and requires enabling the scripting module.
The following lines appear in the freshly-installed solr.in.sh file (in /etc/default),
# The bundled plugins in the "modules" folder can easily be enabled as a comma-separated list in SOLR_MODULES variable
# SOLR_MODULES=extraction,ltr
In order to be able to use solrcloud and create collections, etc., the following line needs to be included:
SOLR_MODULES="extraction,ltr,scripting"
With this change, solrcloud works as expected!
On Solr 4.2.1, I was able to use the solr post and now I have upgraded to 5.4 and when I used the post method. I am getting Error loading class 'solr.XsltUpdateRequestHandler' error.
Here is the complete error:
null:org.apache.solr.common.SolrException: Error loading class 'solr.XsltUpdateRequestHandler'
at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:559)
at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:490)
Caused by: java.lang.ClassNotFoundException: solr.XsltUpdateRequestHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
I have used the following on the solrconfig and no errors during the solr start.
<requestHandler name="/update/xslt" class="solr.XsltUpdateRequestHandler" startup="lazy" />
Any help is much appreciated.
Thank you
Looks like that handler was deprecated back in 4.8 or possibly even sooner than that. I wouldn't be surprised if it was removed from Solr completely by 5.0, but I don't see anything in the docs about it. I pulled up the 4.2.1 docs and even those have the deprecated annotation.
You might want to try to downgrade all the way back to 4.10 at the latest to see if you can use that handler, then start upgrading versions one at a time until the error happens again. Jumping from 4.2.1 to 5.4.1 is huge. There have been quite a few changes between these versions.
If you don't want to bother, I did a quick search in my 5.4.1 solrconfig.xml and found the following:
<!-- XSLT response writer transforms the XML output by any xslt file found
in Solr's conf/xslt directory. Changes to xslt files are checked for
every xsltCacheLifetimeSeconds.
-->
<queryResponseWriter name="xslt" class="solr.XSLTResponseWriter">
<int name="xsltCacheLifetimeSeconds">5</int>
</queryResponseWriter>
I don't know how to use this as I've never had a reason to bother with xslt, but it looks like a good place to start.
Thanks #TMBT for your response. I was able to find the solution by using it UpdateRequestHandler as XsltUpdateRequestHandler is deprecated. After changing it to solr.UpdateRequestHandler, I was able to run the solr POST and it was successful.
<requestHandler name="/update/xslt" class="solr.UpdateRequestHandler" startup="lazy" />
I was following this article to start with my apache solr expedition.
http://examples.javacodegeeks.com/enterprise-java/apache-solr/apache-solr-tutorial-beginners/
I have created a solr core using below command-
> solr create -c mycorename
This has created a core but schema.xml file is not created inside the conf directory. Instead of this i am able to see managed-schema.xml file. Does this command create a schemaless core. Please let me know how i can create a core that also have a schema.xml file created in it.
Yes, i've got some issue.
Shortly. Solr can use ether static schema, or dynamic (REST api) schema. So, you should select which one you'll use.
You can do id in solrconfig.xml
Like this:
<schemaFactory class="ManagedIndexSchemaFactory">
<bool name="mutable">true</bool>
<str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>
More info, read this guide
I'm Trying to setup a multi core solr server for our webapplication but i'm having trouble creating new core through the coreadmin service.
I'm using Solr-4.4 because 4.3 ran into problems persisting the cores in solr.xml (datadir wasn't preserved) So i'm using the new Solr.xml configuration 4.4 and beyond
My solr.xml currently looks like:
<solr>
<str name="coreRootDirectory">default-instance/cores/</str>
</solr>
solrconfig.xml is located at (solrhome)/default-instance/conf/solrconfig.xml
When trying to create a core with the url
http:/example.org/solr/admin/cores?action=CREATE&name=test-name&schema=schema-test.xml&loadOnStartup=false
gives me the error:
Error CREATEing SolrCore 'test-name': Unable to create core: test-name
Caused by: Can't find resource 'solrconfig.xml' in classpath or
'default-instance/cores/test-name/conf/', cwd=/var/lib/tomcat7
The following seems to work:
http:/example.org/solr/admin/cores?action=CREATE&name=test-name&schema=schema-test.xml&loadOnStartup=false&config=/absolute/file/path/to/solrconfig.xml
The problem is this only seems to work with a absolute path (or possibly a relative path from /var/lib/tomcat7) which is not a workable solution.
What i'm looking for is a way to place solrconfig.xml so it can be used to create new cores with that config (or a way the create those cores with the current location).
More or less the same will be needed for schemas
This worked. Ran on command line and was viewable in admin console:
solr create -c (name for core or collection)
See README.txt for more info.
In my case I took advantage of the Core Discovery feature in 4.4+, rather than creating the core using the management web interface.
This simply involved copying the example collection1 folder from the examples directory (which I usually use as a starting point).
Then I had to make sure that there is core.properties in the root of my new core with name=<new core name> inside. Solr automatically detected the new core and allowed me to use it without any fuss.
This avoided the trouble of having to copying solrconfig.xml and schema.xml into any special location.
I had the same problem: solrconfig.xml was not in the classpath. I solved it by copying my configuration file templates into the classpath.
So I took a look at http://localhost:8983/solr/#/~java-properties to see solrs classpath definition and then i copied the template solrconfig.xml and schema.xml into the folder C:\servers\solr-4.4.0\example\resources. Furthermore i copied all the stopwords stuff there...
This solution is not a fully satisfying, but it works. Adding another path to the classpath should work, too. I'm slightly astonished that no default configuration for new cores can be declared within solr.xml
I recommend the new Config Sets for this use case.
If you place your schema.xml and solrconfig.xml (and other config files like stopwords etc.) in a directory $SOLR_HOME/configsets/myConfig/conf, you can create a new core with this config by calling:
http://solr/admin/cores?action=CREATE&name=mycore&instanceDir=my_instance&configSet=myConfig
See https://cwiki.apache.org/confluence/display/solr/Config+Sets
But they are not available until Solr 4.8, see https://issues.apache.org/jira/browse/SOLR-4478
Can you help me configuring Apache Solr using Tomcat and how to index in MS SQL database using Solr.
What are the steps to configure Tomcat to run Apache Solr in Tomcat.
Here is the step by step procedure that would help.
PART 1: SETTING UP SOLR with TOMCAT
Step 1: Download Solr. It's just a zip file.
Step 2: Copy from your SOLR_HOME_DIR/dist/apache-solr-1.3.0.war to your tomcat webapps directory: $CATALINA_HOME/webapps/solr.war – Note the war file name change. That’s important.
Step 3: Create your solr home directory at a location of your choosing. This is where the configuration for that solr install resides. The easiest way to do this is to copy the SOLR_HOME_DIR/examples/solr directory to wherever it is you want your solr home container to be. Say place it in C:\solr.
Step 4: Hope you have set your environment variables, if not then please set JAVA_HOME, JRE_HOME, CATALINA_OPTS, CATALINA_HOME. Note that CATALINA_HOME refers to your Tomcat directory & CATALINA_OPTS refers to the amount of heap memory you want to give to your Solr.
Step 5: Start tomcat. Note this is only necessary to allow tomcat to unpack your war file. If you look under $CATALINA_HOME/webapps there should now be a solr directory.
Step 6: Stop tomcat
Step 7: Go into that solr directory and edit WEB-INF/web.xml. Scroll down until you see an entry that looks like this:
<!-- People who want to hardcode their "Solr Home" directly into the
WAR File can set the JNDI property here...
-->
<!--
<env-entry>
<env-entry-name>solr/home</env-entry-name>
<env-entry-value>/Path/To/My/solr/Home/solr/</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
-->
Set your Solr home (for example: C:\solr) and uncomment the env entry.
Step 8: Start Tomcat again, and things should be going splendidly. You should be able to verify that solr is running by trying the url http://localhost:8080/solr/admin/.
PART 2: SETTING UP SOLR WITH MSSQL SERVER USING DATA IMPORT HANDLER
Step 1: Download Microsoft SQL Server JDBC Driver 3.0. Just extract the contents. Create a folder under your solr home directory (Example: C:\solr\lib). Copy the file sqljdbc4.jar out of the archive downloaded above into it.
Step 2: So under your Solr home the basic directories needed are conf and lib. The first one i.e. conf you might have got with Step 3 of part 1 & lib is the directory you have created in Step 1 of part 2.
Step 3. Go to conf directory. Please open 3 files in your editor: data-config.xml, schema.xml & solrconfig.xml.
Step 4. Start by editing data-config.xml. Place your SQL query, DB Name, Server name etc. For an example:
• <dataConfig>
• <dataSource type="JdbcDataSource" driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" url="jdbc:sqlserver://X.Y.Z.U:1433;databaseName=myDB" user="test" password="tester" />
• <document>
• <entity name="Text" query="select DocumentId, Data from Text">
• <field column="DocumentId" name="DocumentId" />
• <field column="Data" name="Data" />
• </entity>
• </document>
• </dataConfig>
Step 5: Tell Solr about our data-config.xml file. This would be done by adding a request handler to the solrconfig.xml file which is solr configuration file.
Add the following requesthandler to solrconfig.xml:
• <requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
• <lst name="defaults">
• <str name="config">C:\solr\conf\data-config.xml</str>
• </lst>
• </requestHandler>
Step 6: Configure schema.xml - In this file you can do several stuff like setting up datatypes of your fields, setting unique/primary key of your search etc.
Step 7: Start Tomcat
Step 8: Now visit http://localhost:8080/solr/admin/dataimport.jsp?handler=/dataimport & start your full import.
Some handy Notes:
• There are a number of reasons a data import could fail, most likely due to problem with
the configuration of data-config.xml. To see for sure what's going on you'll have to look in
C:\tomcat6\logs\catalina.*.
• If you happen to find that your import is failing due to system running out of memory,
however, there's an easy, SQL Server specific fix. Add responseBuffering=adaptive and
selectMethod=cursor to the url attribute of the dataSource node in data-config.xml. That stops the
JDBC driver from trying to load the entire result set into memory before reads can occur.
• Note that by default the index gets created in C:\Tomcat6\bin\solr\data\index. To change this path
just edit solrconfig.xml & change <dataDir>${solr.data.dir:./solr/data}</dataDir>.
• In new Solr versions, I think 3.0 and above you have to place the 2 data import handler
jars in your solr lib directory (i.e. for example apache-solr-dataimporthandler-3.3.0.jar & apache-
solr-dataimporthandler-extras-3.3.0.jar). Search for them in your Solr zip you downloaded. In older
Solr versions this is not required because they are bundled with solr.war. Since we have placed the
data import handlers in the lib directory so we need to specify their paths in solrconfig.xml. Add
this line to solrconfig.xml: (Example: <lib dir="C:/solr/lib/" regex="apache-solr-dataimporthandler-
\d.*\.jar" />)