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" />
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!
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
I'm attempting to update my solr config via the Solr Config API. I attempting to first query the config with the following endpoint:
http://localhost:8983/solr//config
the response I get back is 500 Internal Server Error and I noticed in logs for the deployed solr the following exception:
Internal Server Error (500) - No RestManager found!
at org.apache.solr.rest.RestManager.getRestManager(RestManager.java:245)
at org.apache.solr.rest.SolrConfigRestApi.createInboundRoot(SolrConfigRestApi.java:67)
at org.restlet.Application.getInboundRoot(Application.java:270)
at org.restlet.engine.application.ApplicationHelper.start(ApplicationHelper.java:127)
at org.restlet.Application.start(Application.java:582)
The core was created using the following post:
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=<keyspace.table>&generateResources=true&reindex=true"
This action was successful but a GET to the config api fails.
The url should be: http://localhost:8983/solr/#/[ks.cf]/config
Still there are convenience/recommended methods to avoid you all the curl commands. See:
dsetool create_core
dsetool get_core_config
dsetool get_core_schema
dsetool reload_core
In your case a dsetool create_core, dsetool get_core_config, modify the solrconfig.xml and a later dsetool reload_core with the new solrconfig should get you what you need. See: Dsetool doc for usage details
If you need some examples on how to do that with curl, if you still need to use curl, see the shell files under the wikipedia demo, 1-add-schema.sh for instance. Still dsetool commands are the recommended method.
If you intended to use the Solr Config API please notice this is Solr 5 feature and in DSE you will find version 4.10 so that feature is not available yet. If you want to change the solr config you will have to reload with the new solrconfig using the outlined dsetool commands above.
It would be very useful to know the exact version you are using.
Hope it helps.
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
I have installed Apache Solr with Tomcat and my /solr/admin is working fine. But when I try to issue /solr/update I am getting the following error. What could be the reason?
org.apache.solr.common.SolrException: missing content stream
If you add commit parameter i.e. ?commit=true, it will work
/solr/update will look for any input documents to be indexed. Running plain /solr/update will cause this exception since there is no input for it. The easiest way to run it is like,
java -Durl=localhost:8080/<your apache solr context path, mostly solr>/update -jar post.jar *.xml
This can also happen through SolrJ/spring-data-solr if you try to persist an empty collection of documents.
So solrClient.add(new ArrayList<SolrInputDocument>(), 10000);
would also cause the error.