Alfresco And SOLR

From alfrescowiki

Introduction

From Alfresco 4.0, SOLR is available to support search within the Alfresco repository. The existing embedded lucene index will continue to be available in 4.0.

Choosing SOLR for search support has many advantages but you will not be able to use them if you require:

WCM based on AVM;
Records Management (RM module)
- as the query result with SOLR are eventually consistent
- the SOLR query does not yet enforce RM caveats (protected markings)
- the next release of the RM module will allow for (or fix) these limitations
- RM 2.0 and later will support SOLR
Multi-tenancy
- "Early access" for this will first be available in 4.c
you need in-transaction indexing and are not happy with eventually consistent results, or cannot resolve this requirement in another way. For example, taking advantage of changes to the NodeService and other Services.

Search has been moved into a sub-system with a "solr" and "lucene" implementation.

The Alfresco SOLR Search sub-system supports the same query languages as the embedded lucene sub-system. The same fields (ID , PARENT, properties) are also available. The only minor difference is that SOLR only supports the opencmis based CMIS query language. This is more strict in its adherence to the CMIS specification - type and aspect names are case sensitive.

The SOLR sub-system has the following improvements:

"standard" tokenisation, in addition to local specific tokenisation, to support better cross-language support
uses the datetime analyser for d:datetime properties (variable resolution search e.g. cm:created:2010)
a more performant PATH implementation
evaluates READ access at query time (but does not yet apply RM caveats)
evaluates tenant restrictions at query time.
no in-transaction indexing
cross-locale ordering for d:text and d:mltext properties
full integration with the Alfresco data model including tracking model changes
support via the SearchService for simple field based faceting - faceting is after read access enforcement
no need to duplicate indexes on every machine in a cluster
search support can be scaled separately from the Alfresco Repository (for example 2 SOLR master instances for a 4 cluster node)
- there is curently no slave replication support
use the solr built in admin http://localhost:8080/solr/alfresco/admin/ to check tokenisation behaviour, terms in the index etc

Configuring Alfresco

To configure alfresco to use SOLR set the following properties

 index.subsystem.name=solr
 solr.host=localhost
 solr.port=8080
 solr.port.ssl=8443

These properties can also be set via JMX (MBeans - Alfresco - Configuration - Search) and the Share admin page if you are using Alfresco Enterprise. You can switch between lucene and solr - in JMX this is done by setting the manager sourceBeanName to "solr" or "lucene". The subsystems make available their own related properties. The "managed - solr" instance exposes solr.base.url. The lucene sub-system exposes all the properties that had to be set at start up. These can now be configured live and the sub-system redeployed.

Configuring the SOLR web app

Setting up the SOLR web app from the distribution

The distribution will contain a zip file named something like

alfresco-enterprise-solr-4.0.0d.zip

This archive contains:

a template SOLR home directory, containing solr.xml etc as expected by SOLR
the solr war
- patched to alow an initial backup to made after start up
- patched to limit the number of back ups
- patched to support SSL
an example context to wire up in tomcat
instructions on how to set up the web app in HowToSetUpSolr.txt
a lib directory with all the alfresco and other jars that are required
two SOLR core configurations, one to track the live SpacesStore and one to track items archived from the SpacesStore
- Note: tracking includes the SpacesStore for all tenants - separate cores are not required for each tenant

extract the archive to some location <SOLR-ARCHIVE>
Copy solr-tomcat-context.xml to apache-tomcat-6.0.26\conf\Catalina\localhost\solr.xml (for set up on other app contains refer to the SOLR wiki)
edit docBase in solr.xml to point to <SOLR-ARCHIVE>\apache-solr-1.4.1.war
edit solr/home in xml to point to <SOLR-ARCHIVE>
For each core edit solrcore.properties e.g archive-SpacesStore/conf/solrcore.properties and workspace-SpacesStore/conf/solrcore.properties
1. edit the "data.dir.root" property to where the solr indexes will be stored - you can set the same value for the both cores and the cores will create the sub-directories)
2. edit the url to point to Alfresco "alfresco.url" - this could point to the load balancer in front of an alfresco cluster

It is possible to set properties via the solr.xml file. To configure a property in solr.xml, remove it from the two core propertis files and add it to solr.xml either as a common property or one that is core specific.

