Comment résoudre le problème de la temporisation lors de l’utilisation de Solr?

J’ai deux cœurs pour notre système Solr (Solr version 3.6.1). Lorsque j’appelle la ligne de commande suivante sur notre serveur Solr dédié pour append puis indexer un fichier:

java -Durl=http://solrprod:8080/solr/original/update -jar /home/solr/solr3/biomina/solr/post.jar /home/solr/tmp/2008/c2m-dump-01.noDEID_clean.xml 

Je reçois une exception dans le fichier /usr/share/tomcat7/logs/solr.2013-12-11.log (après environ 6 minutes d’attente):

 SEVERE: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/home/solr/solr3/biomina/solr/original/data/index/write.lock 

(Vous pouvez voir le résultat détaillé à la fin de ce message).

J’ai essayé de modifier le délai d’expiration des verrous (en définissant writeLockTimeout sur 300000 ), mais cela n’a pas résolu le problème. Je n’utilise aucun script personnalisé, juste le post.jar fourni avec Solr 3.1.6, pour append et indexer.

Des idées sur ce qui doit être changé pour se débarrasser de cette erreur et append avec succès le fichier XML sur Solr et l’indexer?

Contenu de /home/solr/solr3/biomina/solr/solr.xml :

           

Partie pertinente de solrconfig.xml (pour le kernel nommé original ):

   <!-- 10000 -->  300000 

Partie pertinente de solrconfig.xml (pour le kernel nommé deidentified ):

   <!-- 10000 -->  300000 

Sortie détaillée de l’exception

 Dec 11, 2013 11:27:25 AM org.apache.solr.core.SolrCore execute INFO: [original] webapp=/solr path=/update params={} status=500 QTime=300070 Dec 11, 2013 11:32:25 AM org.apache.solr.common.SolrException log SEVERE: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/home/solr/solr3/biomina/solr/original/data/index/write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1098) at org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:84) at org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:101) at org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:171) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:219) at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61) at org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:115) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:157) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) at java.lang.Thread.run(Thread.java:804) Dec 11, 2013 11:32:25 AM org.apache.solr.core.SolrCore execute INFO: [original] webapp=/solr path=/update params={} status=500 QTime=556916 

Détails du système:

 uname -a Linux solrprod 3.0.93-0.8-default #1 SMP Tue Aug 27 08:44:18 UTC 2013 (70ed288) x86_64 x86_64 x86_64 GNU/Linux java -version java version "1.7.0" Java(TM) SE Runtime Environment (build pxa6470sr6-20131015_01(SR6)) IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References 20131013_170512 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR6_20131013_1510_B170512 JIT - r11.b05_20131003_47443 GC - R26_Java726_SR6_20131013_1510_B170512_CMPRSS J9CL - 20131013_170512) JCL - 20131011_01 based on Oracle 7u45-b18 

Les modifications suivantes ont résolu le problème:

  • Appliqué les modifications décrites à l’ adresse https://stackoverflow.com/a/3035916/236007

  • Passé au runtime Oracle Java (c’était le runtime IBM Java ).

  • Mettez le ulimit -v unlimited dans /etc/init.d/tomcat7 .

  • Modification du fichier /usr/share/tomcat7/bin/setenv.sh sous la forme suivante (environ 4 Go de mémoire):

  • export JAVA_OPTS="$JAVA_OPTS -Xmx4000m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/data/tomcat_dump"

Vous avez des problèmes avec Lock obtain timed out write.lock d’ write.lock pour le fichier write.lock . Il s’est produit après une réinitialisation assez dure et il s’est avéré que, après le redémarrage, deux processus étaient en cours d’exécution depuis que le premier avait été détruit de manière disgracieuse auparavant.

En cours d’exécution ps aux | grep solr ps aux | grep solr et tuer le processus corrompu et laisser l’autre démarrer puis résolu le problème.

J’ai eu ces erreurs pour l’utilisation générale de la bibliothèque Lucene et le problème était des erreurs du système de fichiers, c’est-à-dire que l’erreur reproductible avait disparu après la réparation de fsck . J’ajoute cette réponse à cette question, car j’ai trouvé cette question en premier.