Приложение Java зависает в Linux на "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)
Кто-нибудь знает, что могло привести к зависанию в isFile?
Ответы 5
Понятия не имею, но очевидный вопрос, какой JDK / JRE приходит на ум и какие другие вы пробовали ...
Возможно, репозиторий SVN каким-то образом заблокирован. Все, что я могу сделать, это предположить.
Имеет ли приложение доступ к репозиторию Subversion?
Возможно, он ждет, пока репозиторий не будет снова заблокирован, кто знает ваше приложение.
Из приведенной выше трассировки стека похоже, что код tmatesoft пытается создать временный файл. Это не наш код, а java-клиент svn, который мы используем для общения с svn.
getBooleanAttributes0 вызывает stat (или stat64, если таковой имеется). Если у вас есть исходный код OpenJDK, он указан в файле jdk/src/solaris/native/java/io/UnixFileSystem_md.c.
Итак, реальный вопрос: почему stat заморожен? Например, является ли файл, к которому осуществляется доступ, сетевым файлом на неработающем сервере? Если это воспроизводимая проблема, вы можете использовать strace для подключения к процессу Java непосредственно перед замораживанием. Затем посмотрите в выходных данных вызовы stat, чтобы узнать, к чему осуществляется доступ.
Я получаю это без монтирования nfs ... вероятно, плохие блоки диска grrrr
Похоже, вызов stat, вызванный getBooleanAttributes0, блокируется. Обычно это происходит из-за того, что файл находится на неработающем ресурсе NFS.
Мы видели это при большой нагрузке на файловые системы NFS.
Мы видим эту проблему в Eclipse, когда он регистрирует несуществующий файл в каталоге автоматического монтирования NFS.
Если вы ограничите свой java-процесс с помощью -f -t -T (отслеживание вилок и времени), мы увидим, что самый статистика возвращается за очень короткое время. Те, что находятся в каталоге automount, занимают на два порядка больше времени.
Во многих случаях ОС использует это как возможность переключить поток из контекста. В результате поток, выполняющий статистику, не работает очень долгое время. Если ваш Java-код (в нашем случае плагин Eclipse) неэффективно рекурсивно описывает дерево для каждого файла, вы можете заблокировать этот поток на долгое время.
Решение состоит в том, чтобы остановить это на Java.
Заказчик использует Sun JRE 1.6.0.07. Других я еще не пробовал. Я обнаружил, что [ruby-forum.com/topic/165608] и [jetbrains.net/jira/browse/IDEADEV-23062]] сообщают о чем-то похожем, но без каких-либо решений.