You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "A. Rothman" <am...@amichais.net> on 2013/03/20 19:25:02 UTC
Fwd: DOSGi - service not exported consistently
[The message body disappeared for some reason, resending...]
Hi,
While trying to use DOSGi (1.4.0, in Karaf 2.3.1) I came across some
serious issues, namely when starting up a fresh Karaf instance
repeatedly, only about 50% of the time the service actually got exported
(as verified with a browser pointing to the appropriate WSDL URL). This
is just on a single instance on a local host, before trying to do
anything remotely. I started investigating into the matter, which
required quite a lot of debugging and code reviewing, and found various
issues with the (strangely named?) TopologyManagerExport class which
seems to be at the heart of the matter. This took several iterations and
includes also non-critical cleanups I did along the way - I'm attaching
the final version I arrived at which hopefully addresses the issues,
though due to the law of clustering of bugs, I wouldn't be surprised if
there are other new or old bugs still lurking there... any feedback and
additional code reviews would be greatly appreciated.
Here is a summary of all the changes, big and small:
- fixed typos in docs and logs.
- fixed formatting to be more consistent and readable.
- added debug logs to RemoteServiceAdminLifeCycleListener.added/removed
callbacks (this proved the serious tracker bug below, but is also useful
for general debugging).
- simplified shouldExportService returned boolean expression.
- replaced iterations on map keys followed by a get of the corresponding
value with an iteration on Map.Entry (prevents unnecessary lookups).
- replaced map containsKey checks followed by get with a get followed by
null check (prevents unnecessary lookups, and theoretically race
conditions too).
- fixed tracker misuse: when tracker callback (added) is called, the
tracker itself does not yet reflect the new state, so accessing services
(or size) on the tracker from within the callback will fail to include
the new service. Although the actual service export triggered by the
callback is performed on a separate thread, this still leaves a race
condition between the two which sometimes causes the export to fail
(with "No RemoteServiceAdmin available!" log). To fix this, the newly
added RSA is passed down the method chain to the doExportService method
explicitly. doExportService then uses the reference if it is given, or
if null (as when called from elsewhere), uses the tracker to get the
service list as it did in the past.
- fixed exportService always overwriting a service's entry in
exportedServices with a new empty data structure - now it only does so
if it does not already exist.
- fixed exportedServices inner maps to be created as synchronized maps -
previously doExportService wrapped it in a synchronized map on each
invocation, which results effectively in no synchronization, since the
synchronized wrapper map is local only so each thread accessing the map
uses a different lock. Also fixed other accesses of the inner maps to be
synchronized (Collections.synchronizedMap requires external
synchronization on it when being iterated, as specified in the docs).
- fixed exports null check in doExportService (in the old code,
Collections.synchronizedMap never returns null; In the new code it makes
more sense.)
- removed redundant remoteServiceAdminTracker null check in
doExportService (it is already used in the constructor, so can't be null
at this point).
- added cast of null to String when calling getServiceReferences in
exportExistingServices, so that it will compile also with the OSGi 4.3.0
and later API (which added an overloaded method accepting a Class). Does
not affect previous versions.
- removed removeExportRegistration, removeExportReference and
remoteAdminEvent methods, all of which are both unused and have a no-op
implementation.
Feel free to pick out the changes u like...
In addition, I had a few related questions/thoughts, I hope someone here
can help with them:
1. Is DOSGi being updated to work with OSGi 4.3.0/Felix 4.x/Karaf 2.3.x
etc.? It seems to be slightly outdated. At a glance, it looks like
making it compile against OSGi 4.3.0 requires just a few
backward-compatible syntax changes, and hopefully the semantics have not
changed too much.
2. The website says on the Karaf feature page: "CXF DOSGi does not work
with Karaf 2.3.0", however it does not mention whether this applies to
2.3.1 as well (is it a DOSGi issue or Karaf issue that prevents it from
working?), nor does it say anything about what the problem is, where it
might be relevant, or link to any issue in JIRA - could someone in the
know please update the text to be a bit more informative? Also, is this
indeed just an issue with installation via the feature, or with
compatibility between the projects/versions in general regardless of
installation method?
3. After all the fixes above, the export success rate is definitely
better than 50%, but still isn't 100% - every once in a while the export
still fails. Looking through the logs, I found the message
"RemoteServiceAdmin Implementation is shutting down now" - during Karaf
startup! I'm still not sure what exactly is going on, but 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. The initial theory
is that the dsw Activator might be getting a ConfigurationAdmin updated
event with null configuration, which would trigger a shutdown - but I
haven't yet confirmed that this is the case, nor why it would happen or
what the proper behavior in such a case should be.
I'm totally new to CXF and DOSGi (and pretty new to OSGi too), so please
forgive any silly mistakes or assumptions above... but I do hope this
will be useful in making it a better product and making it work better
out of the box :-)
Thanks to anyone who read this far!
Amichai
Re: Fwd: DOSGi - service not exported consistently
Posted by "A. Rothman" <am...@amichais.net>.
Thanks for updating the website, it's clearer now what to do.
I've opened the following issues:
https://issues.apache.org/jira/browse/DOSGI-160 - Activator shutdown
when configuration is null (includes patch)
https://issues.apache.org/jira/browse/DOSGI-161 - TopologyManager fixes
(I've split it into 3 consecutive patches to make it easier for you to
review)
https://issues.apache.org/jira/browse/DOSGI-162 - compilation errors
with newer OSGi releases (includes patch)
btw 1.4 is listed as unreleased in JIRA.
Any thoughts on the changed export URL in 1.5 snapshot (trunk)? Should I
open an issue or is this on purpose?
Do I owe you anything else or will this suffice for now?
Amichai
Re: Fwd: DOSGi - service not exported consistently
Posted by Christian Schneider <ch...@die-schneider.net>.
On 22.03.2013 12:39, A. Rothman wrote:
>
>>> 1. Is DOSGi being updated to work with OSGi 4.3.0/Felix 4.x/Karaf
>>> 2.3.x etc.? It seems to be slightly outdated. At a glance, it looks
>>> like making it compile against OSGi 4.3.0 requires just a few
>>> backward-compatible syntax changes, and hopefully the semantics have
>>> not changed too much.
>>>
>> DOSGi should work with all newer versions of Felix and Karaf. The
>> OSGI 4.3.0 spec should be compatible to 4.2.0. So this should also work.
> I'll open a separate JIRA issue for fixing the compilation errors with
> 4.3.0.
Have you tested the OSGI 4.3.1 spec from maven? It fixes some compile
errors with Java 7. This should only be a compile problem anyway. At
runtime DOSGi should not have any issues.
>>> 2. The website says on the Karaf feature page: "CXF DOSGi does not
>>> work with Karaf 2.3.0", however it does not mention whether this
>>> applies to 2.3.1 as well (is it a DOSGi issue or Karaf issue that
>>> prevents it from working?), nor does it say anything about what the
>>> problem is, where it might be relevant, or link to any issue in JIRA
>>> - could someone in the know please update the text to be a bit more
>>> informative? Also, is this indeed just an issue with installation
>>> via the feature, or with compatibility between the projects/versions
>>> in general regardless of installation method?
>>>
>> The website says "The default aegis data format will not work with
>> Apache Karaf 2.3.0. (See DOSGI-153
>> <https://issues.apache.org/jira/browse/DOSGI-153>). Please upgrade to
>> Apache Karaf 2.3.1".
> True, but I was referring to the "CXF DOSGi in Apache Karaf" feature
> page which says "CXF DOSGi does not work with Karaf 2.3.0. Please use
> the latest 2.2.x version for now." So it's even more confusing now -
> does one need to downgrade to 2.2.x or upgrade to 2.3.1? Is there a
> separate problem with the feature installation, or is it the same
> problem referred to on both pages? I think it's safer to leave a
> notice on both pages (you never know how people reach the links), but
> they should be clarified and/or updated with the latest issue links
> and workarounds.
I just tested my DOSGi tutorial with Karaf 2.3.1
(http://liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi).
It worked without any problems. I updated the page so it now recommends
to update to karaf 2.3.1. Of course DOSGi will also work with Karaf 2.2.x.
>>
>>> 3. After all the fixes above, the export success rate is definitely
>>> better than 50%, but still isn't 100% - every once in a while the
>>> export still fails. Looking through the logs, I found the message
>>> "RemoteServiceAdmin Implementation is shutting down now" - during
>>> Karaf startup! I'm still not sure what exactly is going on, but 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.
>>> The initial theory is that the dsw Activator might be getting a
>>> ConfigurationAdmin updated event with null configuration, which
>>> would trigger a shutdown - but I haven't yet confirmed that this is
>>> the case, nor why it would happen or what the proper behavior in
>>> such a case should be.
>> I have not yet seen this problem. If you can find a way to reproduce
>> it I would be very interested in your findings.
> I'm not sure how to reproduce it in a test case, though it happens
> quite often in my project (Karaf 2.3.1 with activemq 5.8.0 and DOSGi
> 1.4.0 installed from their respective features), with a handful of
> custom bundles which use a trivial/default DOSGi configuration. The
> only interesting thing I can think of about them is that some of them
> register their exported services asynchronously when their dependent
> services and internal state are all up and running, as opposed to
> registering in the bundle start method like some simple bundle
> examples do - but I really don't know if this is related. In any case
> I'll open a separate JIRA issue for this with the findings and patch
> from my previous post.
Thanks.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Fwd: DOSGi - service not exported consistently
Posted by "A. Rothman" <am...@amichais.net>.
>> 1. Is DOSGi being updated to work with OSGi 4.3.0/Felix 4.x/Karaf
>> 2.3.x etc.? It seems to be slightly outdated. At a glance, it looks
>> like making it compile against OSGi 4.3.0 requires just a few
>> backward-compatible syntax changes, and hopefully the semantics have
>> not changed too much.
>>
> DOSGi should work with all newer versions of Felix and Karaf. The OSGI
> 4.3.0 spec should be compatible to 4.2.0. So this should also work.
I'll open a separate JIRA issue for fixing the compilation errors with
4.3.0.
>> 2. The website says on the Karaf feature page: "CXF DOSGi does not
>> work with Karaf 2.3.0", however it does not mention whether this
>> applies to 2.3.1 as well (is it a DOSGi issue or Karaf issue that
>> prevents it from working?), nor does it say anything about what the
>> problem is, where it might be relevant, or link to any issue in JIRA
>> - could someone in the know please update the text to be a bit more
>> informative? Also, is this indeed just an issue with installation via
>> the feature, or with compatibility between the projects/versions in
>> general regardless of installation method?
>>
> The website says "The default aegis data format will not work with
> Apache Karaf 2.3.0. (See DOSGI-153
> <https://issues.apache.org/jira/browse/DOSGI-153>). Please upgrade to
> Apache Karaf 2.3.1".
True, but I was referring to the "CXF DOSGi in Apache Karaf" feature
page which says "CXF DOSGi does not work with Karaf 2.3.0. Please use
the latest 2.2.x version for now." So it's even more confusing now -
does one need to downgrade to 2.2.x or upgrade to 2.3.1? Is there a
separate problem with the feature installation, or is it the same
problem referred to on both pages? I think it's safer to leave a notice
on both pages (you never know how people reach the links), but they
should be clarified and/or updated with the latest issue links and
workarounds.
>
>> 3. After all the fixes above, the export success rate is definitely
>> better than 50%, but still isn't 100% - every once in a while the
>> export still fails. Looking through the logs, I found the message
>> "RemoteServiceAdmin Implementation is shutting down now" - during
>> Karaf startup! I'm still not sure what exactly is going on, but 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. The
>> initial theory is that the dsw Activator might be getting a
>> ConfigurationAdmin updated event with null configuration, which would
>> trigger a shutdown - but I haven't yet confirmed that this is the
>> case, nor why it would happen or what the proper behavior in such a
>> case should be.
> I have not yet seen this problem. If you can find a way to reproduce
> it I would be very interested in your findings.
I'm not sure how to reproduce it in a test case, though it happens quite
often in my project (Karaf 2.3.1 with activemq 5.8.0 and DOSGi 1.4.0
installed from their respective features), with a handful of custom
bundles which use a trivial/default DOSGi configuration. The only
interesting thing I can think of about them is that some of them
register their exported services asynchronously when their dependent
services and internal state are all up and running, as opposed to
registering in the bundle start method like some simple bundle examples
do - but I really don't know if this is related. In any case I'll open a
separate JIRA issue for this with the findings and patch from my
previous post.
Re: Fwd: DOSGi - service not exported consistently
Posted by Christian Schneider <ch...@die-schneider.net>.
On 20.03.2013 19:25, A. Rothman wrote:
>
> [The message body disappeared for some reason, resending...]
>
>
> Hi,
>
> While trying to use DOSGi (1.4.0, in Karaf 2.3.1) I came across some
> serious issues, namely when starting up a fresh Karaf instance
> repeatedly, only about 50% of the time the service actually got
> exported (as verified with a browser pointing to the appropriate WSDL
> URL). This is just on a single instance on a local host, before trying
> to do anything remotely. I started investigating into the matter,
> which required quite a lot of debugging and code reviewing, and found
> various issues with the (strangely named?) TopologyManagerExport class
> which seems to be at the heart of the matter. This took several
> iterations and includes also non-critical cleanups I did along the way
> - I'm attaching the final version I arrived at which hopefully
> addresses the issues, though due to the law of clustering of bugs, I
> wouldn't be surprised if there are other new or old bugs still lurking
> there... any feedback and additional code reviews would be greatly
> appreciated.
>
> Here is a summary of all the changes, big and small:
>
> - fixed typos in docs and logs.
> - fixed formatting to be more consistent and readable.
> - added debug logs to
> RemoteServiceAdminLifeCycleListener.added/removed callbacks (this
> proved the serious tracker bug below, but is also useful for general
> debugging).
> - simplified shouldExportService returned boolean expression.
> - replaced iterations on map keys followed by a get of the
> corresponding value with an iteration on Map.Entry (prevents
> unnecessary lookups).
> - replaced map containsKey checks followed by get with a get followed
> by null check (prevents unnecessary lookups, and theoretically race
> conditions too).
> - fixed tracker misuse: when tracker callback (added) is called, the
> tracker itself does not yet reflect the new state, so accessing
> services (or size) on the tracker from within the callback will fail
> to include the new service. Although the actual service export
> triggered by the callback is performed on a separate thread, this
> still leaves a race condition between the two which sometimes causes
> the export to fail (with "No RemoteServiceAdmin available!" log). To
> fix this, the newly added RSA is passed down the method chain to the
> doExportService method explicitly. doExportService then uses the
> reference if it is given, or if null (as when called from elsewhere),
> uses the tracker to get the service list as it did in the past.
> - fixed exportService always overwriting a service's entry in
> exportedServices with a new empty data structure - now it only does so
> if it does not already exist.
> - fixed exportedServices inner maps to be created as synchronized maps
> - previously doExportService wrapped it in a synchronized map on each
> invocation, which results effectively in no synchronization, since the
> synchronized wrapper map is local only so each thread accessing the
> map uses a different lock. Also fixed other accesses of the inner maps
> to be synchronized (Collections.synchronizedMap requires external
> synchronization on it when being iterated, as specified in the docs).
> - fixed exports null check in doExportService (in the old code,
> Collections.synchronizedMap never returns null; In the new code it
> makes more sense.)
> - removed redundant remoteServiceAdminTracker null check in
> doExportService (it is already used in the constructor, so can't be
> null at this point).
> - added cast of null to String when calling getServiceReferences in
> exportExistingServices, so that it will compile also with the OSGi
> 4.3.0 and later API (which added an overloaded method accepting a
> Class). Does not affect previous versions.
> - removed removeExportRegistration, removeExportReference and
> remoteAdminEvent methods, all of which are both unused and have a
> no-op implementation.
>
> Feel free to pick out the changes u like...
>
> In addition, I had a few related questions/thoughts, I hope someone
> here can help with them:
>
> 1. Is DOSGi being updated to work with OSGi 4.3.0/Felix 4.x/Karaf
> 2.3.x etc.? It seems to be slightly outdated. At a glance, it looks
> like making it compile against OSGi 4.3.0 requires just a few
> backward-compatible syntax changes, and hopefully the semantics have
> not changed too much.
>
DOSGi should work with all newer versions of Felix and Karaf. The OSGI
4.3.0 spec should be compatible to 4.2.0. So this should also work.
> 2. The website says on the Karaf feature page: "CXF DOSGi does not
> work with Karaf 2.3.0", however it does not mention whether this
> applies to 2.3.1 as well (is it a DOSGi issue or Karaf issue that
> prevents it from working?), nor does it say anything about what the
> problem is, where it might be relevant, or link to any issue in JIRA -
> could someone in the know please update the text to be a bit more
> informative? Also, is this indeed just an issue with installation via
> the feature, or with compatibility between the projects/versions in
> general regardless of installation method?
>
The website says "The default aegis data format will not work with
Apache Karaf 2.3.0. (See DOSGI-153
<https://issues.apache.org/jira/browse/DOSGI-153>). Please upgrade to
Apache Karaf 2.3.1".
> 3. After all the fixes above, the export success rate is definitely
> better than 50%, but still isn't 100% - every once in a while the
> export still fails. Looking through the logs, I found the message
> "RemoteServiceAdmin Implementation is shutting down now" - during
> Karaf startup! I'm still not sure what exactly is going on, but 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. The
> initial theory is that the dsw Activator might be getting a
> ConfigurationAdmin updated event with null configuration, which would
> trigger a shutdown - but I haven't yet confirmed that this is the
> case, nor why it would happen or what the proper behavior in such a
> case should be.
I have not yet seen this problem. If you can find a way to reproduce it
I would be very interested in your findings.
>
> I'm totally new to CXF and DOSGi (and pretty new to OSGi too), so
> please forgive any silly mistakes or assumptions above... but I do
> hope this will be useful in making it a better product and making it
> work better out of the box :-)
Many thanks for your efforts already. It will take a while to work
through your changes and test them. I will take a look as soon as they
are in jira so we can properly track them. For the future it would be
great if you could separate changes into smaller chunks and create
individual jira issues for each. This way it is easier to work through
the changes ... and it also gives you more visibility if you want to
become a committer ;-)
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Fwd: DOSGi - service not exported consistently
Posted by Christian Schneider <ch...@die-schneider.net>.
Can you open a jira issue to track this and attach the patch there?
Christian
On 20.03.2013 19:25, A. Rothman wrote:
>
> [The message body disappeared for some reason, resending...]
>
>
> Hi,
>
> While trying to use DOSGi (1.4.0, in Karaf 2.3.1) I came across some
> serious issues, namely when starting up a fresh Karaf instance
> repeatedly, only about 50% of the time the service actually got
> exported (as verified with a browser pointing to the appropriate WSDL
> URL). This is just on a single instance on a local host, before trying
> to do anything remotely. I started investigating into the matter,
> which required quite a lot of debugging and code reviewing, and found
> various issues with the (strangely named?) TopologyManagerExport class
> which seems to be at the heart of the matter. This took several
> iterations and includes also non-critical cleanups I did along the way
> - I'm attaching the final version I arrived at which hopefully
> addresses the issues, though due to the law of clustering of bugs, I
> wouldn't be surprised if there are other new or old bugs still lurking
> there... any feedback and additional code reviews would be greatly
> appreciated.
>
> Here is a summary of all the changes, big and small:
>
> - fixed typos in docs and logs.
> - fixed formatting to be more consistent and readable.
> - added debug logs to
> RemoteServiceAdminLifeCycleListener.added/removed callbacks (this
> proved the serious tracker bug below, but is also useful for general
> debugging).
> - simplified shouldExportService returned boolean expression.
> - replaced iterations on map keys followed by a get of the
> corresponding value with an iteration on Map.Entry (prevents
> unnecessary lookups).
> - replaced map containsKey checks followed by get with a get followed
> by null check (prevents unnecessary lookups, and theoretically race
> conditions too).
> - fixed tracker misuse: when tracker callback (added) is called, the
> tracker itself does not yet reflect the new state, so accessing
> services (or size) on the tracker from within the callback will fail
> to include the new service. Although the actual service export
> triggered by the callback is performed on a separate thread, this
> still leaves a race condition between the two which sometimes causes
> the export to fail (with "No RemoteServiceAdmin available!" log). To
> fix this, the newly added RSA is passed down the method chain to the
> doExportService method explicitly. doExportService then uses the
> reference if it is given, or if null (as when called from elsewhere),
> uses the tracker to get the service list as it did in the past.
> - fixed exportService always overwriting a service's entry in
> exportedServices with a new empty data structure - now it only does so
> if it does not already exist.
> - fixed exportedServices inner maps to be created as synchronized maps
> - previously doExportService wrapped it in a synchronized map on each
> invocation, which results effectively in no synchronization, since the
> synchronized wrapper map is local only so each thread accessing the
> map uses a different lock. Also fixed other accesses of the inner maps
> to be synchronized (Collections.synchronizedMap requires external
> synchronization on it when being iterated, as specified in the docs).
> - fixed exports null check in doExportService (in the old code,
> Collections.synchronizedMap never returns null; In the new code it
> makes more sense.)
> - removed redundant remoteServiceAdminTracker null check in
> doExportService (it is already used in the constructor, so can't be
> null at this point).
> - added cast of null to String when calling getServiceReferences in
> exportExistingServices, so that it will compile also with the OSGi
> 4.3.0 and later API (which added an overloaded method accepting a
> Class). Does not affect previous versions.
> - removed removeExportRegistration, removeExportReference and
> remoteAdminEvent methods, all of which are both unused and have a
> no-op implementation.
>
> Feel free to pick out the changes u like...
>
> In addition, I had a few related questions/thoughts, I hope someone
> here can help with them:
>
> 1. Is DOSGi being updated to work with OSGi 4.3.0/Felix 4.x/Karaf
> 2.3.x etc.? It seems to be slightly outdated. At a glance, it looks
> like making it compile against OSGi 4.3.0 requires just a few
> backward-compatible syntax changes, and hopefully the semantics have
> not changed too much.
>
> 2. The website says on the Karaf feature page: "CXF DOSGi does not
> work with Karaf 2.3.0", however it does not mention whether this
> applies to 2.3.1 as well (is it a DOSGi issue or Karaf issue that
> prevents it from working?), nor does it say anything about what the
> problem is, where it might be relevant, or link to any issue in JIRA -
> could someone in the know please update the text to be a bit more
> informative? Also, is this indeed just an issue with installation via
> the feature, or with compatibility between the projects/versions in
> general regardless of installation method?
>
> 3. After all the fixes above, the export success rate is definitely
> better than 50%, but still isn't 100% - every once in a while the
> export still fails. Looking through the logs, I found the message
> "RemoteServiceAdmin Implementation is shutting down now" - during
> Karaf startup! I'm still not sure what exactly is going on, but 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. The
> initial theory is that the dsw Activator might be getting a
> ConfigurationAdmin updated event with null configuration, which would
> trigger a shutdown - but I haven't yet confirmed that this is the
> case, nor why it would happen or what the proper behavior in such a
> case should be.
>
> I'm totally new to CXF and DOSGi (and pretty new to OSGi too), so
> please forgive any silly mistakes or assumptions above... but I do
> hope this will be useful in making it a better product and making it
> work better out of the box :-)
>
> Thanks to anyone who read this far!
>
> Amichai
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Fwd: DOSGi - service not exported consistently
Posted by "A. Rothman" <am...@amichais.net>.
> 3. After all the fixes above, the export success rate is definitely
> better than 50%, but still isn't 100% - every once in a while the
> export still fails. Looking through the logs, I found the message
> "RemoteServiceAdmin Implementation is shutting down now" - during
> Karaf startup! I'm still not sure what exactly is going on, but 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. The
> initial theory is that the dsw Activator might be getting a
> ConfigurationAdmin updated event with null configuration, which would
> trigger a shutdown - but I haven't yet confirmed that this is the
> case, nor why it would happen or what the proper behavior in such a
> case should be.
Following up on this, the config updated callback was indeed the
problem. There's also a race condition in the class that can cause
trouble, and an endless loop bug when the configuration does change...
attached is a fix for the issues I've found - again, I'm new to all
this, so please correct anything I've missed.
These are the changes:
- 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 managed
service, which re-triggers update, which calls start etc. ad infinitum
- synchronized init/uninit/update (since update is called from another
thread and so init/uninit may be called concurrently with undefined results
- fixed updated callback shutting down service right after it starts
(when config is null), causing service exports to fail sometimes
- added proper unregistering of managed service
- added a few debug logs to help follow the sequence of events
Also, if there's anything else I should do to get these patches accepted
and committed for the next release, please let me know!
p.s.
Sometime between 1.4 and 1.5-SNAPSHOT it appears the default exported
service urls (with -> without "cxf" prefix) and ports (8181 -> 9000)
have changed - is this on purpose? Actually, there are two different
default configurations in two different places, HttpServiceManager and
Pojo something, and now one of them is used instead of the other.
Perhaps they should be rearranged to make it clear how and when each is
used.