It is possible to set properties via the solr.xml file. To configure a property in solr.xml, remove it from the two core propertis files and add it to solr.xml either as a common property or one that is core specific. See http://lucidworks.lucidimagination.com/display/solr/Configuring+solr.xml for more details.

<solr persistent="true" sharedLib="lib" >  
  <cores adminPath="/admin/cores" adminHandler="org.alfresco.solr.AlfrescoCoreAdminHandler">    
  <-- common root dir -->    
  <property name="data.dir.root" value="w:/woof" />    
  <core name="alfresco" instanceDir="workspace-SpacesStore" />    
  <core name="archive" instanceDir="archive-SpacesStore" >      
    <property name="data.dir.root" value="w:/woof" />    
  </core>  
</cores></solr>

See http://wiki.apache.org/solr/SolrInstall for details on how to set up SOLR in other containers.

Setting up the SOLR web app from the source

Is very similar to the distribution.

The source contains a project ..\HEAD\root\projects\solr, and within that a directory with the basis of what the distribution contains, but with out the libraries. This is ..\HEAD\root\projects\solr\source\solr\instance. To build the libraries, change to the directory ..\HEAD\root and run the command "ant deploy-solr". The directory ..\HEAD\root\projects\solr\source\solr\instance should now match what you would extract from the distribution.

Then follow the steps above to complete the installation.

To upgrade SOLR

Get the new SOLR distribution and set it up as above. Apply your recorded local changes to the new distribution (or diff the old and new configurations) The release notes will indicate if a rebuild of the index is required and the old indexes should not be used.

Setting up SOLR web app using the installer

The installer carries out the above steps to install SOLR in the same tomcat container as Alfresco. The connection URL is unchanged from the default. The SOLR home is in the Alfresco data dir, which also contains the SOLR data files.

example solr/xml

<?xml version="1.0" encoding="utf-8"?>
<Context docBase="<SOLR-ARCHIVE>\apache-solr-1.4.1.war" debug="0" crossContext="true">
   <Environment name="solr/home" type="java.lang.String" value="<SOLR-ARCHIVE>" override="true"/>
</Context>

Security

Communications between the repository and Solr are protected by SSL with mutual authentication. Both the repository and Solr have their own public/private key pair, which are stored in their own respective keystores. These keystores are bundled with Alfresco; the customer is free to create their own if desired (see below).

Repository SSL Keystores

See also the wiki entry Data Encryption, section 'Alfresco Keystores'.

The repository has two keystores it uses for SSL:

the 'ssl keystore' containing a public/private RSA key pair for the repository, and
the 'ssl truststore' containing the trusted Alfresco Certificate Authority certificate (which has been used to sign both the repository and Solr certificates).

These key stores can be stored wherever the customer desires; the following properties need to be updated accordingly in alfresco-global.properties.

SSL Keystore

Keystore location: encryption.ssl.keystore.location
Keystore provider: encryption.ssl.keystore.provider
Keystore type: encryption.ssl.keystore.type
Keystore metadata file location: encryption.ssl.keystore.keyMetaData.location

SSL Truststore

Keystore location: encryption.ssl.truststore.location
Keystore provider: encryption.ssl.truststore.provider
Keystore type: encryption.ssl.truststore.type
Keystore metadata file location: encryption.ssl.truststore.keyMetaData.location

Solr SSL Keystores

Each Solr core similarly has two SSL keystores, the 'ssl.repo.client.keystore' containing a Solr public/private RSA key pair and the 'ssl.repo.client.truststore' containing the trusted Alfresco Certificate Authority certificate (which has been used to sign both the repository and Solr certificates).

Generating New SSL Keys

You may want to generate new SSL keystores.

See http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/repository/config/alfresco/keystore/CreateSSLKeystores.txt for an overview of how to create an SSL public/private key and certificate for the repository.

See http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/solr/source/solr/instance/CreateSSLKeystores.txt for an overview of how to create an SSL public/private key pair and certificate for Solr.

Connecting to the SSL-Protected Solr Web Application

All urls for the Solr web application bundled with Alfresco are protected by SSL. In order to use these from a browser you need to import a browser-compatible keystore to allow mutual authentication and decryption to work. Follow these steps to import the keystore into your browser (these relate to Firefox, other browsers will have a similar mechanism):

(i) Open the Firefox Certificate Manager

(ii) Import the browser keystore 'browser.p12' that is located in your WEB_INF/classes/alfresco/keystore directory.

