[jira] [Commented] (DOSGI-160) RemoteServiceAdmin shuts itself down during startup

["Christian Schneider (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DOSGI-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631582#comment-13631582 ] 

Christian Schneider commented on DOSGI-160:
-------------------------------------------

I found one issue with the patch. You unregister the managed service. According to the OSGi specs this should not be done as OSGi cleans it up on stop anyway. I removed that part and documented that we do not need the unregistration. The other unregistrations are done to reflect changes in the config so I think they are necessary.

To register the managed service after the normal init is a good idea. I kept it that way. The synchronized blocks are also good. With the managed service registration after the init the concurrent call probably can only happen if shutdown and update are both happening but still it makes sense for this case.

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