2012-04-18 14 views
7

Ho un requisito in cui ho bisogno di ricaricare i miei bundle osgi 4 volte al giorno. Ricaricare un bundle significa ricreare bean di istanze statiche, ricaricare rotte di cammello, ricreare e iniettare pool di thread, pool di connessione al database ..etc (altri contenuti primaverili in xml). Ho provato ad aggiornare i miei bundle tramite ssh, ma avevo bisogno di un bundle id per ciò che può cambiare gli straordinari. Così, ho scritto un bundle manager che ottiene i fasci da nomi simbolici e li rinfresca 4 volte al giornoProblema con l'aggiornamento dei bundle osgi

  osgi impl : felix 

      container : apache-servicemix-4.4.1-fuse-03-06 

      Service Dependency spec : Blueprint 

Ci sono 3 bundle insieme a un aiutante fascio .Il pacchetto helper ha utilizzato tutti i comuni classi e di servizio interfacce. Non vi è alcuna condivisione di codice tra questi 3 pacchetti (nessuno di essi esporta alcun pacchetto). Tutti interagiscono attraverso endpoint e servizi di cammello VM. Rinnovo solo gli altri 3 bundle e il bundle helper non fornisce alcun servizio.

Ora, il problema è quando faccio un aggiornamento su questi 3 bundle che avviano e funzionano bene, ma vedo sempre un aumento di 800-900 classi su jconsole ogni volta che lo faccio. Anche forzare gc non sembra ripulire questi oggetti. Quindi, cosa potrebbero essere questi vecchi oggetti cablati? Le dipendenze del servizio dovrebbero essere aggiornate automaticamente e non ci sono dipendenze tra i pacchetti. Ho controllato la differenza nel conteggio delle classi dopo e prima dell'aggiornamento.

ho potuto vedere che il conteggio di alcune classi sono raddoppiati come org.apache.activemq.camel.component.VmComponent, org.apache.commons.dbcp.BasicDataSource .etc e alcuni chicchi personalizzati che i ho definito nelle mie rotte di cammello. Sono dipendente dal contenitore per cammello-core, cianografia, quarzo ... ecc. Cosa succede esattamente ai bean, endpoint VM..etc nel contesto cammello e componenti definiti in blueprint-config xml in aggiornamento. So che è consigliabile chiamare FrameworkWiring.refreshBundles() dopo aver aggiornato il pacchetto. Ma, non ho la condivisione del codice tra i pacchetti e presumo che qualsiasi altro contenitore di dipendenze debba gestire quello che penso sia sbagliato ora. E non sono sicuro che l'attuale implementazione del framework felix in servicemix supporta FrameworkWiring.refreshBundles() (ref), non sono riuscito a farlo funzionare. Come posso risolvere questo problema?

Grazie sanre6

+0

Sono presenti fili della vecchia istanza di bundle? – artbristol

+0

sì, il loro conteggio è raddoppiato. Stai cercando di dire che devo chiudere le mie istanze, chiudere percorsi cammello prima di aggiornare il pacchetto? – sanre6

+0

Abbiamo riscontrato lo stesso problema. Passare all'attuazione dell'equinozio fa scomparire questo problema, quindi sospetto un problema con il contenitore OSI Felix. –

risposta

0

Non so molto di cammello, ma se si sta fornendo la piattaforma con runnables che fanno riferimento a raggruppare le classi, quindi è necessario fare in modo che tutti vengono cancellati o comunque distrutto il rinfresco, dato che i thread in cui sono in esecuzione terranno un riferimento alle vecchie istanze di Class (che sono diverse dalle istanze di Class del nuovo bundle, anche se sono veramente le stesse). Quindi, aumentando i conteggi delle classi.

+0

la mia applicazione è fortemente dipendente dai bundle di Servicemix e credo che la migliore pratica sia lasciare che il contenitore gestisca le dipendenze, identificando tutte queste dipendenze e risolvendole sarà un lavoro molto doloroso. Non sono nemmeno sicuro se riuscirai a rimuovere l'osgiore principale e e le dipendenze correlate al blueprint prima di aggiornare un pacchetto – sanre6

1

In generale, non è sufficiente richiamare un aggiornamento sui pacchetti. A un certo punto devi anche aggiornare i tuoi pacchetti. Se tutto è ben fatto, questo dovrebbe essere sufficiente per aggiornare tutto il cablaggio del pacchetto, permettendo in effetti di raccogliere le vecchie versioni del bundle. Tuttavia, se c'è qualcosa in uno dei bundle che non si comporta bene e mantiene un thread in esecuzione o alcune risorse in giro in una cache o qualcosa del genere, è necessario iniziare a rintracciare il problema. Prenditi un buon profiler, guarda a quale bundle e classloader appartengono questi oggetti "extra" e vai da lì.