Énorme quantité de fichiers JAR dans jboss/server/web/tmp/vfs-imbriqués.répertoire tmp

Parfois, nous avons une grosse quantité de fichiers JAR dans jboss/server/web/tmp/vfs-imbriqués.tmp répertoire.
Par exemple, aujourd'hui ce répertoire comprend plus de 350 ko des fichiers jar.
Mais sur les autres serveurs, il y a seulement 2 jar fichiers dans ce répertoire.
Ce qui peut être la cause de ce problème?

Nous utilisons JBoss 5.1

Mise à JOUR:
J'ai trouvé les informations suivantes dans les notes de version de JBoss 5.1.0.GA:

JBoss VFS fournit un ensemble de différents
les commutateurs de contrôle interne
comportement. JBoss COMME jeux
jboss.vfs.forceCopy=true par défaut.
Pour voir tous les drapeaux VFS
découvrez le code de la
VFSUtils.la classe java.

Donc je ne comprends pas que dois-je mettre?
Dois-je mettre -Djboss.vfs.forceNoCopy=true ou -Djboss.vfs.forceCopy=false?
Ou dois-je mettre les deux d'entre eux?

Mise à JOUR 1:
J'ai lu tout le fil http://community.jboss.org/thread/2148?start=0&tstart=0
et maintenant, je ne suis pas shure que je devrais changer de jboss.vfs.forceCopy ou jboss.vfs.forceNoCopy.
Selon ce fil, je vais avoir OutOfMemory erreur au lieu de la quantité énorme de fichiers tmp dir.

Ont le même problème, donc je suis en train de mettre une prime sur cette question.
Avez-vous jamais obtenir une bonne réponse à cette question? Je vais avoir le même problème. Deux identiques(?) serveurs, un remplissage avec des fichiers tmp, les autres apparemment très bien. Et je crois que la création de ces fichiers à chaque minute est aussi pour effet de ralentir le serveur.
Nous sommes également à avoir ce problème, et, tandis que nous n'avons pas trouvé un moyen d'arrêter JBoss de la production de ces fichiers, nous avons constaté que nous pouvons supprimer les anciens fichiers de ce dossier alors que JBoss est en cours d'exécution, sans affecter l'application(s). La commande nous utilisons est " à trouver . -ctime +1 -exec rm {} \;" à partir de l'intérieur de la vfs-imbriqués.dossier tmp pour supprimer des fichiers de plus de 24 heures (YMMV). Nous sommes assez sûr que le problème est lié à l'utilisation de liens symboliques vers nos engins déployables, peut-être en association avec l'utilisation de l'Ornement à faire de nos déploiements. Voir JBoss forums de trop!
Concerne serverfault.com/questions/128458/...

OriginalL'auteur Volodymyr Bezuglyy | 2010-06-24

  1. 3

    À partir d'ici: http://sourceforge.net/project/shownotes.php?release_id=575410

    "Excessive nestedjarNNN.fichiers tmp dans le répertoire tmp. La VFS déballe imbriqués les bocaux par l'extraction de la imbriquée pot dans un fichier tmp dans le java répertoire tmp. Cela peut entraîner un grand nombre de fichiers qui remplissent le répertoire tmp. Vous pouvez désactiver ce comportement en définissant -Djboss.vfs.forceNoCopy=true sur la ligne de commande utilisée pour démarrer jboss. Ce sera activée par défaut dans une version future, JBAS-4389."

    Notre application fonctionne sur les différents hôtes et seulement sur 2, nous avons ce problème. Pourquoi n'avons-nous pas ce problème sur tous les hôtes?
    Veuillez voir le jour.
    Le problème ici est que forceNoCopy a documenté l'impact sur la consommation de mémoire et istead de l'espace disque, vous obtenez OutOfMemoryError

    OriginalL'auteur Jubal

  2. 1

    jskaggz a une bonne réponse. En outre, j'ai ceci dans le début de ma course.fichier 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 ---

    J'ai eu des problèmes avec les anciennes copies de classes traîner, donc cela semble aider.

    Notre application fonctionne sur les différents hôtes et seulement sur 2, nous avons ce problème. Pourquoi n'avons-nous pas ce problème sur tous les hôtes?
    Veuillez voir le jour.

    OriginalL'auteur Jon Onstott

  3. 1

    Nous avons résolu ce problème en explosé de déploiement ( travaux en faveur de la guerre et de l'oreille) comme décrit dans la documentation jboss http://docs.jboss.org/jbossas/docs/Administration_And_Configuration_Guide/5/html/ch03s01.html

    Qui vfs n'est pas utilisé.

    Nous avons résolu ce problème de la même manière.

    OriginalL'auteur ABKSystem

  4. 1

    J'ai eu le même problème décrit ci-dessus dans la production et résolu avec la solution suivante.

    Ajouté des options java

     -Djboss.vfs.cache=org.jboss.virtuels.les plugins.le cache.IterableTimedVFSCache 
-Djboss.vfs.le cache.TimedPolicyCaching.durée de vie=1440

    Ma configuration définit également de déploiement supplémentaires répertoires j'ai donc besoin d'ajouter ces autres répertoires vfs.xml fichier situé dans $JBOSS_SERVER_HOME/conf/bootstrap/ afin de voir les avantages.

    Le paramètre de durée de vie, je pense, en minutes, alors je l'ai mis à jour, car j'ai prévu de redémarrer le serveur pour la nuit.

    Avant de trouver cette solution, j'avais aussi essayé d'utiliser -Djboss.vfs.forceNoCopy=true et -Djboss.vfs.forceCopy=false

    Cela semblait fonctionner, mais j'ai remarqué que l'application couru beaucoup plus lent, sans doute parce que ces paramètres tourner vfs la mise en cache hors.

    Ma version de Jboss jboss-5.1.0.GA
    et mon application s'exécute dans un cluster sur la production.

    OriginalL'auteur Stuart James

  5. 0

    Trouvé beaucoup d'autres ayant le même problème dans le groupe (ou la batterie) les environnements.
    https://issues.jboss.org/browse/JBAS-7126 décrit pour résoudre le problème d'avoir une ferme répertoire comme répertoire de déploiement.

    J'ai eu le même problème à l'aide d'un 2e répertoire de déploiement.
    Les fichiers jar de mes demandes en provenance de cette 2e répertoire deploy ai copié jusqu'à ce que le disque était plein.

    Essayé d'ajouter le 2ème répertoire deploy la même façon qu'à https://issues.jboss.org/browse/JBAS-7126 décrit pour la batterie de serveurs d'annuaire.

    Il fonctionne bien!

    OriginalL'auteur Christian13467

  6. 0

    Nous avons été confrontés à la même question, et ont été en mesure de contourner le problème en utilisant une batterie de répertoire comme répertoire de déploiement.

    Après la mise en place, nous avons été confrontés à l'un plus, à cause de la nature de notre environnement de DEV ( Nous avons environnement en clusters et nous avons de nombreux développeurs déploiement de l'environnement de DEV ) de ne pas avoir une uniformité des résultats, alors que nous étions déployer les Oreilles et les Guerres de cette façon .Nous avons contourné le problème en faisant en sorte que les Oreilles et les Pots qui sont en cours de déploiement sont TOUCHÉ (http://en.wikipedia.org/wiki/Touch_(Unix) ) sur les serveurs pour s'assurer que les incohérences sont à éviter .

    OriginalL'auteur user811591