2009-06-04 9 views

Répondre

3

Je pense que vous trouverez la plupart des gens se disputeront sur Redhat sur Windows pour la fiabilité. Glassfish lui-même devrait fonctionner de la même manière.

Vous devriez probablement poser sur Server Fault

16

Si vous cochez la source GlassFish, plus précisément ./appserv-commons/src/java/com/sun/enterprise/util/io/FileUtils.java, vous aurez voir toutes les contorsions que vit Glassfish pour supprimer/renommer des fichiers et des répertoires sous Windows.

Ceci est un problème de Windows, avec ses restrictions sur la suppression et le changement de nom des fichiers ouverts.

Il ya toutes sortes de trucs là-dedans, y compris demander un GC de la JVM plusieurs fois dans l'espoir de fermer le flux de fichiers, "pseudo" renommer, sleep-try boucles.

Quelques exemples:

/** 
*Attempts to delete files that could not be deleted earlier and were not overwritten. 
*<p> 
*On Windows, the method requests garbage collection which may unlock locked 
*files. (The JarFile finalizer closes the file.) 

/* 
    *On Windows, as long as not all leftover files have been cleaned and we have not 
    *run the max. number of retries, try again to trigger gc and delete 
    *each remaining leftover file. 
    */ 

/** 
* Windows has BIG issues renaming a directory that is open somnewhere -- e.g. if 
* a DOS box is opened anywhere in that directory. 
* This method will try to do a "virtual renaming" if there are problems 
* I.e. it attempts to do a simple rename, if that fails it will copy everything under 
* the original directory to the renamed directory. Then it will delete everything 
* under the original directory that the OS will allow it to. 

En pratique, cela se traduit parfois foireuse déploiements ou redéploiements sous Windows, car certains fichiers ne peuvent pas être supprimés ou déplacés et finissent par se laisser distancer. Sur les quelque 50 instances de Glassfish que je cours, je n'ai jamais eu de problème avec Solaris 10 et j'ai toujours des problèmes avec Windows. En bref, tout * NIX sera mieux pour cette seule raison, d'autres considérations d'administration de la plate-forme mises à part.