Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 18 Mar 2014 14:21:43 +0000 (UTC)
From: "Amichai Rothman (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12699361.1394180433138.97116.1395152503791@arcas>
In-Reply-To: <JIRA.12699361.1394180433138@arcas>
References: <JIRA.12699361.1394180433138@arcas>
Subject: [jira] [Resolved] (DOSGI-214) Endpoint publication to discovery
 does not always work
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DOSGI-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amichai Rothman resolved DOSGI-214.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 1.7.0
         Assignee: Amichai Rothman  (was: Christian Schneider)

Nice catch! And a good analysis too - thanks.

I made the second fix using the SimpleServiceTracker helper class though, since it's simpler (keeps concurrency logic separate from the business logic) and I think using synchronized as suggested would still leave a small gap between when addingService returns and when the new service is added to the getServiceReferences result where a new export might get lost.

> Endpoint publication to discovery does not always work
> ------------------------------------------------------
>
>                 Key: DOSGI-214
>                 URL: https://issues.apache.org/jira/browse/DOSGI-214
>             Project: CXF Distributed OSGi
>          Issue Type: Bug
>          Components: DSW
>    Affects Versions: 1.6.0
>         Environment: Windows 7, Linux (OpenSuse), seems to happen more often with slower CPU computers
>            Reporter: Timo Heinonen
>            Assignee: Amichai Rothman
>             Fix For: 1.7.0
>
>
> TopologyManager bundle's EndpointListenerNotifier does not call all EndpointListener's at all times correctly and therefore some endpoints don't get published to discovery (zookeeper). 
> I found following problems with the current implementation:
> 1) TopologyManagerExport.exportServiceUsingRemoteServiceAdmin():
> In the end of the exportServiceUsingRemoteServiceAdmin() notifyListeners() is called before updating endpointregistry. This causes problem in EndpointListenerNotifier, because endpointRepository.getAllEndpoints() does not return correct state before endpoints are updated. Basically problem exists when ServiceTracker's addingService() is called simultaneously for discovery bundle's EndpointLIstener and other thread (call coming from TopologyManagerExport) calls notfiyListeners(). stEndpointListeners.getServiceReferences() does not yet return the endpoint listener of discovery bundle and therefore discovery is not notified. Also, addingService() call does not find endpoint from endpointRegistry and therefore does not publish it.
> FIX: By changing the order of notifyListeners() and addEndpoints() in TopologyManagerExport the above is fixed.
> 2) EndpointListenerNotifier is not threadsafe although ServiceTracker is. stEndpointListeners.getServiceReferences() returns just added EndpointListener (the one from discovery bundle) only AFTER whole overrided addingService() method has finished. So following can happen:
> a) addingService() is called with discovery bundle's EPL
> b) super.addingService() call is finished and notifyListener() is called with no new Endpoint because TopologyManagerExport has not yet added it to endPointRepo
> c) TopologyManagerExport calls addEndpoint() and notifyListeners() (in fixed order) and EndpointListenerNotifier does not notify discove EPL, because addingService() call has not yet returned and therefore stEndpointListeners.getServiceReferences() still returns 1 EPL (from topologyManager bundle)
> FIX: Add synchronized (EndpointListenerNotifier.this) to both methods addingService and modifiedService. Also add synchronized (this) to notifyListeners() method so that lock guards call to stdEndpointListeners.getServiceReference(). 


--
This message was sent by Atlassian JIRA
(v6.2#6252)