SpringSource dm Server échoue occastionally pour décompresser valide fichier ZIP

Question

Lors du déploiement de mon projet à SpringSource dm Server, chaque fois dans un certain temps un JAR ne parvient pas à déployer avec le message suivant:

/mnt/myproject/springsource/work/com.springsource.server.deployer/packed/my.project.0.1.10.M.jar' cannot be unpacked. 

java.util.zip.ZipException: error in opening zip file 

Il y a 5 fichiers .war dans le projet. Si l'un d'eux échoue, c'est toujours le même (qui est aussi le dernier à être copié dans le répertoire de ramassage). Cependant, généralement tous les 5 vont se déployer sans problèmes. Il s'agit exactement du même ensemble de fichiers dans toutes les instances, provenant d'un référentiel maven, qui vient d'être déployé sur de nouvelles instances de serveur.

Le fichier qui échoue peut être ouvert correctement par 7-Zip. Si j'arrête Spring, efface le répertoire de collecte, démarre Spring et copie les fichiers .war à nouveau, cela fonctionnera normalement.

Le processus de déploiement habituel est:

• Début printemps
• Attendez jusqu'à Ouvrir les rapports pour les affaires avec le profil « web »
• Copie tous les 5 projets avec un délai de 2 secondes entre chaque copie (scriptées).

Des problèmes similaires java-util-zip-zipexception-error-in-opening-zip-file et jboss5-cannot-deploy-due-to-java-util-zip-zipexception-error-in-opening-zip-fil ne semblent pas s'appliquer.

Answer 1

Vous ne dites pas quelle version de dm Server vous utilisez, donc je vous recommande de passer à la version 2.0.x pour récupérer les correctifs si ce n'est déjà fait. Vous pouvez également effectuer une mise à niveau vers Eclipse Virgo, qui est la suite du projet dm Server. Je suppose que l'heuristique dans dm Server pour déterminer quand une copie de fichier dans le ramassage est terminée est lue, peut-être en raison d'une opération de copie lente ou irratique. Y at-il quelque chose d'inhabituel sur votre disque, tel que le cryptage ou le montage à distance, qui peut interférer avec l'opération de copie? Une façon d'exclure l'heuristique serait de placer les fichiers dans le répertoire de collecte lorsque dm Server n'est pas en cours d'exécution, puis de lancer dm Server lorsque l'opération de copie est définitivement terminée. Si le problème se reproduit, il se peut qu'il y ait un problème dans le JRE que vous utilisez.