OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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