Hi, I'm still seeing the behaviour where the zookeeper node isn't deleted, and after several hours debugging I think I can see why. This is against the current trunk of the DOSGi code.
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 ? I've placed the logging config I used at https://gist.github.com/sneakybeaky/5579559. If you use that and stop the bundle with the service you can see the sequence happening in that order : Jon. On Tue, May 14, 2013, at 01:25 PM, Christian Schneider wrote: > The zookeeper node of the service should be deleted. > > I just tested this on my system. > > When I start the service then the following node is created: > /osgi/service_registry/com/ninedemons/spikes/dosgi/shared/PingService/192.168.7.2#8181##cxf#display > > When I stop the service the node is deleted. The parent node is still > there but that should be no problem. > /osgi/service_registry/com/ninedemons/spikes/dosgi/shared/PingService > > Christian > > On 14.05.2013 13:59, Jon Barber wrote: > > Hi, > > > > So I used CXF DOSGi current snapshot from trunk, and that sort of fixes > > the issue in that the service is removed when the bundle is stopped, but > > the entry in zookeeper remains, meaning consuming services still try and > > use it. > > > > Is this a bug, or my misunderstanding of what should happen ? > > > > Thanks, > > > > Jon. > > > > On Tue, May 14, 2013, at 11:51 AM, Jon Barber wrote: > >> Hi Christian, > >> > >> Many thanks for looking at this. > >> > >> I should have made it clearer in the README - I started zookeeper > >> externally, but your method makes it even easier to reproduce. > >> > >> I explicitly set the port & server to get around an issue when I had 2 > >> Karaf containers running - at least one would not use the default 8181 > >> port and CXF seemed to default to this, leading to the service not being > >> registered (or at least that seemed to be the case). If I can omit that > >> line even better. > >> > >> Jon. > >> > >> On Tue, May 14, 2013, at 10:57 AM, Christian Schneider wrote: > >>> Hi Jon, > >>> > >>> I was not able to run your example as is. > >>> The first problem was that zookeeper was missing. So I needed to run: > >>> features:install cxf-dosgi-zookeeper-server > >>> cxf-dosgi-discovery-distributed > >>> > >>> Then it tried to come up but I got the message that a jetty was already > >>> started on this port. So this may point to another bug. > >>> > >>> I simplified your example a but by doing: > >>> > >>> props.put("service.exported.interfaces", "*"); > >>> props.put("service.exported.configs", "org.apache.cxf.ws"); > >>> props.put("org.apache.cxf.ws.address", "/display"); // old > >>> obsolete value > >>> // props.put("endpoint.id", address); > >>> > >>> So I simply used an address without server and port. This signals dosgi > >>> to use the servlet transport. So it uses the default port 8181 and the > >>> default cxf servlet alias of "cxf". The full address then looks like > >>> this: http://192.168.7.2:8181/cxf/display > >>> > >>> Is there a special reason why you explicitly specify a port and a server > >>> name? I think using the servlet transport is much easier and allows to > >>> centrally manage the port at one place. > >>> > >>> So this allowed me to get the service published. I then tried to stop > >>> the bundle. The service was still available like you reported. > >>> I will track the issue in: > >>> https://issues.apache.org/jira/browse/DOSGI-180 > >>> > >>> As a next step I will test with the current snapshot and try to debug > >>> where the problem is originated. > >>> > >>> Christian > >>> > >>> > >>> On 14.05.2013 10:11, Jon Barber wrote: > >>>> Hi Christian, > >>>> > >>>> The code I'm using is available at > >>>> https://github.com/sneakybeaky/DOSGi-Spike and I've added details to the > >>>> README about how to recreate. > >>>> > >>>> Thanks, > >>>> > >>>> Jon. > >>>> > >>>> On Mon, May 13, 2013, at 11:48 PM, Christian Schneider wrote: > >>>>> I think the patch will not work for your problem as you only register > >>>>> the service once. > >>>>> > >>>>> I will try to recreate the problem on my system. > >>>>> > >>>>> Christian > >>>>> > >>>>> Am 13.05.2013 21:36, schrieb Jon Barber: > >>>>>> Hi, > >>>>>> > >>>>>> I applied that patch, built as 1.5.0-SNAPSHOT and loaded into a running > >>>>>> Karaf instance. Same issue - this doesn't seem to fix the problem. > >>>>>> > >>>>>> Jon. > >>>>>> > >>>>>> On Mon, May 13, 2013, at 04:36 PM, Sergey Beryozkin wrote: > >>>>>>> Hi > >>>>>>> > >>>>>>> Please watch the following JIRA: > >>>>>>> > >>>>>>> https://issues.apache.org/jira/browse/DOSGI-177 > >>>>>>> > >>>>>>> it even has a patch attached, so will be fixed for DOSGi 1.5 > >>>>>>> > >>>>>>> Sergey > >>>>>>> On 13/05/13 16:03, Jon Barber wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I have a simple OSGi service I've exposed via CXF DOSGi 1.4.0 using > >>>>>>>> Karaf 2.2.11 - it's pretty much a straight copy from the discovery > >>>>>>>> sample from the 1.4.0 release of cxf-dosgi. The service is exposed by > >>>>>>>> the bundle activator as follows : > >>>>>>>> > >>>>>>>> private ServiceRegistration reg; > >>>>>>>> > >>>>>>>> public void start(BundleContext bc) throws Exception { > >>>>>>>> Dictionary<String, Object> props = new Hashtable<String, > >>>>>>>> Object>(); > >>>>>>>> > >>>>>>>> String host = getHostName(); > >>>>>>>> int port = getPort(); > >>>>>>>> > >>>>>>>> String address = getAddress(host,port); > >>>>>>>> LOG.info("Registering ws address {}",address); > >>>>>>>> > >>>>>>>> props.put("service.exported.interfaces", "*"); > >>>>>>>> props.put("service.exported.configs", > >>>>>>>> "org.apache.cxf.ws"); > >>>>>>>> props.put("org.apache.cxf.ws.address", address); // old > >>>>>>>> obsolete > >>>>>>>> value > >>>>>>>> props.put("endpoint.id", address); > >>>>>>>> > >>>>>>>> reg = bc.registerService(PingService.class.getName(), > >>>>>>>> new SimplePingService(), props); > >>>>>>>> } > >>>>>>>> > >>>>>>>> public void stop(BundleContext bc) throws Exception { > >>>>>>>> LOG.info("Unregistering ping service"); > >>>>>>>> > >>>>>>>> reg.unregister(); > >>>>>>>> } > >>>>>>>> > >>>>>>>> > >>>>>>>> And sure enough it gets registered as a SOAP service and I can see > >>>>>>>> it in > >>>>>>>> zookeeper too. However, when I stop the bundle the service is indeed > >>>>>>>> removed in the local OSGi registry but I can still access the SOAP > >>>>>>>> endpoint, and it's still visible in zookeeper too. Furthermore, if I > >>>>>>>> re-activate the bundle the service is now available on the old > >>>>>>>> endpoint > >>>>>>>> and the new one. > >>>>>>>> > >>>>>>>> So either my understanding is wrong (I would have thought > >>>>>>>> unregistering > >>>>>>>> the service would remove the SOAP service too) or there's a bug in > >>>>>>>> DOSGi, or I'm missing something / doing something wrong. > >>>>>>>> > >>>>>>>> Could someone give some guidance please ? > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Jon. > >>>>>>> -- > >>>>>>> Sergey Beryozkin > >>>>>>> > >>>>>>> Talend Community Coders > >>>>>>> http://coders.talend.com/ > >>>>>>> > >>>>>>> Blog: http://sberyozkin.blogspot.com > >>>>> -- > >>>>> > >>>>> Christian Schneider > >>>>> http://www.liquid-reality.de > >>>>> > >>>>> Open Source Architect > >>>>> Talend Application Integration Division http://www.talend.com > >>>>> > >>> > >>> -- > >>> Christian Schneider > >>> http://www.liquid-reality.de > >>> > >>> Open Source Architect > >>> http://www.talend.com > >>> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
