Thanks to all of you for the insights.
From the responses I take that clean shutdown is not in scope of OSGi
itself.
I agree that it is best solved on the application level. On the other
hand I see that the Quiesce API can at least cover some
cases and so it has its values.
Christian
Am 13.02.2015 um 17:55 schrieb Raymond Auge:
To my knowledge what you are speaking of is not intentionally
supported by the dynamics of osgi. This topic comes up all the time,
it's funny.
If you must support "in flight" changes, then you have to implement
this support in your code using concurrency constructs.
Note that unregistering a service is a synchronous operation during
"shutdown" of a bundle, and so with proper concurrency measures in
place, a bundle could both be shutting down (meaning it's not
reachable by other bundles) and also finishing any ongoing work.
Anyone feel free to correct me but this is what I've learned in my
short experience.
- Ray
On Fri, Feb 13, 2015 at 11:37 AM, Christian Schneider
<[email protected] <mailto:[email protected]>> wrote:
I had a longer discussion with Guillaume Nodet about how to shut
down bundles cleanly. The main question was if you can cleanly
shut down bundles with just the OSGi APIs or if we are missing
something.
So the thing to define is: what does clean shutdown mean? Clean
would refer to the fact that none of the inflight calls the bundle
processes are disturbed.
Case A
So what could happen. In the simplest case a bundle might simply
process a long running service call.
1. The call started before the bundle was stopped
2. Then the bundle is stopped
3. The bundle is refreshed or uninstalled
4. At some later point the call finishes
So what happens with the inflight call after 3?
Can the running thread still work normally?
One issue that might arise is that during stop the bundle might
have shut down some needed resources. This is in control of the
developer, so I think it should be no big issue.
The question though is what happens to the Classloader of the bundle?
The stop operation should be no problem here but what about
refresh, update or uninstall? Does this old classloader still work
then?
If the classloader does not work anymore how should this case be
handled?
Does the bundle have to make sure all inflight processing is done
before stop is finished?
Case B
This could be even more complex when you have chained service calls.
Service A1 in bundle A calls service B1 in bundle B
1. Service call in A1 starts processing
2 Bundle B is stopped
3. bundle B is uninstalled
3. Service A1 tries to call service B
For blueprint I know that the call to service B will block because
of the service damping.
What happens in DS here? Normally DS would stop Service A1 when
the Service B1 disappears but the call to service A1 already started.
I think that in this case Service A1 will still have an instance
of B1 injected. So the call to B1 will probably happen, even if B1
was uninstalled in the mean time.
So I think we might have the same classloader issue as in the
first case. The problem is though that bundle B cannot defer
stopping because it does not see an inflight call at the point
where it stops.
I think one solution to avoid Case B could be to stop bundles
according to their service dependencies. So you would first stop
bundle B then bundle A. Is this the recommended solution? Is this
already automated in OSGi in some way?
Case C
An even more complicated case is when one or more extenders are
involved that create services on behalf of the bundles. Are there
any best practices around this?
I have seen that there is the Quiesce API in aries that seems to
cover shutting down bundles when extenders are involved.
See
https://github.com/apache/aries/blob/trunk/quiesce/quiesce-api/src/main/java/org/apache/aries/quiesce/participant/QuiesceParticipant.java
The API seems to be aries specific though. Is something like that
necessary or should plain OSGi APIs offer enough flexibility for
this case too?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
