Referencias de servicio en OSGi

Question

Una vez que se recupera una instancia de un servicio OSGi del contexto de paquete, ¿se invalida cuando se detiene el servicio?

Mis pruebas iniciales muestran que la instancia de servicio se puede usar incluso después de detener el paquete de servicios, lo que contradice mi comprensión de la naturaleza dinámica de OSGi.

Supongo que esto se reduce a lo que hace realmente recuperar un servicio (a través de ServiceTracker) de otro paquete en el contenedor OSGi, crea una nueva instancia o le da un puntero a la instancia que está registrada en el contenedor ?

¿Hay algún peligro al usar la instancia de servicio una vez que se ha detenido el servicio?

Answer 1

Esta es una muy buena pregunta, así que profundicé en la especificación en busca de una respuesta definitiva. Resulta que hay una sección completa que habla sobre este problema - ver la sección 5.4 Referencias obsoletas comenzando en la página 132 de OSGi Service Platform Core Specification, Release 4, Version 4.2.

Para responder a su pregunta de acuerdo a la especificación:

El comportamiento de un servicio que se convierte sin registrar no está definido. Dichos servicios pueden continuar funcionando correctamente o emitir una excepción a su discreción.

y para prevenir posibles problemas:

paquetes deben escuchar a los eventos generados por el Marco para limpiar y eliminar rancios referencias.

La especificación también brinda algunos consejos sobre cómo minimizar las consecuencias de las referencias obsoletas.

Answer 2

Tiene razón en que es contradictorio con la naturaleza dinámica de OSGi. Creo que no hay garantía de que el servicio esté disponible, aunque las diferentes implementaciones de los contenedores y servicios OSGi pueden comportarse de manera diferente.

Por ejemplo, si el servicio fue creado y registrado con Spring DM, entonces el servicio recuperado es en realidad un proxy basado en Spring para la implementación subyacente, y la implementación aún puede desaparecer. Por lo tanto, una referencia de servicio que se refiere directamente a una implementación puede evitar que ese objeto se elimine, mientras que la referencia basada en proxy no lo hará.

Answer 3

La especificación OSGi dice:

paquetes son entidades que son visibles en la programación aplicación normal. Para el ejemplo , cuando se detiene un paquete, todos sus servicios serán desregistrados .

Por lo tanto, no debería poder recibir un servicio de un paquete detenido. Pero técnicamente puede ser posible usarlo, al menos mientras mantenga una referencia al objeto de servicio (nadie puede quitárselo y no será GC). Pero no creo que sea seguro usar el servicio. Puede depender de otros recursos del paquete, que no están disponibles después de que el paquete se haya detenido.

Answer 4

En relación con su pregunta sobre si es peligroso utilizar una instancia de servicio después de que se haya detenido el servicio. Para citar de la especificación 4.2 de núcleo (5.4 Referencias rancios):

El comportamiento de un servicio que se convierte en no registrado es indefinido. Dichos servicios pueden continuar funcionando correctamente o lanzar una excepción en su discreción.

no quiero citar toda la sección de la especificación aquí, pero las siguientes frases son una buena discusión sobre el peligro de utilizar referencias rancios:

Una referencia rancio es una referencia a una aplicación Java objeto que pertenece al cargador de clase de un paquete que está detenido o está asociado con un objeto de servicio que no está registrado. El estándar Java no proporciona ningún medio genérico para limpiar las referencias obsoletas, y los desarrolladores del paquete deben analizar su código cuidadosamente para asegurarse de que las referencias obsoletas se eliminen.

Las referencias obsoletas son potencialmente dañinas porque impiden que el recolector de basura Java recopile las clases, y posiblemente las instancias, de paquetes detenidos. Esto puede ocasionar un aumento significativo del uso de la memoria y puede hacer que falle la actualización de las bibliotecas de códigos nativos. Los paquetes que usan los servicios son muy recomendables para usar Service Tracker o Servicios Declarativos.

Answer 5

Una vez que una instancia de un servicio OSGi se obtenidos del contexto paquete qué que se convierta en invalidada cuando el servicio se detiene?

No, la referencia en sí no se invalida. Mientras algo dentro del contenedor lo contenga, tampoco puede ser sometido a GC.

Sin embargo, si será o no útil, depende solo de la implementación del servicio en sí, no del contenedor.

Mis pruebas iniciales muestran que la instancia de servicio se puede usar incluso después de que el paquete de servicios> se detiene, lo que contradice mi comprensión de la naturaleza dinámica de OSGi.

Las propias especificaciones indican que tales referencias no deben mantenerse, pero corresponde al implementador tener cuidado de implementar las especificaciones correctamente; significa que no hay contradicción, solo existe el hecho de que puede implementar y desplegar paquetes que no se comportan correctamente de acuerdo con las especificaciones.

supongo que esto se reduce a lo que la recuperación de un servicio (a través de ServiceTracker) de otro paquete en el contenedor OSGi en realidad no, tampoco crea una nueva instancia o se le dará un puntero a la instancia que es registrado en el contenedor?

El contenedor no crea nuevas instancias de servicios, excepto si hay un ServiceFactory involucrado (ver especificaciones). Buscar un servicio siempre debe darle un puntero a la instancia registrada en el contenedor.

¿Hay algún peligro al usar la instancia de servicio una vez que se ha detenido el servicio?

Eso solo depende de la implementación del servicio; sin embargo, al hacerlo en un paquete, crea automáticamente un paquete que no cumple con las especificaciones.

En la práctica, muchos servicios se implementan para liberar recursos y referencias y ya no responderán correctamente.

Answer 6

Una referencia de servicio nunca debe mantenerse como referencia. Siempre debe buscar un servicio en tiempo de ejecución. Sin embargo, esto te vincula con la api de OSGI, que no siempre se desea.

Tenga una mirada en - OSGi serviceTracker - OSGi servicios declarativos - OSGi BluePrint - Spring DM - Peaberry - iPojo

la que todos cuidar el dinamismo para usted, la mayoría de ellos sin OSGI api para usar.

Saludos,

Leen Toelen