Details

Description

I have a lone instance which prints the following error into the log every 10 seconds:

2009-09-09 11:02:27,502 ERROR Timer-4 org.sakaiproject.search.optimize.shared.impl.DbJournalOptimizationManager - This node already merging shared segments, index writer spellbreaker:1251938321559 This node is currently optimizing the shared segments, This is an error as only one copy of this node should be Active in the cluster

In spite of the message, this instance has never been part of a cluster.

Hi
I am facing the same error after restarting the nodes. I tried running above SQL command, but the error did not stop. I am running 2.8.0 with 2 nodes setup with Oracle 10g database.
Please advise. Your prompt reply is appreciated.

This will not be an issue with the elasticsearch impl the whole way the storage of index data is managed is completely different. The recommended solution to addressing these sort of issues is to switch over to elasticsearch in Sakai 10. These types of issues is the whole reason search was re-implemented.

John Bush
added a comment - 30-Jan-2014 10:17 - edited This will not be an issue with the elasticsearch impl the whole way the storage of index data is managed is completely different. The recommended solution to addressing these sort of issues is to switch over to elasticsearch in Sakai 10. These types of issues is the whole reason search was re-implemented.

Is elasticsearch the default in trunk? How is it being activated/switched from the lucene search? It looks like the parallelIndexComponents.xml and the optimizer in that are still active and I'm still seeing this error running of recent trunk build. Do you have any examples of avoiding this, how to use SRCH-119 or why this would still be happening?

Matthew Jones
added a comment - 30-Jan-2014 10:32 Is elasticsearch the default in trunk? How is it being activated/switched from the lucene search? It looks like the parallelIndexComponents.xml and the optimizer in that are still active and I'm still seeing this error running of recent trunk build. Do you have any examples of avoiding this, how to use SRCH-119 or why this would still be happening?

I don't think elasticsearch is the default in trunk right now, we've gone back and forth on that. I think it should be the default, b/c while the solr option might be just as good (i have no experience with it) it does require another server be setup. To enable elasticsearch as the default the following should be set:

John Bush
added a comment - 30-Jan-2014 10:57 I don't think elasticsearch is the default in trunk right now, we've gone back and forth on that. I think it should be the default, b/c while the solr option might be just as good (i have no experience with it) it does require another server be setup. To enable elasticsearch as the default the following should be set:
search.enable=true
elasticsearch.http.enabled=true
elasticsearch.http.port=9200
search.service.impl=org.sakaiproject.search.elasticsearch.ElasticSearchService
search.indexbuilder.impl=org.sakaiproject.search.elasticsearch.ElasticSearchIndexBuilder

Elasticsearch is what's in there out of the box, certainly lucene shouldn't be the default for 10 and SOLR requires some configuration that doesn't exist. Thanks for the info. I can create a new jira to make ElasticSearchService the default too..

Matthew Jones
added a comment - 30-Jan-2014 11:06 Elasticsearch is what's in there out of the box, certainly lucene shouldn't be the default for 10 and SOLR requires some configuration that doesn't exist. Thanks for the info. I can create a new jira to make ElasticSearchService the default too..