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
Priority: Critical
Attachments: KarafConfigMBeanTest.zip
Although the API of the Karaf Config MBean looks like it offers synchronous
calls, in reality
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 running
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 changes,
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 configurations
as Dictionary instances). So on the console the config commands maintain state
between config:edit
and config:update. Sending off config:update will publish all collected changes
as one configuration
instance.
The API on the JMX level was more or less directly derived from the way the
config console commands
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, but
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 configurations
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
