archivo de mi proceso de java descriptores va "mal" y no tengo ni idea de por qué

Question

Tengo una aplicación web Java, construido con Lucene, y me siguen dando varios "archivo ya cerrado" excepciones - en función de la aplicación Directorio utilizo. Pude obtener el "Descriptor de archivo incorrecto java.io.IOException" y "java.nio.channels.ClosedExpresion de canal" fuera de Lucene, por lo general envuelto alrededor de una Excepción AlreadyClosed para IndexReader.

Lo curioso es que no han cerrado la IndexReader y parece que los descriptores de fichero van rancio por su propia cuenta. Estoy usando la última versión de Lucene 3.0 (no he tenido tiempo para actualizarme de la serie 3.0), la última versión de JDK6 de Oracle, la última versión de Tomcat 6 y la última versión de CentOS. Puedo replicar el error con el mismo software en otros sistemas Linux, pero no en los sistemas Windows y no tengo una PC OSX para probar. Los servidores de Linux están virtualizados con qEmu, si eso pudiera importar.

Esto parece ser también relacionados con la carga - la frecuencia con la que esto sucede corresponde a la cantidad de solicitudes/segundo que Tomcat está sirviendo (a esta aplicación web en particular). Por ejemplo, en un servidor cada solicitud se completa como se espera hasta que tenga que ocuparse de ~ 2 reqs/seg, luego alrededor del 10% comienza a tener sus descriptores de archivo cerrados desde debajo de ellos, solicitud intermedia (el código busca un objeto IndexReader válido y crea uno al comienzo del procesamiento de la solicitud). Una vez que llega a aproximadamente 3 reqs/seg, todas las solicitudes comienzan a fallar con descripciones de archivos incorrectos.

Mi mejor suposición es que de alguna manera hay falta de recursos en un nivel de sistema operativo y el sistema operativo está limpiando fds ... pero eso es simplemente porque he eliminado todas las demás ideas que he tenido. Ya he comprobado los límites de ff del sistema de archivos y ulmits, y el número de descriptores abiertos está muy por debajo de cualquiera de los límites (ejemplo de salida de sysctl fs.file-nr: 1020 0 203404, ulimit -n: 10240).

estoy casi completamente fuera de cosas para probar y no estoy más cerca de resolver esto que el día que me enteré. Alguien ha experimentado algo similar?

EDITAR 07/12/2011: He encontrado una máquina OSX usar para algunas pruebas y han confirmado que esto sucede en OSX. También hice pruebas en cuadros físicos de Linux y repliqué el problema, por lo que el único sistema operativo con el que no he podido replicar este problema es Windows. Supongo que esto tiene algo que ver con el manejo de los descriptores de archivos de POSIX porque esa parece ser la única diferencia relevante entre los dos sistemas de prueba (la versión de JDK, la versión de tomcat y la de webapp eran idénticas en todas las plataformas).

Answer 1

la razón es probable que no presenta este fenómeno en Windows, podría ser que sus valores por defecto a utilizar FSDirectory.open SimpleFSDirectory.

la salida de las advertencias en la parte superior de FSDirectory y NIOFSDirectory: el texto en rojo en http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/store/NIOFSDirectory.html:

NOTA: El acceso a esta clase, ya sea directa o indirectamente de un hilo mientras está interrumpido puede cerrar el descriptor de fichero subyacente inmediatamente si al mismo tiempo, el hilo está bloqueado en IO. El descriptor de archivo permanecerá cerrado y el acceso posterior a NIOFSDirectory arrojará una ClosedChannelException. Si la aplicación utiliza ya sea Thread.interrupt() o Future.cancel (booleano) se debe utilizar SimpleFSDirectory a favor de NIOFSDirectory

https://issues.apache.org/jira/browse/LUCENE-2239