2010-05-24 6 views
10

Je travaille sur Solr dans mon application. J'utilise apache-solr-solrj-1.4.0.jar.SolrException: erreur interne du serveur

Quand je tente d'appeler add(SolrInputDocument doc) de CommonsHttpSolrServer, je reçois l'exception suivante:

org.apache.solr.common.SolrException: Erreur interne du serveur Erreur interne du serveur à org.apache.solr .client.solrj.impl.CommonsHttpSolrServer.request (CommonsHttpSolrServer.java:424) à org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request (CommonsHttpSolrServer.java:243) à org.apache.solr.client .solrj.request.AbstractUpdateRequest.process (AbstractUpdateRequest.java:105) sur org.apache.solr.client.solr j.SolrServer.add (SolrServer.java:64)

Quelqu'un peut-il m'aider s'il vous plaît à résoudre ce problème?

Voici les attributs solrconfig.xml:

<lockType>native</lockType> 
<unlockOnStartup>false</unlockOnStartup> 
<reopenReaders>true</reopenReaders> 

Je reçois l'exception suivante dans les journaux du serveur Solr:

24 mai 2010 2: 51:22 org.apache.solr.common.SolrException log SEVERE: java.lang.NullPointerException sur org.apache.solr.handler.ReplicationHandler $ 4.p ostCommit (ReplicationHandler.java:922) à org.apache.solr.update.UpdateHandler.callPostCommitCallbacks (UpdateHandler.java:78) à org.apache.solr.update.DirectUpdateHandler2.commit (DirectUpdateHandler2.java:411) à org.apache.solr.update.processor.RunUpdateProcessor.processCommit (RunUpdateProcessorFactory.java:85) à org.apache.solr.handler.RequestHandlerUtils.handleCommit (RequestHandlerUtils.java:107) à org.apache.solr.handler. ContentStreamHandlerBase.handleRequestBody (ContentStreamHandlerBase.java:48) à org.apache.solr.handler.RequestHandlerBase.handleRequest (RequestHandlerBase.java:131) à org.apache.solr.core.SolrCore.execute (SolrCore.java:1316) sur org.apache.solr.servlet.SolrDispatchFilter.execute (SolrDispatchFil ter.java:338) à org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:241) à org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:235) à org. apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) à org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:233) à org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) à org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:128) à org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:102) à org. apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) à org.apache.catalina.ha.session.JvmRouteBinderValve.invoke (JvmRouteBinderValve.java:210) à org.apache.catalina.ha.tcp.ReplicationValve.invoke (ReplicationValve.java:347) à org.apache. catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:293) à org.apache.jk.server.JkCoyoteHandler.invoke (JkCoyoteHandler.java: 190) à org.apache.jk.common.HandlerRequest.invoke (HandlerRequest.java:291) à org.apache.jk.common.ChannelSocket.invoke (ChannelSocket.java:769) à org.apache. jk.common.ChannelSocket.processConnection (ChannelSocket.java:698) à org.apache.jk.common.ChannelSocket $ SocketConnection.runIt (ChannelSocket.java:891) à org.apache.tomcat.util.threads.ThreadPool $ ControlRunnable.run (ThreadPool.java:690) à java.lang.Thread.run (Thread.java:619)


