felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Giving up on in process update... suggestions for how to structure separate JVM update?
Date Tue, 14 May 2013 13:38:07 GMT

On 5/14/13 09:35 , Richard S. Hall wrote:
> On 5/14/13 09:24 , Dan Gravell wrote:
>> Thanks Richard.
>>
>> Are start levels not... "bad"... from a conceptual point of view? Or, in
>> this case, where start levels are used to separate "layers" (the 
>> management
>> layer from the application layer) are they deemed ok?
>
> This is pretty much why start levels exist, but regardless, we are 
> talking about restarting the JVM because you have bundles that won't 
> behave, so I think adding start levels doesn't really further soil the 
> situation. :-)

To further clarify, start levels are not intended as a poor man's 
approach to ordering bundle start up, since you shouldn't care about the 
order in which bundles start. Using start levels for coarse grained 
"mode" management is not unreasonable, but you shouldn't do much more 
than that.

-> richard

>
> -> richard
>
>> Dan
>>
>>
>> On Tue, May 14, 2013 at 2:07 PM, Richard S. Hall 
>> <heavy@ungoverned.org>wrote:
>>
>>> The simplest approach is once you decide some sort of restart is 
>>> needed,
>>> just stop the framework JVM and have your launcher relaunch it in 
>>> "update
>>> mode" which would be a low start level in which no bundles but your
>>> "management" bundle can execute.
>>>
>>> In this mode, you know no other bundles have started, so your 
>>> management
>>> bundle can do whatever updates it wants, call refresh, then change the
>>> start level to enter normal operating mode when it is done.
>>>
>>> -> richard
>>>
>>>
>>> On 5/14/13 07:17 , Dan Gravell 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: 
>>> users-unsubscribe@felix.**apache.org<users-unsubscribe@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message