서비스 이벤트에 대해 어떤 보증이 제공되는지 이해하려고합니다.ServiceListener 및 ServiceTracker 호출에는 어떤 순서 보증이 제공됩니까?
OSGi 스펙에 따르면 ServiceEvents가 동기식이므로 ServiceEventener가 REGISTERED ServiceEvent가있는 serviceChanged() 호출이 완료 될 때까지 ServiceListener가 서비스 재시도하지 않는 ServiceEvent를 수신하지 못한다는 것을 의미합니다. 이 올바른지?
또한 ServiceTracker의 소스를 살펴 보았습니다. 이 두 serviceChanged() 호출이 겹치는 상황에 대처하려고 노력하는 것 같습니다. 이것이 가능한가?
ServiceTrackerCustomizer에 대한 호출에 대해 유사한 보증이 있습니까?
이것은 매우 까다로운 문제입니다. 서비스가 OSGi에 등록되면 이벤트가 처리되고 모든 흥미있는 당사자에게 통지됩니다 (서비스 수신기, 서비스 추적기 및 선언적 서비스 런타임). 각 이해 관계자는 이벤트를 처리 할 수있는 기회를 갖습니다. 이벤트 처리에는 추가 서비스 등록 또는 등록 취소가 포함될 수 있습니다. ServiceEvent 알림의 동기 동작으로 인해 이러한 이벤트가 이해 당사자에게 전달됩니다. 긴 종속성 체인에서 알림 트리가 생겨 하나의 서비스를 등록하면 새로운 녀석이 등록됩니다. OSGi는 간단한 등록 서비스 호출이 알 수없는 서비스 수의 서비스 활성화에 대해 요금을 부과 받았기 때문에 OSGi가 매우 어려운 작업을 시작하도록 성능 튜닝을 수행 할 수 있기 때문에이 사실을 알고 있습니다.
특별히 이벤트에 대한 멀티 스레드 관심사가 아닌 질문에 대한 답변을 제공하려면 리전트 (re-entrant) 이벤트가 필요합니다. 전체 트리가 처리되기 전에 등록 이벤트를 처리하는 사람이 다른 이벤트 알림으로 돌아갈 수 있습니다. 이는 잠금을 유지하면서 서비스를 등록 또는 등록 취소하지 않거나 이벤트 디스패처 스레드를 교착 상태로 만들 수 있음을 강력히 권장하는 이유 중 하나입니다. 안전을 유지하는 또 다른 좋은 방법은 그래프가 아니라 번들 종속성 트리를 갖는 것입니다. 클래스가 컴파일 되더라도 번들 간의 순환 의존성은 실제 문제를 일으킬 수 있습니다.
이 정보가 도움이되기를 바랍니다. 이런 종류의 것을 더 읽고 싶다면, OSGi와 Equinox에 새로운 책이 나온다. 그것의 거친 상처에 지금 사용할 수 있으며 곧 인쇄에서 사용할 수 있어야합니다. http://my.safaribooksonline.com/9780321561510
시작 중에 이러한 이벤트 폭풍을 피하고 약간의 순서를 유지하려면 시작 레벨을 사용할 수 있습니다. – akr
서비스 A가 등록되면 각 관심있는 ServiceListener는 해당 서비스에 대한 REGISTERED 이벤트가있는 serviceChanged() 호출을 가져옵니다. REGISTERED 이벤트가 처리되는 동안 동일한 서비스 A *에 대해 UNREGISTERING 이벤트로 re-entrant serviceChanged() 호출을받을 수 있습니까? 서비스 등록을 취소하기 위해 ServiceRegistration이 필요하고 등록이 완료 될 때까지는 사용할 수 없다는 것을 알 수는 없지만 ... –