[jira] [Commented] (ARIES-1940) Failure during service export is not properly handled by RemoteServiceAdminCore

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (ARIES-1940) Failure during service export is not properly handled by RemoteServiceAdminCore

ASF subversion and git services (Jira)

    [ https://issues.apache.org/jira/browse/ARIES-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970378#comment-16970378 ]

Arnoud Glimmerveen commented on ARIES-1940:
-------------------------------------------

I think there is one aspect that needs attention with respect to dealing with failed service export: how/when is the ExportRegistration removed from the internal state of RemoteServiceAdminCore?

I believe the current implementation relies on a ServiceListener and matching the ServiceReference with the ServiceReferences referenced by the ExportReference in order to cleanup the internal administration. However in the failure case only the thrown Exception is stored, so there is no ServiceReference to match, leaving the failed ExportRegistration in the internal state.

Is this observation accurate or is there some other cleanup-flow I missed?

> Failure during service export is not properly handled by RemoteServiceAdminCore
> -------------------------------------------------------------------------------
>
>                 Key: ARIES-1940
>                 URL: https://issues.apache.org/jira/browse/ARIES-1940
>             Project: Aries
>          Issue Type: Bug
>          Components: Remote Service Admin
>    Affects Versions: rsa-1.14.0
>         Environment: Apache Aries 1.14.0
> Apache Felix Framework 6.0.2
>            Reporter: Arnoud Glimmerveen
>            Priority: Major
>             Fix For: rsa-1.15.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> When a DistributionProvider throws an Exception from the DistributionProvider.exportService() method, the RemoteServiceAdminCore detects this properly and keeps track of this failure by creating a ExportRegistration instance that references the thrown Exception.
> The specification mandates that if a service export failed, the ExportRegistration should provide access to the thrown Exception (which the current implementation does) and that the ExportReference of the ExportRegistration should throw an IllegalStateException.
> The current implementation of RemoteServiceAdminCore handles this in an inconsistent way:
> * The ExportRegistration.getExportReference() returns null rather then throwing the IllegalStateException
> * The use of ExportRegistration assumes that there always is an ExportReference instance. This assumption is wrong in cases that the export failed.
> The latter triggers exceptions such as as the one below; typically triggered by an event unrelated to the export service failure:
> {noformat}
> java.lang.NullPointerException
>                 at org.apache.aries.rsa.core.RemoteServiceAdminCore.removeServiceExports(RemoteServiceAdminCore.java:505)
>                 at org.apache.aries.rsa.core.RemoteServiceAdminCore$2.serviceChanged(RemoteServiceAdminCore.java:104)
>                 at org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>                 at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>                 at org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>                 at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>                 at org.apache.felix.framework.Felix.access$000(Felix.java:112)
>                 at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:434)
>                 at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:170)
>                 at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:145)
>                 ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)