Java Application Cuelgue en Linux en "java.io.UnixFileSystem.getBooleanAttributes0"

Nuestra aplicación de los clientes parece que se cuelga con el seguimiento de pila:Java Application Cuelgue en Linux en "java.io.UnixFileSystem.getBooleanAttributes0"

java.lang.Thread.State: RUNNABLE 
    at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) 
    at java.io.UnixFileSystem.getBooleanAttributes(Unknown Source) 
    at java.io.File.isFile(Unknown Source) 
    at org.tmatesoft.svn.core.internal.wc.SVNFileType.getType(SVNFileType.java:118) 
    at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createUniqueFile(SVNFileUtil.java:299) 
    - locked <0x92ebb2a0> (a java.lang.Class for org.tmatesoft.svn.core.internal.wc.SVNFileUtil) 
    at org.tmatesoft.svn.core.internal.wc.SVNRemoteDiffEditor.createTempFile(SVNRemoteDiffEditor.java:415) 
    at org.tmatesoft.svn.core.internal.wc.SVNRemoteDiffEditor.applyTextDelta(SVNRemoteDiffEditor.java:255)

Alguien sabe lo que podría provocar que se cuelgue en isFile?

Fuente

2008-10-22 Anonymous

Ni idea, pero la pregunta obvia de las cuales JDK/JRE viene a la mente y lo que otros has ...

Fuente

2008-10-22 07:49:51

El cliente está utilizando Sun's JRE 1.6.0.07. Todavía no he probado otros. Encontré [http://www.ruby-forum.com/topic/165608] y [http://www.jetbrains.net/jira/browse/IDEADEV-23062] informando algo similar, pero sin soluciones. –

Tal vez el repositorio SVN de alguna manera está bloqueado Todo lo que puedo hacer es adivinar.

¿La aplicación accede a un repositorio de subversión?

Podría estar esperando a que el repositorio no se vuelva a bloquear, quién sabe si es su aplicación.

Fuente

2008-10-22 07:51:10

Del rastro de la pila anterior, parece que el código tmatesoft está intentando crear un archivo temporal. Este no es nuestro código, sino el cliente java svn que usamos para hablar con svn. –

getBooleanAttributes0 llamadas stat (o stat64, si está disponible). Si tiene el código fuente OpenJDK, esto se encuentra en el archivo jdk/src/solaris/native/java/io/UnixFileSystem_md.c.

Entonces, la verdadera pregunta es, ¿por qué se congela stat? ¿El archivo al que se accede es un archivo de red en un servidor inactivo, por ejemplo? Si este es un problema reproducible, puede usar strace para adjuntarlo al proceso de Java, justo antes de la congelación. Luego, busque en la salida las llamadas al stat, para ver a qué se accede.

Fuente

2008-10-22 08:18:19

obtengo esto sin montajes nfs ... probablemente malos bloques de disco grrrr –

Parece que la llamada stat que resulta de getBooleanAttributes0 está bloqueando. Esto normalmente ocurre porque el archivo está ubicado en un recurso compartido de NFS que está inactivo.

Fuente

2008-10-22 08:25:56 staffan

Hemos visto esto bajo mucha carga en los sistemas de archivos NFS. – ReneS

Vemos este problema en Eclipse cuando registra un archivo inexistente en un directorio automount de NFS.

Si dirige su proceso de Java con -f -t -T (siga las horquillas y la hora) lo que vemos es que más las estadísticas regresan en un tiempo muy corto. Los del directorio automount toman dos órdenes de magnitud más.

En muchos casos, el sistema operativo toma esto como una oportunidad para cambiar el contexto del hilo. El resultado es que el hilo que realiza la estadística no se ejecuta durante mucho tiempo. Si su código Java (un plugin de Eclipse en nuestro caso) está configurando inequívocamente el árbol de forma recursiva para cada archivo, puede terminar bloqueando ese hilo durante mucho tiempo.

La solución es evitar que su Java haga eso.

Fuente

2010-05-07 09:31:40

Java Application Cuelgue en Linux en "java.io.UnixFileSystem.getBooleanAttributes0"

Respuesta

Cuestiones relacionadas