D’Apache Archiva à Sonatype Nexus – Conclusion

Dernière partie consacrée à la migration d’Archiva vers Nexus avec le bilan.

Tout d’abord revenons sur les problèmes que nous avions avec Archiva et qui nous ont poussés à tenter l’aventure Nexus.

Le nombre de descripteurs de fichiers ouverts par le produit

Il est encore un peu tôt pour crier victoire cependant après plus de deux semaines d’exploitation nous pouvons constater que notre problème sur le nombre de descripteurs de fichiers ouverts simultanément a disparu.Là où Archiva dépassait facilement les 1024 descripteurs ouverts, Nexus se contente d’environ 400 ce qui soulage énormément la machine.

Nombre de "file descriptors" ouverts par Archiva
Nombre de 'file descriptors' ouverts par Archiva
Nombre de "file descriptors" ouverts par Nexus
Nombre de 'file descriptors' ouverts par Nexus

La consommation mémoire

Même si cela n’était pas très grave puisque nous avions les ressources nécessaire Archiva était très consommateur de mémoire. Il en prennait en moyenne 1,3Go. Nexus est beaucoup moins gourmand et tourne avec moins de 400Mo (Même mon eclipse consomme plus 🙂 ).

Mémoire consommée par Archiva
Mémoire consommée par Archiva
Mémoire consommée par Nexus
Mémoire consommée par Nexus

Les problèmes de snapshots non trouvés

Malheureusement à ce niveau là, le problème perdure. Mais le fait que le changement de serveur ne résolve pas le problème nous avons investigué un peu plus.
Nous avons découvert aujourd’hui deux causes plus précises du problème :

  • La première est un bug Maven (MNG-4142) qui est un subtil problème à moitié chemin entre l’utilisation d’artifacts avec des classifiers et une corruption des metadonnées du repository local.
  • La seconde cause est liée à des bugs NEXUS (NEXUS-1333, NEXUS-2036) qui font que le processus de correction des metadonnées les supprime dans un répertoire si il n’arrive pas à comprendre un POM. Cas qui semble arriver fréquemment en utilisant par exemple des propriétés maven “deprecated” comme ${parent.*} (à remplacer par ${project.parent.*}) ou ${pom.*} (à remplacer par ${project.*}).

A ces problèmes vient s’en greffer un nouveau spécifique à Nexus.

Les cookies rejetés

Un problème est apparu avec Nexus. Nous avons un soucis avec les règles de réécriture qui font que Maven se plaint lorsqu’il fait un déploiement que les cookies sont rejetés (NEXUS-1967). Ca n’est pas grave, mais cela crée du bruit dans les logs Maven ce qui ne facilite pas le diagnostic des erreurs.

Mais au final le jeu en valait bien la chandelle !!

La cerise sur le gâteau

Au final toutes les économies de ressources sur le serveur mais aussi la meilleure qualité de Nexus sur la rapidité de l’upload des artifacts (quelque soit leur taille) font que le serveur d’intégration continue est beaucoup plus stable et beaucoup plus régulier. Comme on peut le voir sur les quelques graphiques ci-dessous tirés de différents builds sur Bamboo il y a une nette fracture lors de la mise en production de Nexus. On note une régularité sans commune mesure sur les temps des builds et surtout une grande diminution de ceux-ci.

chart4chart3

chart2chart1

Conclusion

Avons-nous trouvé la silver bullet ? Bien sur que non. J’ai déjà listé quelques contraintes ou problèmes rencontrés et il y en a d’autres à découvrir. Tout produit est perfectible. Malgré cela comment dire autre chose que …. migrez !!! C’est malheureux pour moi de l’avouer en tant que membre de l’équipe Archiva mais je dois me ranger aux résultats. Ils sont édifiants. Nexus est un produit de qualité qui rend très bien le service qu’on lui demande. De plus, développé par des personnes à temps plein (merci Sonatype), il bénéficie d’un support réactif et facilement accessible (je vous conseille le channel #nexus sur irc.codehaus.org). Archiva, lui, régit par les lois de l’open-source, doit se contenter du maigre temps libre de ses committeurs ce qui ne suffit plus pour rester dans la compétition.
Alors, faites-vous plaisir et profitez d’un service à la hauteur de vos demandes, adoptez Nexus !

4 thoughts on “D’Apache Archiva à Sonatype Nexus – Conclusion”

  1. Une chose qui serait à ajouter à la version OSS de Nexus serait le support d’authentification Ldap et notamment AD.

    J’avais bosse dessus et il va falloir que je m’y remette car la crise aidant pas moyen pour l’instant de passer à la version pro 🙁

    Le constat de Nexus est surtout qu’en OpenSource comme ailleurs, sans full time developpeurs et donc adosse à une activité commerciale (par exemple éditeur ou intégrateur), les produits n’avancent pas ou plus assez et perdent des supporters et utilisateurs.

  2. C’est évident. Il est impossible de répondre aux exigences des entreprises sans moyens dédiés. C’est pour cela que l’OSS professionnel fonctionne de mieux en mieux. Ce ne sont finalement que des éditeurs “classiques” qui ont la particularité de laisser leurs sources disponibles (au cas où quelqu’un voudrait s’y intéresser). Ces acteurs fournissent l’essentiel de la contribution à leurs produits.
    La communauté n’est plus réellement portée sur le développement mais sur l’utilisation. Là où avec les éditeurs “classiques” nous avions un système en étoile où chaque utilisateur “client” n’interagissait qu’avec l’éditeur, chez un éditeur “oss” nous avons une communauté d’utilisateurs qui partagent leurs expériences.

Comments are closed.