[
https://issues.apache.org/jira/browse/DOSGI-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved DOSGI-160.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.5
Assignee: Christian Schneider
> 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.0
> Environment: Oracle JDK 1.7.0_17, Karaf 2.3.1, DOSGi 1.4.0 (installed
> from Karaf feature)
> Reporter: Amichai Rothman
> Assignee: Christian Schneider
> Fix For: 1.5
>
> 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
