Огромное количество JAR файлов в каталоге jboss/server/web/tmp/vfs-nested.tmp

Иногда у нас есть огромное количество JAR файлов в каталоге jboss/server/web/tmp/vfs-nested.tmp.
Например, сегодня этот каталог содержал более 350 тыс. Jar файлов.
Но на других хостах в этом каталоге есть только 2 файла jar.
Какова может быть основная причина этой проблемы?

Мы используем JBoss 5.1

UPDATE:
Я нашел следующую информацию в примечаниях к выпуску для JBoss 5.1.0.GA:

JBoss VFS предоставляет набор различных переключатели для управления им поведение. Комплекты JBoss AS jboss.vfs.forceCopy = true по умолчанию. Чтобы увидеть все предоставленные флаги VFS проверьте код Класс VFSUtils.java.

Итак, я не понимаю, что я должен установить?
Должен ли я установить -Djboss.vfs.forceNoCopy = true или -Djboss.vfs.forceCopy = false?
Или я должен установить оба из них?

ОБНОВЛЕНИЕ 1:
Я прочитал целую цепочку http://community.jboss.org/thread/2148?start=0&tstart=0 и теперь я не уверен, что я должен изменить либо jboss.vfs.forceCopy, либо jboss.vfs.forceNoCopy.
Согласно этой теме, у меня будет ошибка OutOfMemory вместо огромного количества файлов в tmp dir.

Ответ 1

Отсюда: http://sourceforge.net/project/shownotes.php?release_id=575410

"Избыточные файлы nestedjarNNN.tmp в каталоге tmp. VFS разворачивает вложенные банки, извлекая вложенную банку в tmp файл в каталоге java tmp. Это может привести к большому количеству файлов, которые заполняют каталог tmp. Вы можете отключить это поведение, установив -Djboss.vfs.forceNoCopy = true в командной строке, используемой для запуска jboss. Это будет включено по умолчанию в будущей версии JBAS-4389."

Ответ 2

jskaggz имеет хороший ответ. Кроме того, у меня есть это в начале моего файла run.bat:

rmdir /s /q c:\apps\jboss-5.1.0.ga\server\default\tmp
rmdir /s /q c:\apps\jboss-5.1.0.ga\server\default\work
rmdir /s /q c:\apps\jboss-5.1.0.ga\server\default\log
mkdir       c:\apps\jboss-5.1.0.ga\server\default\tmp
mkdir       c:\apps\jboss-5.1.0.ga\server\default\work
mkdir       c:\apps\jboss-5.1.0.ga\server\default\log
echo --- Cleared temp folders ---

У меня были проблемы со старыми копиями классов, которые висят вокруг, так что это помогает.

Ответ 3

У меня была такая же проблема, как описано выше, и разрешила ее с помощью следующего решения.

Добавлены опции java

    -Djboss.vfs.cache=org.jboss.virtual.plugins.cache.IterableTimedVFSCache
    -Djboss.vfs.cache.TimedPolicyCaching.lifetime=1440

Моя настройка также определяет дополнительные каталоги развертывания, поэтому мне нужно было добавить эти дополнительные каталоги в файл vfs.xml, расположенный в $JBOSS_SERVER_HOME/conf/bootstrap/, чтобы увидеть преимущество.

Время жизни, которое, как мне кажется, составляет несколько минут, поэтому я установил его на один день, так как у меня запланированный перезапуск сервера в одночасье.

До поиска этого решения я также попытался использовать -Djboss.vfs.forceNoCopy=true и -Djboss.vfs.forceCopy=false

Это работало, но я заметил, что приложение работает намного медленнее - по-видимому, потому что эти настройки отключают кэширование vfs.

Версия My Jboss - jboss-5.1.0.GA и мое приложение запускается в кластере при производстве.

Ответ 4

Мы решили эту проблему взорванным развертыванием (работает для войны и слуха), как описано в документации jboss http://docs.jboss.org/jbossas/docs/Administration_And_Configuration_Guide/5/html/ch03s01.html

Таким образом, vfs не используется.

Ответ 5

Обнаружено много других, имеющих ту же проблему, что и в кластерных (или фермерских) средах. https://issues.jboss.org/browse/JBAS-7126 описывает проблему, имеющую каталог фермы в качестве каталога развертывания.

У меня была такая же проблема с использованием второго каталога развертывания. Файлы jar из моих приложений, поступающих из этого второго каталога развертывания, были скопированы до тех пор, пока диск не будет заполнен.

Попробовал добавить второй каталог развертывания так же, как в https://issues.jboss.org/browse/JBAS-7126, описанный для каталога фермы.

Хорошо работает!

Ответ 6

Мы столкнулись с одной проблемой и смогли обойти проблему, используя каталог фермы в качестве каталога развертывания.

После установки этого процесса мы столкнулись с еще одной проблемой из-за характера нашей среды DEV (у нас есть кластерная среда, и у нас много разработчиков, развертывающих в общей среде DEV), чтобы не получать согласованные результаты во время развертывания EAR и WARs таким образом. Мы обошли проблему, убедившись, что EAR и JAR, которые развертываются, подключены (http://en.wikipedia.org/wiki/Touch_(Unix)) на на серверах, чтобы избежать несоответствий.