[ https://issues.apache.org/jira/browse/ARIES-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider reassigned ARIES-1817: ------------------------------------------ Assignee: Christian Schneider > Export remove do no always end up in REMOVE events (timing issue) > ----------------------------------------------------------------- > > Key: ARIES-1817 > URL: https://issues.apache.org/jira/browse/ARIES-1817 > Project: Aries > Issue Type: Bug > Components: Remote Service Admin > Affects Versions: rsa-1.12.0 > Reporter: Mark Hoffmann > Assignee: Christian Schneider > Priority: Major > Fix For: rsa-1.13.0 > > Attachments: ServiceExportsRepository.patch > > > During testing aries RSA I found several situations where my discovery did > not received a remove event. After some inspection I found that > org.apache.aries.rsa.core.ExportRegistrationImpl#getExportReference returns > only the reference instance when its not closed, otherwise null. > Usually I expected that the ExportRegistration is closed by the > TopologyManager, in this case > org.apache.aries.rsa.topologymanager.exporter.ServiceExportRepository. But > thats not true. While debugging I saw that sometimes > org.apache.aries.rsa.core.RemoteServiceAdminCore#removeServiceExports closes > the ExportRegistration a little bit earlier. That leads to a null > ExportReference instance in ServiceExportRepository#closeReg, which in return > leads to no remove event. > So, there is no single point of truth, who closes the ExportRegistration. > Citing the Spec 122.5.1: > _The Export Registrations remain open until:_ > _Explicitly closed by the Topology Manager, or_ > _The Remote Service Admin service is no longer used by the Topology Manager > that created the Export Registration._ > _If the Remote Service Admin service can no longer maintain the corresponding > Endpoint due to failures than these should be reported through the events. > However, the registrations should remain open until explicitly closed by the > Topology Manager._ > I attached a patch, that solve the problem, but is as well not compliant to > the spec, like the current implementation. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)