cancel
Showing results for 
Search instead for 
Did you mean: 

content store to solr core mapping

dbiggins
Star Contributor
Star Contributor
We are using 4.2 EE on a linux / postgres environment.  I have Solr running on the same physical server as alfresco.

I would like to have one or more content stores have their indexing stored in one of multiple solr cores. 

I can create multiple stores by adding the following 'content-store-selector-context.xml' to my extensions folder:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>
<beans>
        <bean id="firstSharedFileContentStore" class="org.alfresco.repo.content.filestore.FileContentStore">
                <constructor-arg>
                        <value>${dir.root}/storeA</value>
                </constructor-arg>
        </bean>
        <bean id="secondSharedFileContentStore" class="org.alfresco.repo.content.filestore.FileContentStore">
                <constructor-arg>
                        <value>${dir.root}/storeB</value>
                </constructor-arg>
        </bean>
        <bean id="storeSelectorContentStore" parent="storeSelectorContentStoreBase">
                <property name="defaultStoreName">
                        <value>default</value>
                </property>
                <property name="storesByName">
                        <map>
                                <entry key="default">
                                        <ref bean="fileContentStore" />
                                </entry>
                                <entry key="storeA">
                                        <ref bean="firstSharedFileContentStore" />
                                </entry>
                                <entry key="storeB">
                                        <ref bean="secondSharedFileContentStore" />
                                </entry>
                        </map>
                </property>
        </bean>
<!– Point the ContentService to the 'selector' store –>
        <bean id="contentService" parent="baseContentService">
                <property name="store">
                        <ref bean="storeSelectorContentStore" />
                </property>
        </bean>
<!– Add the other stores to the list of stores for cleaning –>
        <bean id="eagerContentStoreCleaner" class="org.alfresco.repo.content.cleanup.EagerContentStoreCleaner" init-method="init">
                <property name="eagerOrphanCleanup" >
                        <value>${system.content.eagerOrphanCleanup}</value>
                </property>
                <property name="stores" >
                        <list>
                                <ref bean="fileContentStore" />
                                <ref bean="firstSharedFileContentStore" />
                                <ref bean="secondSharedFileContentStore" />
                        </list>
                </property>
                <property name="listeners" >
                        <ref bean="deletedContentBackupListeners" />
                </property>
        </bean>
</beans>



That works great: changing the content store physically copies the file on the linux box to the new directory.

I can add multiple cores to the solr instance by executing the solr admin command via http:

https://127.0.0.1:8443/solr/admin/cores?action=newCore&storeRef=storeB://system&property.data.dir.st...
and
https://127.0.0.1:8443/solr/admin/cores?action=newCore&storeRef=storeB://system&property.data.dir.st...


, and then via JMX, adding the new vals for Alfresco -> Configuration -> Search -> managed -> solr -> solr.store.mappings.  This also appears to work: a series of subdirectories are created in the alf_data subdirectory for each new core.

At what point do I tell the content store to use the specific core?  Or probably, the solr subsystem to look at the specific content store?  When I make these changes and restart, it LOOKS like three solr cores each have the same number of records.

Thanks!

3 REPLIES 3

afaust
Legendary Innovator
Legendary Innovator
Hello,

it appears you have misunderstood how the concept of (file) content stores in Alfresco relates to the SOLR index server. The SOLR index server DOES NOT index any (file) content store directly, rather it indexes a particular, logical "node store" / "workspace" such as workspace://SpacesStore.
You cannot have separate SOLR cores for different (file) content stores as long as you do not setup separate logical "node stores" / "workspace" for each of your content store and distribute the nodes to these logical stores based on their target content store.


For what reason do you want to have multiple SOLR cores instead of the standard one? Are you aware that separating your indexed content into multiple cores will also mean you can no longer perform a single query across all your content? You'd need to perform individual queries against all cores and collate the results yourself. Also, the Alfresco search end-user interfaces currently do not support selecting a specific core to target a query against and always target the standard core by default.

Regards
Axel

dbiggins
Star Contributor
Star Contributor
Axel,
Thanks!  My thoughts were that since we had different flavors of content (huge amounts of metadata rich content that is pretty static, vs smaller amount of frequently changing, and so on), we may want to have the ability to have different cores to either rebuild seperatly or apply different config options on the solr side.  I had thought that I would have an easier time directing certain queries against a particular core, but i will have to rethink this based on your comments.

In your opinion, why would I want to add a core to an alfresco solr instance?  rebuilding an index offline?

afaust
Legendary Innovator
Legendary Innovator
Hello,

a new (second) SOLR core could be used to reindex content while still serving search queries with the first ("old") core. This is basically an "online re-index" capability. When the re-index in the second core is done, you can shut down SOLR, swap the index files and restart in a matter of seconds.

Regards
Axel