You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Mark Hoffmann (JIRA)" <ji...@apache.org> on 2018/07/06 13:00:00 UTC
[jira] [Created] (ARIES-1817) Export remove do no always end up in
REMOVE events (timing issue)
Mark Hoffmann created ARIES-1817:
------------------------------------
Summary: 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
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)