cancel
Showing results for 
Search instead for 
Did you mean: 

Alfresco 5.0.2: configuring an external Solr instance

mikeblum
Champ in-the-making
Champ in-the-making
Hi,

I'm working on moving an Alfresco 5.0.2 install to use an external Solr. I have copied the ALFRESCO_HOME/solr4 directory and created a C:/alfresco_solr. I'm running Solr-4.9.1 on Tomcat 7 and Java 8. Going off of this document: http://docs.alfresco.com/5.0/tasks/solr4-install-config.html, I discovered that the context.xml copied to the SOLR_TOMCAT/conf/Catalina/localhost needs to be called solr.xml NOT solr4.xml. With my ALFRESCO_HOME at C:/Alfresco I made a solr.xml that points to the copied solr4 directory at C:/alfresco_solr:


<?xml version="1.0" encoding="utf-8"?>
<Context debug="0" crossContext="true">
  <Environment name="solr/home"        type="java.lang.String" value="C:\alfresco_solr" override="true"/>
  <Environment name="solr/model/dir"   type="java.lang.String" value="C:\Alfresco\alf_data\solr4\model" override="true"/>
  <Environment name="solr/content/dir" type="java.lang.String" value="C:\Alfresco\alf_data\solr4\content" override="true"/>
</Context>


When I start up the Solr Tomcat I get the following exception:


ERROR - 2016-01-26 14:05:06.910; org.apache.solr.common.SolrException; nullSmiley Surprisedrg.apache.solr.common.SolrException: Unable to create core: archive
   at org.apache.solr.core.CoreContainer.recordAndThrow(CoreContainer.java:911)
   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:568)
   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:261)
   at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:253)
   at java.util.concurrent.FutureTask.run(Unknown Source)
   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
   at java.util.concurrent.FutureTask.run(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.solr.common.SolrException: Could not load core configuration for core archive
   at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:66)
   at org.apache.solr.core.CoreContainer.create(CoreContainer.java:554)
   … 8 more
Caused by: org.apache.solr.common.SolrException: Error loading solr config from C:\alfresco_solr\archive-SpacesStore\solrconfig.xml
   at org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:148)
   at org.apache.solr.core.ConfigSetService.createSolrConfig(ConfigSetService.java:79)
   at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:61)
   … 9 more
Caused by: org.apache.solr.common.SolrException: Error loading class 'org.alfresco.solr.cache.AuthorityCacheRegenerator'
   at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:490)
   at org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:521)
   at org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:517)
   at org.apache.solr.search.CacheConfig.getConfig(CacheConfig.java:100)
   at org.apache.solr.search.CacheConfig.getMultipleConfigs(CacheConfig.java:73)
   at org.apache.solr.core.SolrConfig.<init>(SolrConfig.java:230)
   at org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:144)
   … 11 more
Caused by: java.lang.ClassNotFoundException: org.alfresco.solr.cache.AuthorityCacheRegenerator
   at java.net.URLClassLoader$1.run(Unknown Source)
   at java.net.URLClassLoader$1.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.net.FactoryURLClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Unknown Source)
   at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:474)
   … 17 more

INFO  - 2016-01-26 14:05:0

and get the same trace for the alfresco core. I tried loading the solr4.war from the alfresco instasll onto the external tomcat and have issues with the SSL/TLS handshake. Is it possible to use regular Solr 4 to host the external Solr for Alfresco 5+? I've looked that the jars included in the solr4.war and can't seem to resolve the org.alfresco.solr.cache.AuthorityCacheRegenerator dependency. Any guidance would be much appreciated.

Thanks
3 REPLIES 3

progdevtom
Champ in-the-making
Champ in-the-making
Hi,
did you solve this issue? I'm trying the same thing, using a central solr instance to also service alfresco. But I get the same error message. I'm a bit surprised there is so little information to find on this subject? Is there a reason why it shouldn't be done?

Hi,

Not sure how well this is going to work for you, without a lot of tweaking (but I haven't tried it myself).  The classes your dependent on are coming from the  alfresco-solr4xxx.jar that you'll need to have on the classpath of your external Solr.  As well as this, Alfresco have added other alfresco jars to the Solr4 webapp so I'd guess you'd need these two. You can find them in your alfresco tomcat's webapps/solr4/WEB-INF/lib directory.

Even if you do get past this dependency issue (and there may be other issues hiding behind this as well), I imagine you'll have the same problem you saw when copying the war out.  Alfresco is configured to use bidirectional SSL to secure the communication between Solr and Alfresco so unless you also apply the same security on your external Solr using the same certificates or disable the SSL requirement completely you won't be able to get Alfresco and the new Solr to talk to each other.

Also putting Solr and Alfresco on different servers is going to generate a lot of network traffic between the 2 nodes, and probably reduce performance.  The model used by Alfresco is actually a pull model from Solr rather than a push into Solr.  So the alfresco code (from the extra jars) that lives in the Solr app makes frequent HTTPS calls to Alfresco to determine if there is new content, ACLS, models etc to index and if there is it pulls those across creates Solr document objects from them and then uses standard Solr APIs to ingest the content into the index.  This lets the Alfresco application not worry about the need for indexing at all with the exception of answering specific questions that Solr asks periodically.  It also leads to the eventual consistency model that is used for indexing since the introduction of Solr in Alfresco 4.0

WIth regards the use of a central Solr instance, the default Alfresco security setup is going to make this difficult to do.  Either you allow Solr to use bidirectional SSL so that Alfresco knows it's talking to a trusted Solr but which will probably break your ability to access the SOlr index from anything other than Alfresco, or you turn off the SSL requirement both for Alfresco and Solr, which means that anyone who can access the Solr node can impersonate <em>any</em> user and retrieve any content/metadata/index info that exists in the index, bypassing all Alfresco security imposed on the content itself

So, I'm sure it's possible to do, but it's not often done because of the complexities from the design.  And that's the real point, Alfresco designed the index service to work with a dedicated Alfresco Solr node, not a shared Solr service.

Regards

Steven

Hello Steven,
Thanks for your insights.
In this context it indeed makes more sence to setup another solr instance for other purposes. I don't want to start messing with the SSL part of this setup.
It was nice as a POC but indeed it won't be practical wrt performance.
Thanks again.