2010-05-24 11 views
10

Estoy trabajando en Solr en mi aplicación. Estoy usando apache-solr-solrj-1.4.0.jar.SolrException: Error interno del servidor

Cuando intento llamar add(SolrInputDocument doc) de CommonsHttpSolrServer, me estoy haciendo la siguiente excepción:

org.apache.solr.common.SolrException: Error interno del servidor Error interno del servidor en org.apache.solr .client.solrj.impl.CommonsHttpSolrServer.request (CommonsHttpSolrServer.java:424) en org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request (CommonsHttpSolrServer.java:243) en org.apache.solr.client .solrj.request.AbstractUpdateRequest.process (AbstractUpdateRequest.java:105) en org.apache.solr.client.solr j.SolrServer.add (SolrServer.java:64)

¿Alguien me puede ayudar a resolver este problema?

Los siguientes son los atributos en solrconfig.xml:

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

estoy recibiendo el siguiente excepción en los registros del servidor Solr:

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


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

Respuesta

1

estoy muy seguro, pero en este hilo

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

que recomiendan usar

<unlockOnStartup>true</unlockOnStartup> 

y

<lockType>simple</lockType> 

creo que esto debería ser seguro, siempre y cuando accede al índice a través de solr o solrj (¡aunque no lucene!).

¿Alguna otra idea?

+0

dónde viene esta true y sencilla tienen que ser añadidos para el inicio en la primavera? –

0

El cliente SolrJ no le proporciona el error real. Intente mirar los registros del servidor Solr que deben ubicarse debajo de Tomcat o Jetty (o lo que sea que ejecute Solr).

5

He establecido el siguiente en mi solrconfig.xml y funciona.

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

Además, establecer excepciones siguientes para evitar bloqueo de escritura en el directorio de índice:

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

Aunque esto parece ser cierto, '' 'unlockOnStartup''' parece asumir que no está bloqueando y establecer los tiempos de espera no debería tener ningún efecto. Al menos según la documentación en el archivo solrconfig.xml – brutuscat

+0

https://cwiki.apache.org/confluence/display/solr/IndexConfig+in+SolrConfig: El parámetro maxFieldLength se eliminó en Solr 4. Si restringir la longitud de los campos es importante para usted, puede obtener un comportamiento similar con LimitTokenCountFactory, que se puede definir para los campos que le gustaría limitar. Por ejemplo, limitaría el campo a 10.000 caracteres. [/ Code] –

0

Suena como un índice dañado o archivo de bloqueo ocupada .. tuve algo similar y el reinicio trabajado, por extraño que parezca.

0

Viene de no poder eliminar el archivo write.lock después de algunas acciones de actualización. La eliminación del write.lock en la carpeta de datos/índice del núcleo resolverá este problema temporalmente y recuperará la acción de actualización. Sé que usar post.jar para actualizar tiene más mala suerte para causar este problema, mientras que la URL con stream.body rara vez causa este problema. La respuesta de Karussel mejoró la situación, pero parece que no la resuelve en absoluto. Dudo que provenga de algún problema de diseño de Solr. Hope Solr 4 ha resuelto este problema. También se puede hacer referencia a la respuesta en esta pregunta: how-to-solve-the-lock-obtain-timed-out-when-using-solr-plainly

Cuestiones relacionadas