Lucene Configuration

Lucene, the search indexer which Web Space Server uses, can be in a shared configuration for a clustered environment, or an index can be created on each node of the cluster. If you wish to have a shared index, you will need to either share the index on the file system or in the database.

The Lucene configuration can be changed by modifying values in your portal-ext.properties file. Open your portal.properties file and search for the text Lucene. Copy that section and then paste it into your portal-ext.properties file.

If you wish to store the Lucene search index on a file system that is shared by all of the Web Space Server nodes, you can modify the location of the search index by changing the lucene.dir property. By default, this property points to the /webspace/lucene folder inside the home folder of the user running Web Space Server:

lucene.dir=${resource.repositories.root}/lucene/

Change this to the folder of your choice. To make the change take effect, you will need to restart Web Space Server. You can point all of the nodes to this folder, and they will use the same index.

Like Jackrabbit, however, this is not the best way to share the search index, as it could result in file corruption if different nodes try reindexing at the same time. A better way is to share the index via a database, where the database can enforce data integrity on the index. This is very easy to do; it is a simple change to your portal-ext.properties file.

There is a single property called lucene.store.type. By default this is set to go to the file system. You can change this so that the index is stored in the database by making it the following:

lucene.store.type=jdbc

The next time Web Space Server is started, new tables will be created in the Web Space Server database, and the index will be stored there. If all the Web Space Server nodes point to the same database tables, they will be able to share the index.

Alternatively, you leave the configuration alone, and each node will then have its own index. This ensures that there are no collisions when multiple nodes update the index, because they all will have separate indexes.