Dan, Each bundle should be responsible for stopping any threads that it has started itself, and it should do this from its BundleActivator.stop() callback method (or if you have used DS, from the deactivate methods, etc). The management agent should not care about bundle threads -- that is an implementation detail that the agent should know nothing about. It should just call Bundle.stop().
With respect to when the thread has to stop, think about it the other way around... what if you never stop any threads? This would mean that objects allocated by the thread do not become candidates for garbage collection; therefore neither do the classes that define those objects; therefore, neither do the classloaders that loaded those classes. So you're going to create a lot of garbage on the heap, eventually resulting in OOME. Also, if a bundle's thread continues running after the bundle has been stopped/updated then you could get unexpected exceptions occurring in that thread; e.g. the bundle classloader might not allow any new classes to be loaded, and calls into OSGi using your BundleContext will probably throw IllegalStateException. Generally these exceptions are not harmful since you wanted the thread to die anyway, but they could cause confusion if written to a log. Therefore from a pure Java/OSGi standpoint it doesn't really matter whether the threads stop before or after update, so long as they do eventually stop. However a bigger problem is likely to be the internal logic of the bundles... is it able to cope with two copies running simultaneously? For example if you access a resource such as file, can you cope with "somebody else" (actually, an old undead copy of yourself!) accessing the same resource at the same time? I hope this helps, Neil On Tue, May 14, 2013 at 12:17 PM, Dan Gravell <[email protected]> wrote: > Hi all. After giving it about a year of tweaks, I'm finally going to give > up trying to update my OSGi app in process. The killer is the requirement > to stop all threads... for my particular requirements this just isn't > feasible. I have to maintain my own forks of projects, some complex (the > Lift web framework) and some less so (JNotify) and this just takes too long. > > So I'm putting thought to how I can structure a solution that restarts the > JVM *at some point*. I am using Felix 'bundlerepository' bundle to perform > the deployments of bundles. > > So first, the requirement to stop threads: is this a requirement *before* > start(), stop() or update(URL) is called? > > If it's only something that has to be done before stop() then I _could_ do > everything I do now, up to when start() is called on each bundle. At that > point, I could exit with an exit code and my launcher script checks that > and, if it's a known value, restarts the same process. In this case, I > would have to re-start the bundles on restart. > > If threads have to be stopped before the update itself, then I suppose I > can download the bundles to a holding area, and have a bootstrap JVM that > picks them up and somehow performs the update, and then starts. > > If anyone has any wisdom or experience of this I would be grateful to hear > it... > > Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
