Quali garanzie di ordinazione vengono fornite sulle chiamate ServiceListener e ServiceTracker?

Question

Sto cercando di capire quali garanzie sono fornite per gli eventi di servizio.

Le specifiche OSGi dice che ServiceEvents sono sincroni, ho preso questo implicare che un ServiceListener non riceverà un serviceChanged() con un annullamento della registrazione ServiceEvent fino alla serviceChanged() con un REGISTRATO ServiceEvent è stata completata. È corretto?

Ho anche dato un'occhiata all'origine di ServiceTracker. Sembra che provi ad affrontare la situazione in cui le due chiamate serviceChanged() si sovrappongono. È possibile?

Esistono garanzie simili per le chiamate a un ServiceTrackerCustomizer?

Answer 1

Questo è un problema molto complicato. Quando un servizio è registrato in OSGi, l'evento viene gestito e tutte le parti interessate vengono notificate (listener del servizio, tracker del servizio e runtime del servizio dichiarativo). Ogni parte interessata ha la possibilità di gestire l'evento. La gestione dell'evento può includere la registrazione o l'annullamento della registrazione di servizi aggiuntivi. A causa del comportamento sincrono della notifica di ServiceEvent, questi eventi vengono quindi inviati alle parti interessate. In una lunga catena di dipendenze si finisce con un albero di notifica, dove si registra un singolo servizio e si fa registrare un gruppo di nuovi ragazzi. Lo so perché può rendere la messa a punto delle prestazioni OSGi startup un esercizio molto impegnativo, dal momento che la semplice chiamata al servizio di registrazione è stata addebitata per l'attivazione del servizio di un numero sconosciuto di servizi.

Per rispondere in modo specifico alla domanda, non è una preoccupazione multi-thread con gli eventi, è un rientro. Quello che sta elaborando il tuo evento di registrazione potrebbe tornare a te con un'altra notifica prima che l'intero albero venga elaborato. Questo è uno dei motivi per cui si consiglia vivamente di non registrare o annullare la registrazione dei servizi mentre si tengono i blocchi, oppure è possibile eseguire il deadlock del thread del dispatcher dell'evento. Un altro buon modo per stare al sicuro è avere un albero di dipendenza del fascio, non un grafico. Le dipendenze circolari tra i pacchetti, anche se la compilazione delle classi può causare problemi reali.

Spero che questo aiuti. Se vuoi leggere di più su questo genere di cose, c'è un nuovo libro che esce su OSGi ed Equinox. È disponibile su tagli di massima ora e dovrebbe essere disponibile in stampa molto presto. http://my.safaribooksonline.com/9780321561510