The password is 'alfresco'. This should result in a dialog indicating that the keystore has been imported successfully, as the following image shows.

'Your Certificates' should now contain the imported keystore with the Alfresco repository certificate.

(iii) In your browser, navigate to a Solr url e.g. http://localhost:8080/solr. This will result in the browser displaying an error dialog of the form shown in the image.

This is probably a result of the fact that the Alfresco certificate presented to the browser is not tied to the server IP address. In this case, simply view the certificate and confirm that it is signed by the Alfresco CA, by expanding "I Understand the Risks" and selecting "Add Exception":

then click "View" to view the certificate.

Confirm that the certificate was issued by "Alfresco CA" and then confirm the Security Exception (you may also want to uncheck the "Permanently store this exception" checkbox).

Access to Solr will be granted as shown in the image below.

Running Without SSL

In alfresco-global.properties, set the property "solr.secureComms" to "none" and ensure that the property "solr.port" is set to the correct non-SSL port of the application server in which Solr is running. Similarly, in each solrconfig.properties file, set the property "alfresco.secureComms" to "none" and ensure that the property "alfresco.port" is set to the correct non-SSL port of the application server in which your repository is running.

In the repository web.xml, remove the following configuration:

   <security-constraint>
      <web-resource-collection>
         <url-pattern>/service/api/solr/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
         <role-name>repoclient</role-name>
      </auth-constraint>
      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
   </security-constraint>
   <login-config>
      <auth-method>CLIENT-CERT</auth-method>
      <realm-name>Repository</realm-name>
   </login-config>
   <security-role>
     <role-name>repoclient</role-name>
   </security-role>

