[
https://issues.apache.org/jira/browse/DOSGI-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658227#comment-13658227
]
Christian Schneider edited comment on DOSGI-180 at 5/15/13 10:41 AM:
---------------------------------------------------------------------
Jon explained in a mail on the list that there is probably a race condition.
I also think so and think there is no simple fix to that.
The problem is that the ExportReference field are set to null when the export
reg is closed. So the topology manager will not notify the correct
EndpointListeners.
---
When I stop the bundle I see that the ServiceTracker declared at
org.apache.cxf.dosgi.dsw.service/ExportRegistrationImpl line 178 is
invoked - in fact it's the removedService() method of that. This in turn
calls close() on the ExportReferenceImpl, which simply sets the
endpointDescription and serviceReference fields to null.
Some time after this then the ServiceListener declared at line 96 of
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport
gets called. This in turn works out what EndpointListeners to notify
that the endpoint has been removed ( the method notifyListenersOfRemoval
at line 126 in
org.apache.cxf.dosgi.topologymanager.exporter.EndpointListenerNotifier )
- and it's one of these
(org.apache.cxf.dosgi.discovery.zookeeper.PublishingEndpointListener)
which deleted the zookeeper node.
However, the logic in notifyListenersOfRemoval uses the
endpointDescription to work out which listeners to notify - and at this
point it's set to null, so none at all are selected, meaning that the
zookeeper node isn't deleted.
So it looks like this may be a race condition - is there any reason why
the correct sequence (ServiceListeners called before ServiceTracker ?)
should happen which would mean the the node is deleted ?
was (Author: ch...@die-schneider.net):
Jon explained in a mail on the list that there is probably a race condition.
I also think so and think there is no simple fix to that.
The problem is that the ExportReference field are set to null when the export
reg is closed. When the zookeeper discovery then is notified of the change it
tries to read the reference but only sees null values.
---
When I stop the bundle I see that the ServiceTracker declared at
org.apache.cxf.dosgi.dsw.service/ExportRegistrationImpl line 178 is
invoked - in fact it's the removedService() method of that. This in turn
calls close() on the ExportReferenceImpl, which simply sets the
endpointDescription and serviceReference fields to null.
Some time after this then the ServiceListener declared at line 96 of
org.apache.cxf.dosgi.topologymanager.exporter.TopologyManagerExport
gets called. This in turn works out what EndpointListeners to notify
that the endpoint has been removed ( the method notifyListenersOfRemoval
at line 126 in
org.apache.cxf.dosgi.topologymanager.exporter.EndpointListenerNotifier )
- and it's one of these
(org.apache.cxf.dosgi.discovery.zookeeper.PublishingEndpointListener)
which deleted the zookeeper node.
However, the logic in notifyListenersOfRemoval uses the
endpointDescription to work out which listeners to notify - and at this
point it's set to null, so none at all are selected, meaning that the
zookeeper node isn't deleted.
So it looks like this may be a race condition - is there any reason why
the correct sequence (ServiceListeners called before ServiceTracker ?)
should happen which would mean the the node is deleted ?
> CXF service does not disappear if exporting bundle is stopped
> -------------------------------------------------------------
>
> Key: DOSGI-180
> URL: https://issues.apache.org/jira/browse/DOSGI-180
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
> Affects Versions: 1.4.0
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Fix For: 1.5
>
>
> I used the example at https://github.com/sneakybeaky/DOSGi-Spike but with an
> address of "/display".
> The cxf endpoint came up when starting the feature but did not go down when
> stopping the service bundle.
> See this post for the original bug report:
> http://cxf.547215.n5.nabble.com/DOSGi-service-still-available-after-being-unregistered-td5727594.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