INFO: {} 0 1039 24 Mai, 2010 2:52:29 AM org.apache.solr.common.SolrException log SEVERE: org.apache.lucene.store.LockObtainFailedException: Verrouillage obtenir expiré: NativeFSLock @./Solr/data/index/lucene -be18de26b941317e71dc59f9e5ba63c4-write.lock à org.apache.lucene.store.Lock.obtain (Lock.java:85) à org.apache.lucene.index.IndexWriter.init (IndexWriter.java:1545) à org. apache.lucene.index.IndexWriter. (IndexWriter.java:1402) à org.apache.solr.update.SolrIndexWriter. (SolrIndexWriter.java:190) à org.apache.solr.update.UpdateHandler.createMainIndexWriter (UpdateHandler. java: 98) à org.apache.solr.update.DirectUpdateHandler2.openWriter (DirectUpdateHandler2.java:173) à org.apache.solr.update.DirectUpdateHandler2.add Doc (DirectUpdateHandler2.java:220) à org.apache.solr.update.processor.RunUpdateProcessor.processAdd (RunUpdateProcessorFactory.java:61) à org.apache.solr.handler.XMLLoader.processUpdate (XMLLoader.java:139) à org.apache.solr.handler.XMLLoader.load (XMLLoader.java:69) à org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody (ContentStreamHandlerBase.java:54) à org.apache.solr.handler. RequestHandlerBase.handleRequest (RequestHandlerBase.java:131) à org.apache.solr.core.SolrCore.execute (SolrCore.java:1316) à org.apache.solr.servlet.SolrDispatchFilter.execute (SolrDispatchFilter.java:338) sur org.apache.solr.servlet.SolrDispatchFilter.doFilter (SolrDispatchFilter.java:241) à ou g.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:235) à org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) à org.apache.catalina.core.StandardWrapperValve. invoquer (StandardWrapperValve.java:233) à org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) à org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:128) à org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:102) à org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) à org.apache.catalina.ha.session. JvmRouteBinderValve.invoke (JvmRouteBinderValve.java:210) at org.apache.catalina.ha.t cp.ReplicationValve.invoke (ReplicationValve.java:347) à org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:293) à org.apache.jk.server.JkCoyoteHandler.invoke (JkCoyoteHandler.java: 190) à org.apache.jk.common.HandlerRequest.invoke (HandlerRequest.java:291) à org.apache.jk.common.ChannelSocket.invoke (ChannelSocket.java:769) à org.apache.jk. common.ChannelSocket.processConnection (ChannelSocket.java:698) à org.apache.jk.common.ChannelSocket $ SocketConnection.runIt (ChannelSocket.java:891) à org.apache.tomcat.util.threads.ThreadPool $ ControlRunnable. run (ThreadPool.java:690) at java.lang.Thread.run (Thread.java: 619)

Répondre

1

Je suis très sûr, mais dans ce fil

http://www.mail-archive.com/[email protected]/msg08048.html

ils recommandent d'utiliser

<unlockOnStartup>true</unlockOnStartup> 

et

<lockType>simple</lockType> 

Je pense que cela devrait être en sécurité aussi longtemps que vous accédez à l'index via solr ou solrj (pas si lucene!).

D'autres idées?

+0

Où cette true et simples doivent être ajoutés pour le démarrage du printemps? –

0

Le client SolrJ ne vous donne pas l'erreur réelle. Essayez de regarder les logs du serveur solr qui devraient être situés sous tomcat ou jetty (ou quoi que ce soit exécute solr).

5

J'ai défini le suivant dans mon fichier solrconfig.xml et cela fonctionne.

<lockType>simple</lockType> 
<unlockOnStartup>true</unlockOnStartup> 

également, mis ci-dessous pour éviter les exceptions de verrouillage d'écriture sur le répertoire d'index:

<maxFieldLength>10000</maxFieldLength> 
<writeLockTimeout>60000</writeLockTimeout> 
<commitLockTimeout>60000</commitLockTimeout> 
+0

Bien que cela semble être vrai, '' '' unlockOnStartup''' semble supposer que vous ne verrouillez pas et définir les délais ne devrait avoir aucun effet du tout. Au moins basé sur la documentation dans le solrconfig.xml – brutuscat

+0

https://cwiki.apache.org/confluence/display/solr/IndexConfig+in+SolrConfig: Le paramètre maxFieldLength a été supprimé dans Solr 4. Si la restriction de la longueur des champs est important pour vous, vous pouvez obtenir un comportement similaire avec LimitTokenCountFactory, qui peut être défini pour les champs que vous souhaitez limiter. Par exemple, limiterait le champ à 10 000 caractères. [/ Code] –

0

Sonne comme un index corrompu ou un fichier de verrouillage occupé .. J'ai eu quelque chose de semblable et remise en marche travaillé, assez curieusement.

0

Il vient de ne pas supprimer le fichier write.lock après certaines actions de mise à jour. Supprimer le write.lock dans le dossier data/index du core résoudra ce problème temporairement et reprendra l'action de mise à jour. Je sais que l'utilisation de post.jar pour mettre à jour a plus de malchance à provoquer ce problème, alors que l'URL avec stream.body cause rarement ce problème. La réponse de Karussel a amélioré la situation mais ne semble pas la résoudre du tout. Je doute qu'il provienne d'un problème de conception de Solr. Hope Solr 4 a résolu ce problème. En outre, on peut se référer à la réponse à cette question: how-to-solve-the-lock-obtain-timed-out-when-using-solr-plainly

Questions connexes