karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré (Commented) (JIRA) <j...@apache.org>
Subject [jira] [Commented] (KARAF-1243) Karaf JMX Config MBean behaves in unpredictable ways
Date Fri, 09 Mar 2012 18:26:58 GMT

    [ https://issues.apache.org/jira/browse/KARAF-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226286#comment-13226286

Jean-Baptiste Onofré commented on KARAF-1243:

I will review the patch and at least add the configuration.update() on Karaf 2.2.x propset()

Anyway, I think that the Christian's patch should not be apply like this as the signature
of ConfigMBean changed. It should not be the case on a maintenance branch.
> Karaf JMX Config MBean behaves in unpredictable ways
> ----------------------------------------------------
>                 Key: KARAF-1243
>                 URL: https://issues.apache.org/jira/browse/KARAF-1243
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-config
>    Affects Versions: 2.2.5
>            Reporter: Jürgen Kindler
>            Assignee: Christian Schneider
>            Priority: Critical
>             Fix For: 2.2.6, 3.0.0
>         Attachments: KarafConfigMBeanTest.zip, karaf2.2.x-config.patch
> Although the API of the Karaf Config MBean looks like it offers synchronous calls, in
> this is not true. I ran into some issues with this, because I tried to install configurations
> for bundles to be picked up (see attached maven test case project to be used with a default
> Karaf 2.2.5 container)
> It seems that the config bundle may need quite a long time to finish applying the configuration
> changes, but returns BEFORE this is finished in background.
> I have searched around, dug through code, but found no way to determine at which time
I can
> safely assume that a configuration change is finished and I can continue with installing
the bundle
> that may pick up this configuration (in some cases the default configuration is enough,
but more 
> often I want to override that...). So I finally ended up with polling for the configuration
> but even that sometimes fails and I could loop infinitely and get no result (got an empty
Map from proplist method).
> From the JavaDoc of the MBean I would - as said - expect that I do not have to do that,
but could
> assume that after a create or propset call returns, the configuration is active. I would
have been
> a bit happier, if the config MBean offered JMX events that notify about the completion
of a 
> configuration change, but after digging deeper it seems that even that would not be an
optimal solution.
> From my understanding the underlying implementation is a mix of Karaf maintaining its
own config
> files inside the etc folder plus updating data inside the OSGi ConfigAdmin Service.
> The good thing about the console commands is that they implement a strategy that really
> matches the idea of the OSGi ConfigAdmin service (the service always publishes complete
> as Dictionary instances). So on the console the config commands maintain state between
> and config:update. Sending off config:update will publish all collected changes as one
> instance.
> The API on the JMX level was more or less directly derived from the way the config console
> work, but tries to avoid maintaining state - so there's no equivalent to config:edit
/ config:update.
> Instead, propset, propdel and propappend immediately trigger propagation of simple changes
to the
> configuration. So on JMX level the granularity is not sending of a new Dictionary instance,
> reflects the operations to create such an instance. Instead of publishing one change
a configuration
> containing 20 properties would trigger 20 changes. 
> This will also cause multiple notifications for any "interested" configuration change
listener ... 
> resulting not only in more load, but also possibly in inconsistent configuration sub
stages to cope
> with: Imagine a service requires two configuration parameters to work correctly. Instead
of getting
> one configuration notification that contains the two parameters, it will get two notifications
and thus will have to handle the case that the second parameter is missing (desperately hoping
that sooner or later this second parameter will appear ...).
> Phew ':-) ... so I would suggest that this API should be changed:
> - guarantee that on return from an MBean method that changes a configuration, this configuration

>   can be assumed to be active (so after creating a query call will return the equivalent
created config).
> - if this appears to be impossible, the bean should at least provide JMX events a client
can listen
>   to in order to be notified when a configuration call is finished.
> - in order to play nicely inside the OSGi framework, it should be possible to create
>   by calling void create(String pid, Map<String, String> config)
> - propset / propappend / propdel should be deprecated or (better) directly removed. (They
make sense
>   on console, but not for JMX).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message