[
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)