Für unsere Zwecke haben wir nicht mit der Standard-OSGI-Jar-Referenz gehen, die die Gläser in das Bündel baut. Bei Online-Upgrades wollten wir in der Lage sein, neue und aktualisierte Jars während Upgrades bereitzustellen. In unserer Activator-Klasse, die ein Bundle startet und stoppt, implementieren wir unseren eigenen URLClassLoader und suchen dann alle JARs in einem Unterordner und stellen den URLClassLoader zusammen mit dem OSGI CLassLoader als Parent bereit. Das ist großartig, denn jetzt können Administratoren der Anwendung jars einfach zu einem Klassenpfad hinzufügen und die Anwendung neu starten (osgi restart, jvm nicht herunterfahren). Wir haben das super funktioniert. Außerdem wird unsere bundle.jar im Laufe der Zeit nicht sehr groß, da nicht alle Jarreferenzen im Bündelglas enthalten sind.OSGI mit benutzerdefiniertem Class Loader Perm-Gen Problem
Jetzt haben wir jedoch die Möglichkeit, die Anwendung remote neu zu starten, indem wir OSGI verwenden, um dies innerhalb derselben JVM zu tun. Wenn der Neustart jedoch auftritt, wird der Klassenlader, den wir hinzugefügt haben, niemals mit Garbage Collections gesammelt. Wenn Sie die Anwendung also 10 Mal neu starten, wird der Perm Gen den Speicher (Java 1.7) sprengen.
Wir haben versucht zu imitieren, was Apache WebAppClassLoader beim Entladen tut, aber die Referenzen auch nicht entfernt.
Ich habe das Internet nach Lösungen dafür durchforstet und vorausgesetzt, wir codieren außerhalb der typischen OSGI-Implementierung, aber gibt es keine Möglichkeit, die Verweise auf den ClassLoader zu löschen. Nach dem Neustart sollte es ehrlich gesagt keine Referenzen geben.
Wir haben MAT verwendet, um den Heap-Dump zu analysieren, aber die referenzierte Liste der Klassen ist immer unterschiedlich.
Wer weiß von einer Möglichkeit, externe Bibliotheken zu laden, eine bessere Möglichkeit für den Einsatz in OSGI?
Danke für jede Information!
So haben wir versucht, die Klassenlade zu verwalten mit URLClassLoader und einfach vertrauen ganz auf OSGi zu entfernen. Wir haben das getestet, indem wir das Bundle mehrfach gestartet und gestoppt haben und statt URLClassloader, das auf alle Klassen verweist, zeigt BundleWiringImpl $ BundleClassLoaderJava5 immer noch Referenzen für jedes Mal an, wenn wir das Bundle starten und stoppen. – Dravenj
Ein Klassenladeprogramm kann nur Garbage Collection abrufen, wenn alle Klassen nicht erreichbar sind. Dies bedeutet, dass auch alle Instanzen dieser Klassen nicht erreichbar sind. Wenn Sie ein Leck haben, spielt es keine Rolle, wie Sie die Struktur des Klassenladeprogramms ändern. Sie können es nur loswerden, indem Sie das Leck identifizieren und beheben. – Holger