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

Amichai Rothman updated DOSGI-160:
----------------------------------

    Attachment: fix_activator_config_and_sync_issues.diff


These are the changes:

- fixed updated callback shutting down service right after it starts (when 
config is null), causing service exports to fail sometimes. This is done by 
simply doing nothing when the configuration is null, since the service is 
already started with default parameters when the bundle starts, so there's no 
need to change anything when there is no new configuration to use.

- separated stop/start (when bundle is started or stopped) from init/uninit 
(setting up/tearing down the services when configuration changes) - solves 
endless loop caused by start re-registering the ManagedService, which 
re-triggers update, which calls start etc. ad infinitum. If there is anything 
else in init/uninit that should actually be performed only once at bundle 
start/stop (and not when configuration changes), feel free to move it into 
start/stop respectively.

- synchronized init/uninit/update (since update is called from another thread 
and so init/uninit may be called concurrently with undefined results)

- added proper unregistering of managed service, just in case (and for 
consistency with how the other two registered services are handled)

- added a few debug logs to be more informative and help follow the sequence of 
events

                
> RemoteServiceAdmin shuts itself down during startup
> ---------------------------------------------------
>
>                 Key: DOSGI-160
>                 URL: https://issues.apache.org/jira/browse/DOSGI-160
>             Project: CXF Distributed OSGi
>          Issue Type: Bug
>          Components: DSW
>    Affects Versions: 1.4
>         Environment: Oracle JDK 1.7.0_17, Karaf 2.3.1, DOSGi 1.4.0 (installed 
> from Karaf feature)
>            Reporter: Amichai Rothman
>         Attachments: fix_activator_config_and_sync_issues.diff
>
>
> Every once in a while (quite often) the service export fails. Looking through 
> the logs, I found the message "RemoteServiceAdmin Implementation is shutting 
> down now" - during Karaf startup! It appears that the RSA is started, 
> services exported properly etc., but then it suddenly commits suicide a few 
> moments later with no other error or indication of who/what initiated the 
> shutdown or why.
> Further investigation shows the DSW Activator is getting a ConfigurationAdmin 
> updated event with null configuration (according to the OSGi specs, the 
> callback is guaranteed to be called - either with an existing configuration 
> or with null if none is available). The current implementation of the 
> callback stops the bundle, shutting down the service and printing the above 
> log message, but when the configuration is null it does not start it back up, 
> resulting in the observed behaviour.
> There's also a race condition in the class since from my understanding of the 
> specs the updated callback is called asynchronously from a separate thread, 
> and since it stops and possibly starts the bundle, this might cause the 
> start/stop methods to be run concurrently and more than once (the bundle 
> lifecycle start/stop along with the update-triggered start/stop).
> Finally, while debugging and attempting to fix this I came across a third 
> related issue - when the bundle is indeed started up again in the updated 
> method (e.g. if removing the null check or if a configuration is available), 
> the start method then re-registers the ManagedService, which causes the 
> updated method to be called again, which restarts the bundle again, etc. - in 
> an infinite loop. In practice I saw the server hang with 100% CPU usage 
> indefinitely, and in a later session with a debugger the loop was confirmed.
> Attached is a fix for the 3 related issues - when applied together everything 
> seems to work as expected. I'm new to this project, so please correct 
> anything I've missed.

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

Reply via email to