Pour nos besoins, nous ne sommes pas allés avec la référence de jar OSGI standard qui construit les jarres dans l'ensemble. Plutôt pour les mises à niveau en ligne, nous voulions être en mesure de fournir des jars nouveaux et mis à jour lors des mises à niveau. Dans notre classe Activator qui démarre et arrête un bundle, nous implémentons notre propre URLClassLoader, puis recherchons tous les jars dans un sous-dossier et fournissons à URLClassLoader avec le CLassLoader OSGI comme parent. C'est génial car maintenant les administrateurs de l'application peuvent simplement ajouter des jars à un chemin de classe et redémarrer l'application (redémarrage d'osgi, pas d'arrêt de jvm). Nous avons eu ce travail très bien. De plus, notre bundle.jar n'est pas énorme au fil du temps car toutes les références de jar ne sont pas incluses dans le pot de bundle. Cependant, nous avons maintenant la possibilité de redémarrer à distance l'application en utilisant OSGI pour le faire au sein de la même JVM. Cependant, lorsque le redémarrage se produit, le chargeur de classe que nous avons ajouté ne reçoit jamais le garbage collecté. Donc, si vous redémarrez l'application comme 10 fois alors il va souffler le Perm Gen de mémoire (Java 1.7).OSGI avec chargeur de classe personnalisée Perm Gen Issue
Nous avons essayé d'imiter ce que fait apache WebAppClassLoader lors du déchargement mais cela n'a pas non plus supprimé les références.
J'ai parcouru Internet pour trouver des solutions à ce problème et je suis certain que nous codons en dehors de l'implémentation OSGI typique, mais il n'y a pas moyen d'effacer les références au ClassLoader. Après le redémarrage, honnêtement, il ne devrait pas y avoir de références.
Nous avons utilisé MAT pour analyser la pile de mémoire, mais la liste de classes référencée est toujours différente.
Quelqu'un sait-il un moyen de charger des bibliothèques externes un meilleur moyen d'utilisation dans OSGI?
Merci pour toute information!
Nous avons donc essayé d'enlever à l'aide URLClassLoader et simplement compter entièrement sur OSGI pour gérer le chargement des classes. Nous avons ensuite testé cela en démarrant et en arrêtant le paquet plusieurs fois et maintenant au lieu de URLClassloader référençant toutes les classes, le BundleWiringImpl $ BundleClassLoaderJava5 montre toujours des références pour chaque fois que nous démarrons et arrêtons le bundle. – Dravenj
Un chargeur de classe peut uniquement récupérer la corbeille si toutes ses classes sont inaccessibles, ce qui implique que toutes les instances de ces classes sont également inaccessibles. Si vous avez une fuite, peu importe comment vous changez la structure du chargeur de classe, vous pouvez seulement vous en débarrasser en identifiant la fuite et en la corrigeant. – Holger