Open Source Document Management System | OpenKM

PostPosted:**Sun Apr 24, 2016 11:18 pm**

Hola

Tengo instalado OpenKm 6.3.1 sobre un Centos 6.7 de 64 bits junto con un MySQL 5.6.23, actualmente tenemos

SELECT COUNT(*) FROM OKM_NODE_BASE;
317515

Aproximadamente entre 30 a 40 usuarios concurrentes realizando operaciones de escritura y lectura, en información tenemos alrededor de 300GB y hemos asignado la siguiente configuración de memoria

Code: Select all

JAVA_OPTS="-Xms4096m -Xmx7168m -XX:PermSize=512m -XX:MaxPermSize=1024m -Djava.awt.headless=true -Dfile.encoding=utf-8"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC -Dlog4j.configuration=file://$CATALINA_HOME/conf/log4j.properties"

El programa funcionaba sin problema alguno hasta hace unas semanas comenzó a mostrar el siguiente error ante operaciones de escritura sobre el sistema.

Code: Select all

2016-04-22 18:20:12,567 [Hibernate Search: Directory writer-1] ERROR org.hibernate.search.backend.impl.lucene.PerDPQueueProcessor - Unexpected error in Lucene Backend:
org.hibernate.search.SearchException: Unable to optimize directoryProvider: org.apache.lucene.store.NIOFSDirectory@/usr/local/credifam/openkm3/openkm625p3/tomcat-openkm3/repository/index/com.openkm.dao.bean.NodeBase lockFactory=org.apache.lucene.store.SimpleFSLockFactory@7b31ae25
        at org.hibernate.search.store.optimization.IncrementalOptimizerStrategy.optimize(IncrementalOptimizerStrategy.java:84)
        at org.hibernate.search.backend.Workspace.optimizerPhase(Workspace.java:134)
        at org.hibernate.search.backend.impl.lucene.PerDPQueueProcessor.performOptimizations(PerDPQueueProcessor.java:139)
        at org.hibernate.search.backend.impl.lucene.PerDPQueueProcessor.run(PerDPQueueProcessor.java:110)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: background merge hit exception: _f0ce(3.1):C293763/23 _h4zd(3.1):C135682/5 _h4zf(3.1):c1 _h4zh(3.1):c1 _h4zj(3.1):c1 _h4zl(3.1):c1 _h4zn(3.1):c1 _h4zp(3.1):c1/1 _h4zr(3.1):c1 _h4zt(3.1):c1 into _h4zu [optimize]
        at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:2413)
        at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:2352)
        at org.apache.lucene.index.IndexWriter.optimize(IndexWriter.java:2322)
        at org.hibernate.search.store.optimization.IncrementalOptimizerStrategy.optimize(IncrementalOptimizerStrategy.java:81)
        ... 8 more
Caused by: org.apache.lucene.index.CorruptIndexException: docs out of order (123111 <= 123111 )
        at org.apache.lucene.index.FormatPostingsDocsWriter.addDoc(FormatPostingsDocsWriter.java:74)
        at org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:587)
        at org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.java:528)
        at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:463)
        at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:111)
        at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3938)
2016-04-22 18:20:21,718 [Lucene Merge Thread #0] ERROR org.hibernate.search.exception.impl.LogErrorHandler - Exception occurred org.apache.lucene.index.MergePolicy$MergeException: org.apache.lucene.index.CorruptIndexException: docs out of order (123111 <= 123111 )
        at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:517)
        at org.hibernate.search.backend.impl.lucene.overrides.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:49)
        at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:482)
Caused by: org.apache.lucene.index.CorruptIndexException: docs out of order (123111 <= 123111 )
        at org.apache.lucene.index.FormatPostingsDocsWriter.addDoc(FormatPostingsDocsWriter.java:74)
        at org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:587)
        at org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.java:528)
        at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:463)
        at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:111)
        at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3938)

En este punto hemos intentado reconstruir indicies, actualizar de versión la OpenKM (a la actual que es la 6.3.1) pero sin lograr encontrar solución al problema y en los foros y búsquedas no hemos logrado encontrar algo relacionado con el mismo.

No obstante, aún con el error el sistema si deja cargar la información , sin embargo, luego de 2 a 3 horas la openKm se bloquea y va poniendo lenta, hasta bloquer las acciones de los usuarios, para lo cual se debe reiniciar.

Queremos saber si el error se debe a que ya el repositorio es muy grande o es como tal un bug de la aplicación, o en su defecto lo mejor es implementar una solución como la que planteaste en viewtopic.php?f=14&t=19667 , utilizando HaProxy, GlusterFS y MySQL para poder distribuir la carga y usuarios a entornos más pequeños para no afectar el desempeño de la OpenKM

PostPosted:**Mon Apr 25, 2016 7:58 am**

El problema - probablemente - es que se te ha corrompido el lucene, esta parte parece bastante clara. Razones ? puede haber varias, lo mas normal es una parada del equipo que se haya realizado incorrectamente. Aquí la solución es;
- para la aplicación
- eliminar la carpeta /index del repository
- ir a la administracion / tools / rebuild indexes -> rebuild lucene index ( esto va a tardar una cuantas horas en terminarse de ejecutar, durante este tiempo es mejor que no utiliceis la aplicación ).

300K ficheros es un repositorio mediano ( de hecho el mediado lo consideramos a partir de los 500K ), nosotros lo empezamos a consider grande a partir del millón.

PostPosted:**Tue Apr 26, 2016 5:24 pm**

Buenas

Realizamos la operación indicada de borrar los índices y reconstruirlos; y efectivamente logró solucionar los mensajes de error relacionados con el indice que continuamente salían en la aplicación. Por otro lado, nos gustaría saber si es viable la solución que comente sobre el uso de HaProxy, GlusterFS y Mysql, para tener un sistema con 3 nodos de acceso, un repositorio compartido con gluster FS y una única base de datos, estos con el fin de poder segmentar los usuarios que ingresan a la aplicación y que las tareas de carga de información de alguno no afecten las tareas de lecturas de los otros.

PostPosted:**Fri Apr 29, 2016 9:13 pm**

Es factible, pero no con la versión community. No viene preparada para esta configuración. Esto ahora mismo solo esta disponible en la profesional.

Open Source Document Management System | OpenKM

docs out of order

docs out of order

Re: docs out of order

Re: docs out of order

Re: docs out of order