In the solr web.xml, remove the following configuration:

     <security-constraint>
         <web-resource-collection>
             <url-pattern>/*</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>repository</role-name>
         </auth-constraint>
         <user-data-constraint>
             <transport-guarantee>CONFIDENTIAL</transport-guarantee>
         </user-data-constraint>
     </security-constraint>
      <login-config>
         <auth-method>CLIENT-CERT</auth-method>
         <realm-name>Solr</realm-name>
     </login-config>
      <security-role>
        <role-name>repository</role-name>
     </security-role>

Migration

For community releases of 4.0, upgrade to Alfrecso 4.0 - with the lucene sub-system enabled. (Some patches may depend on search)

It is possible to upgrade to Enterprise versions of ALfrecso 4.0 and later with SOLR in place at upgrade time

Set up the SOLR web app and then let it track the repository (you cna confirm this by tuning on debug described below) You can use the lucene search sub-system while this is going. Configure the solr search subsystem properties (it does not have to be active to configure it via JMX or Share) Check the SOLR tracking status using the admin tools. When you are up to date enough switch the search sub-system You can always switch back - the lucene index will rebuild from where it was as the sub-system starts.

Checking the status of the SOLR index

Direct URLs

Summary Report

Quick summary report http://localhost:8080/solr/admin/cores?action=SUMMARY&wt=xml

With multi-threaded tracking (available from 4.0.2) there are additional tracking details and tracking statistics

detail=true
- provide statistics per tracking thread
hist=true
- provides a histogram of the times take for tracking operations for each tracking thread
reset=true
- resests all tracking statistics
values=true
- reports (by default) the last 50 values recorded for each tracking operation for each thread

Last Index Commit Time: - the timestamp for the last transaction that was indexed

Last Index Commit Date: - the timestamp as a date for the last transaction taht was indexed; - changes made after this time are not yet in the index

Lag: - the diffenerence in seconds between the the last transaction timestamp on the server and the timestamp for the last transaction that was indexed

Duration: - The lag as an XML duration so you do not have to do the Math

Active: - is the tracker for the core active

Timestamp for last TX on server

Date for last TX on server

Id for last TX on server

Id for last TX in index

Approx transactions remaining: - the approximate number of transactions to index to bring the index up-to-date; - the last TX id on the server minus the last tx id indexed; - the estimate will include missing and emtry transacations

Approx indexing time remaining: - 4.0; - Based on "Approx transactions remaining" and the average time to index a transaction how long the index will take to be up-to-date; - 4.0.2 and later; - Based on "Approx transactions remaining", the average number of nodes per transaction and the average time to index a node - how long the index will take to be up-to-date; - the estimate is in the most appopriate scale e.g. seconds, minutes, hours, days; - if in hours then no minutes or seconds will be provided

Model sync times (ms): - summary stats for the model sync time; - &detail=true - adds per thread stats; - &hist=true - adds per thread histogram of reposnse times; - &value=true - adds recent response times

Acl index time (ms) - 4.0.2 and later: - summary stats for acl index time; - supports additional info with &detail=true &hist=true &value=true

Node index time (ms) - 4.0.2 and later: - summary stats for node index times; - supports additional info with &detail=true &hist=true &value=true

Acl tx index time (ms) - 4.0 only (acl tx based stats removed in favour of per acl stats for multi-threaded tracking): - summary stats for ACL TX index time; - supports additional info with &detail=true &hist=true &value=true

Tx index time (ms) - 4.0 only (tx based stats removed in favour of per nodes stats for multi-threaded tracking): - summary stats for TX index time; - used to estimate the time required to bring the index up-to-date

Docs/Tx: - summary stats for the number of docs per transaction; - supports additional info with &detail=true &hist=true &value=true

Doc Transformation time (ms): - summary stats for document transformation time; - supports additional info with &detail=true &hist=true &value=true

Overal all status report

General report - including the last TX indexed and the time http://localhost:8080/solr/admin/cores?action=REPORT&wt=xml

DB transaction count: - the transaction count on the database

DB acl transaction count: - the acl transaction count on the database

Count of duplicated transactions in the index: - the number of transactions that appear more than once in the index; - should be zero (if not there is an issue with the index)

Count of duplicated acl transactions in the index: - the number of ACL transactions that appear more than once in the index; - should be zero (if not there is an issue with the index)

Count of transactions in the index but not the database: - should be zero (if not there MAY be an issue with the index); - this count can include now empty transactions that have been purged from the database

Count of acl transactions in the index but not the DB: - should be zero (if not there is an issue with the index); - note empty acl transactions are not currently purged from the database

Count of missing transactions from the Index: - the number of transactions in the database but not in the index; - should be zero when the index is up-to-date; - this may just reflect the index still cathing up (this would then be "how many transactions are threre still to index or missing?")

Count of missing acl transactions from the Index: - the number of acl transactions in the database but not in the index; - should be zero when the index is up-to-date; - this may just reflect the index still cathing up (this would then be "how many acl transactions are threre still to index or missing?")

Index transaction count: - the number of transactions in the index

Index acl transaction count: - the number of acl transactions in the index

Index unique transaction count: - the number of unique transactions in the index

Index unique acl transaction count: - the number of unique acl transactions in the index

Index leaf count: - the number of docs and folders in the index

Count of duplicate leaves in the index: - the number of duplicate docs or folders in the index; - should be zero (if not there is an issue with the index)

Last index commit time: - the timestamp for the last transaction added to the index; - transactions after this timestamp have not yet been indexed

Last Index commit date: - the timestamp as date for the last transaction added to the index; - transactions after this date have not yet been indexed

Last TX id before holes: - SOLR tracking by default goes back an hour from the current time to check that no transactions have been missed; - transactions after this id will be checked again to make sure they have not been missed.; - this is computed from the index at start up time and is initially, by default, an hour after the last commit time found in the index

First duplicate: - optional; - if there are duplicate transactions in the index the id of the first duplicate transaction

First duplicate acl tx: - optional; - if there are duplicate acl transactions in the index the id of the first duplicate acltransaction

First transaction in the index but not the DB: - optional; - if the related count is > 0, the id of the first offender

First acl transaction in the index but not the DB: - optional; - if the related count is > 0, the id of the first offender

First transaction missing from the Index: - optional; - if the related count is > 0, the id of the first offender

First acl transaction missing from the Index: - optional; - if the related count is > 0, the id of the first offender

First duplicate leaf in the index: - optional; - if the related count is > 0, the id of the first offender

Check the cache

The next time the index commits the ceching used for PATH and ACL evaluation will be exhautively checked and fixed up if in error.

http://localhost:8080/solr/admin/cores?action=CHECK

General fix

Fix any issues as reported by the REPORT option http://localhost:8080/solr/admin/cores?action=FIX

Purge/remove from the index

Can be used to remove transactions, acl transactions, nodes and acls from the index May be used to create holes for testing.

http://localhost:8080/solr/admin/cores?action=PURGE&txid=1&acltxid=2&nodeid=3&aclid=4

Reindex a transaction, acl transaction, node or acl

http://localhost:8080/solr/admin/cores?action=REINDEX&txid=1&acltxid=2&nodeid=3&aclid=4

Index a transaction, acl transaction, node or acl

This will create entries in the index. It will not delete the entry first so can be used to create duplicates for testing.

http://localhost:8080/solr/admin/cores?action=INDEX&txid=1&acltxid=2&nodeid=3&aclid=4

Common report options

To specify an option core for the report. If absent a report is produced for each core e.g.

&core=alfresco
&core=archive

&txid=1
&acltxid=1
&nodeid=1
&aclid=1

SOLR index status (the normal SOLR stuff) http://localhost:8080/solr/admin/cores?action=STATUS&wt=xml

JMX

The status of the index can also be checked via JMX. MBeans - Alfresco - solrIndexes - <store alias>

The default SOLR core summary is the default vue.

The operations can run the same consistency checks available by URLs above.

You can also fix index issues, check the index cache and backup individual indexes via JMX.

Back up

Each core of the SOLR index can be backed up in its own right by URL or using cluster aware cron jobs from Alfresco. The location and cron expression for each core can be setup via Share admin or JMX. Ad hoc index back up cna be done via JMX or direct to SOLR.

SOLR will create a time-stamped sub-directory for each index back up you make. It will contain a full index back up.

The Enterprise product allows a limit on the number of backups to be set via JMX or share.

Restore

Stop SOLR. Copy a backup index to the data directory for each core. Restart SOLR - it will start to track based on the state of the restored index.

SOLR core properties in solrcore.properties

Comment out the properties in this file (for each solr core) if you wish to set them via solr.xml

Core SOLR configuration

data.dir.root=@@ALFRESCO_SOLR_DIR@@: Base data dir for the solr indexes; The most likely property you want to centralise

data.dir.store=archive/SpacesStore: The directory relative to data.dir.root where the data for this core is kept

enable.alfresco.tracking=true: Should SOLR try and track the repository

cache.alfresco.size=100: The Alfrecso cache size used internally for PATH looks up etc - leave this alone

max.field.length=2147483647: The max number of tokens to include for each field; By default we add all tokens

Configuring what to track

alfresco.host=localhost: The Alfresco host to track

alfresco.port=8080: The Alfresco host port

alfresco.port.ssl=8443: The alfresco host SSL port

alfresco.cron=0/15 * * * * ? *: How often to check if there is work to do

alfresco.stores=archive: //SpacesStore; The store to track on the Alfresco host

alfresco.lag=1000: Each "track" will run until the time when it starts - less this lag

alfresco.hole.retention=3600000: Each track will revisit all transactions from the timestamp of the last in the index, less this value, to fill in any transactions that may have been missed.

alfresco.batch.count=1000: When tracking docs will be commited in batches of this size, or for each large transaction, or at the end of the current tracking set.

Encryption

alfresco.secureComms=https: https or none; Remember to fix up the configuration in web.xml for Alfresco and SOLR and the Repository side property for query.

SSL

alfresco.encryption.ssl.keystore.type=JCEKS
alfresco.encryption.ssl.keystore.provider=
alfresco.encryption.ssl.keystore.location=ssl.repo.client.keystore
alfresco.encryption.ssl.keystore.passwordFileLocation=ssl-keystore-passwords.properties
alfresco.encryption.ssl.truststore.type=JCEKS
alfresco.encryption.ssl.truststore.provider=
alfresco.encryption.ssl.truststore.location=ssl.repo.client.truststore
alfresco.encryption.ssl.truststore.passwordFileLocation=ssl-truststore-passwords.properties

Tracking

Configuration for multi-threaded tracking - 4.0.2 and later

alfresco.enableMultiThreadedTracking=false: Enable/Disable multi-threaded tracking

alfresco.corePoolSize=4: Pool size for multi-threaded tracking - use for indexing nodes; "1" means one thread indexing nodes and one tracking transactions; "4" means four threads indexing nodes and one tracking transactoins

alfresco.maximumPoolSize=-1

alfresco.keepAliveTime=120

alfresco.threadPriority=5

alfresco.threadDaemon=true

alfresco.workQueueSize=-1: The default queue size is unlimited

HTTP Client

HTTP Client configuration.

alfresco.maxTotalConnections=40
alfresco.maxHostConnections=40

SOLR caching

The SOLR cache confguration from solrconfig.xml exposed as properties. Check the performance of these caches for each core using the SOLR admin pages.

solr.filterCache.size=512
solr.filterCache.initialSize=512: You may want to increase these if you have many users, groups, tenants

solr.queryResultCache.size=512
solr.queryResultCache.initialSize=512: Increase these to cache more query results

solr.documentCache.size=512
solr.documentCache.initialSize=512

solr.queryResultMaxDocsCached=200: Makes sense to put this higher if you expect to page through most results

FAQ

When do I have to rebuild the index?
- If there are incompatible schema changes
  - e.g. a property, type or aspect is renamed
  - a property data type is changed
- Lucene/SOLR upgrade requires it
  - Advanced warning - this will be required for SOLR 4.0
- There is some change to the analysis configuration
  - e.g. change French analysis - change the tokenisation or remove the language specific configuration

How would I rebuild the index from scratch?
Note: you could start a new SOLR web app and switch to use this when the rebuild is done
Note: the index.recovery.mode=FULL is not used by SOLR - only lucene
- Stop the SOLR web app
- delete the index data directory for each core
- optionally, delete the models cached on the SOLR side for each core (e.g. ...\archive-SpacesStore\alfrescoModels\*)
- restart the SOLR web app

I believe there is something wrong with my SOLR index what do I do?
- Use the index checker and fix features described above
- You can set up more than one SOLR instance to track the same reposiroty
  - You can rebuild a new SOLR index while continuing to use the old (with whatever issues you have)
  - There is no enforced down time at start up compared with using the lucene index

How do I change SOLR logging
- SOLRHOST:8443:/solr/ (you may need to install client certificate if you haven’t already)
- Select the “Admin alfresco” link to work with the workspace store (or the archive one if you are checking the archive store)
- Select the “[LOGGING]” link
- For info about tracking set INFO level logging for:
  - org.alfresco.solr.tracker.CoreTracker
  - org.alfresco.solr.tracker.CoreTrackerJob
  - org.alfresco.solr.tracker.CoreWatcherJob
  - Use the “set” option at the bottom of the page to save the changes
- For query debug set FINE for:
  - org.alfresco.solr.query.AbstractQParser
  - org.alfresco.solr.query.AlfrescoFTSQParserPlugin
  - org.alfresco.solr.query.AlfrescoLuceneQParserPlugin
  - org.alfresco.solr.query.CmisQParserPlugin
- For response timing (query time and match reporting)
  - org.apache.solr.core.SolrCore @INFO

What does the SOLR tracking INFO mean ....

17-Nov-2011 11:22:45 org.alfresco.solr.tracker.CoreTracker trackRepository
INFO: .... from Transaction [id=374, commitTimeMs=1321528572425, updates=1, deletes=0]  
17-Nov-2011 11:22:45 org.alfresco.solr.tracker.CoreTracker trackRepository
INFO: .... to Transaction [id=374, commitTimeMs=1321528572425, updates=1, deletes=0]

- Look at “from Transaction” to “to Transaction”
- If they are the same then the tracker does not have anything to do
- To check the last transaction ID in the repo you can query the DB:
  - select max(id) from alf_transaction;
  - The result will match the “from Transaction” value in the log if Solr is up to date

To over-ride sub-system Spring beans, see Alfresco_Subsystems#Spring_Beans

Community

Views

Alfresco And SOLR

From alfrescowiki

Contents

Introduction

Configuring Alfresco

Configuring the SOLR web app

Setting up the SOLR web app from the distribution

Setting up the SOLR web app from the source

To upgrade SOLR

Setting up SOLR web app using the installer

example solr/xml

Security

Repository SSL Keystores

Solr SSL Keystores

Generating New SSL Keys

Connecting to the SSL-Protected Solr Web Application

Running Without SSL

Migration

Checking the status of the SOLR index

Direct URLs

Summary Report

Overal all status report

Transaction specific reports

ACL TX specific reports

Node specific reports

ACL specific reports

Check the cache

General fix

Purge/remove from the index

Reindex a transaction, acl transaction, node or acl

Index a transaction, acl transaction, node or acl

Common report options

JMX

Back up

Restore

SOLR core properties in solrcore.properties

Core SOLR configuration

Configuring what to track

Encryption

SSL

Tracking

HTTP Client

SOLR caching

FAQ

Personal tools

Navigation

Download and go

Support

Participate

Community

Alfresco Cookbooks

Search

Toolbox

Products

Downloads

Services

Resources