You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Dan Gravell <da...@elstensoftware.com> on 2013/05/14 13:17:06 UTC
Giving up on in process update... suggestions for how to structure
separate JVM update?
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
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/14/13 09:43 , Neil Bartlett wrote:
> I think that as an alternative approach to using start levels, you
> could use transient starting.
>
> If (a) the management agent is the only bundle that ever starts
> bundles besides itself, and (b) it always starts them transiently,
> i.e. with Bundle.START_TRANSIENT, then you can be sure the management
> agent will be the only bundle running after a framework restart.
Yes, that is a similar approach. The main thing you want to achieve is
to have the management bundle do its work before any other bundle gets
started.
-> richard
>
> Neil
>
> On Tue, May 14, 2013 at 2:39 PM, Dan Gravell <da...@elstensoftware.com> wrote:
>> Gotcha, thanks.
>>
>>
>> On Tue, May 14, 2013 at 2:38 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>>
>>> 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.**apac**he.org<http://apache.org>
>>>>>> <us...@felix.apache.org>
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Ah yes, I see. I wasn't actually aware of START_TRANSIENT before, and a lot
of head scratching in this area was how to cope with bundle state between
invocations. Thanks.
On Tue, May 14, 2013 at 2:43 PM, Neil Bartlett <nj...@gmail.com> wrote:
> I think that as an alternative approach to using start levels, you
> could use transient starting.
>
> If (a) the management agent is the only bundle that ever starts
> bundles besides itself, and (b) it always starts them transiently,
> i.e. with Bundle.START_TRANSIENT, then you can be sure the management
> agent will be the only bundle running after a framework restart.
>
> Neil
>
> On Tue, May 14, 2013 at 2:39 PM, Dan Gravell <da...@elstensoftware.com>
> wrote:
> > Gotcha, thanks.
> >
> >
> > On Tue, May 14, 2013 at 2:38 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
> >
> >>
> >> 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.**apac**he.org<
> http://apache.org>
> >>>>> <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<
> 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
>
>
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Neil Bartlett <nj...@gmail.com>.
I think that as an alternative approach to using start levels, you
could use transient starting.
If (a) the management agent is the only bundle that ever starts
bundles besides itself, and (b) it always starts them transiently,
i.e. with Bundle.START_TRANSIENT, then you can be sure the management
agent will be the only bundle running after a framework restart.
Neil
On Tue, May 14, 2013 at 2:39 PM, Dan Gravell <da...@elstensoftware.com> wrote:
> Gotcha, thanks.
>
>
> On Tue, May 14, 2013 at 2:38 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>>
>> 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.**apac**he.org<http://apache.org>
>>>>> <us...@felix.apache.org>
>>>>> >
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Gotcha, thanks.
On Tue, May 14, 2013 at 2:38 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
> 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.**apac**he.org<http://apache.org>
>>>> <us...@felix.apache.org>
>>>> >
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>> <he...@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<us...@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
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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. :-)
-> richard
> Dan
>
>
> On Tue, May 14, 2013 at 2:07 PM, Richard S. Hall <he...@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<us...@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
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
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?
Dan
On Tue, May 14, 2013 at 2:07 PM, Richard S. Hall <he...@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<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Thanks. I think I'm going to try this "restart in update mode" approach.
Dan
On Tue, May 14, 2013 at 2:40 PM, Neil Bartlett <nj...@gmail.com> wrote:
> On Tue, May 14, 2013 at 2:16 PM, Dan Gravell <da...@elstensoftware.com>
> wrote:
> > Neil,
> >
> > 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().
> >>
> >
> > Ok, so it's not safe to update() a stop()ped bundle which has threads
> still
> > running that it started itself? That means the update process would have
> to
> > occur in a separate JVM invocation.
>
> "Safe" is relative ;-)
>
> As I tried to explain in my previous email, the old bundle's classes
> and classloader will probably be pinned in memory, so you will have a
> memory leak. Also possibly the resource clashes that I talked about
> (but you could also have these if you had another copy of the same JVM
> process running).
>
> >> 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.
> >>
> >
> > Just to be clear: you're preaching to the converted, I understand why the
> > threads should be stopped. The issue is that I am re-using other projects
> > that don't conform to these rules.... projects that were never written as
> > OSGi bundles. It's a bit like the class loading assumptions you see in
> > other projects... except arguably more subtle.
> >
> > For "teh google", what I commonly see are NullPointerExceptions
> (example):
> >
> > java.lang.NullPointerException
> > at
> >
> org.apache.felix.framework.BundleRevisionImpl.calculateContentPath(BundleRevisionImpl.java:410)
> > at
> >
> org.apache.felix.framework.BundleRevisionImpl.initializeContentPath(BundleRevisionImpl.java:347)
> > at
> >
> org.apache.felix.framework.BundleRevisionImpl.getContentPath(BundleRevisionImpl.java:333)
> > at
> >
> org.apache.felix.framework.BundleRevisionImpl.getResourceLocal(BundleRevisionImpl.java:472)
> > at
> >
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
> > at
> >
> org.apache.felix.framework.BundleWiringImpl.getResourceByDelegation(BundleWiringImpl.java:1360)
> > at
> >
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.getResource(BundleWiringImpl.java:2256)
> >
> > Also in JNotify's case threads are started in the static initalizers and
> it
> > means the native code ends up calling incorrect listeners in the bundle,
> > meaning file notifications are missing. I believe Ferry Huberts wrote a
> > port for the Linux part of JNotify, but I also need to support OS X and
> > Windows.
> >
> > I also see various stack traces in static initalizers... ImageIO is a
> > particular favourite:
> >
> > java.lang.NullPointerException
> > at
> >
> org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:510)
> > at
> >
> org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1127)
> > at
> >
> org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1037)
> > at
> >
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1778)
> > at
> >
> org.eclipse.jetty.osgi.boot.internal.webapp.OSGiWebappClassLoader.getResources(OSGiWebappClassLoader.java:115)
> > at
> > java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:340)
> > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:432)
> > at
> >
> javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:206)
> > at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:138)
> > at
> > javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:159)
> > at javax.imageio.ImageIO.<clinit>(ImageIO.java:64)
> >
> > These are often threads started *after* an update, by *updated* bundles.
> > But conversations with Richard S Hall before suggested the underlying
> cause
> > of the problems were threads that were still running at update.
> >
> > Anyway, the point is I have devoted quite a lot of time to trying to iron
> > these kinks out and I'm not getting that far, so I want to go back to
> > something I think will work.
> >
> > 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?
> >>
> >
> > Thanks, what you wrote helps me understand the fundamental point. I and
> my
> > users are certainly seeing problems (some examples above) after the
> update,
> > and if the threads are the cause, and I can't expediently stop them
> > (expedience in terms of development time), that's why I'll go for the JVM
> > restart.
> >
> > Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Neil Bartlett <nj...@gmail.com>.
On Tue, May 14, 2013 at 2:16 PM, Dan Gravell <da...@elstensoftware.com> wrote:
> Neil,
>
> 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().
>>
>
> Ok, so it's not safe to update() a stop()ped bundle which has threads still
> running that it started itself? That means the update process would have to
> occur in a separate JVM invocation.
"Safe" is relative ;-)
As I tried to explain in my previous email, the old bundle's classes
and classloader will probably be pinned in memory, so you will have a
memory leak. Also possibly the resource clashes that I talked about
(but you could also have these if you had another copy of the same JVM
process running).
>> 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.
>>
>
> Just to be clear: you're preaching to the converted, I understand why the
> threads should be stopped. The issue is that I am re-using other projects
> that don't conform to these rules.... projects that were never written as
> OSGi bundles. It's a bit like the class loading assumptions you see in
> other projects... except arguably more subtle.
>
> For "teh google", what I commonly see are NullPointerExceptions (example):
>
> java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleRevisionImpl.calculateContentPath(BundleRevisionImpl.java:410)
> at
> org.apache.felix.framework.BundleRevisionImpl.initializeContentPath(BundleRevisionImpl.java:347)
> at
> org.apache.felix.framework.BundleRevisionImpl.getContentPath(BundleRevisionImpl.java:333)
> at
> org.apache.felix.framework.BundleRevisionImpl.getResourceLocal(BundleRevisionImpl.java:472)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
> at
> org.apache.felix.framework.BundleWiringImpl.getResourceByDelegation(BundleWiringImpl.java:1360)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.getResource(BundleWiringImpl.java:2256)
>
> Also in JNotify's case threads are started in the static initalizers and it
> means the native code ends up calling incorrect listeners in the bundle,
> meaning file notifications are missing. I believe Ferry Huberts wrote a
> port for the Linux part of JNotify, but I also need to support OS X and
> Windows.
>
> I also see various stack traces in static initalizers... ImageIO is a
> particular favourite:
>
> java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:510)
> at
> org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1127)
> at
> org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1037)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1778)
> at
> org.eclipse.jetty.osgi.boot.internal.webapp.OSGiWebappClassLoader.getResources(OSGiWebappClassLoader.java:115)
> at
> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:340)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:432)
> at
> javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:206)
> at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:138)
> at
> javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:159)
> at javax.imageio.ImageIO.<clinit>(ImageIO.java:64)
>
> These are often threads started *after* an update, by *updated* bundles.
> But conversations with Richard S Hall before suggested the underlying cause
> of the problems were threads that were still running at update.
>
> Anyway, the point is I have devoted quite a lot of time to trying to iron
> these kinks out and I'm not getting that far, so I want to go back to
> something I think will work.
>
> 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?
>>
>
> Thanks, what you wrote helps me understand the fundamental point. I and my
> users are certainly seeing problems (some examples above) after the update,
> and if the threads are the cause, and I can't expediently stop them
> (expedience in terms of development time), that's why I'll go for the JVM
> restart.
>
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by Ferry Huberts <ma...@hupie.com>.
On 14/05/13 16:46, Dan Gravell wrote:
> Hmmmm, sorry, don't want to misrepresent things... In neither case do you
> *explicitly* start threads.
>
> JNotify's threads are started by the class initialisers... so load the
> class (as you do when you add a 'watch' via a static method for a
> directory) and the thread starts.
My fork doesn't do that and has proper activators and deactivators.
You might be interested in it and add Mac and Windblows support???
>
> Lift's are started as part of its HTTP request handling. I managed to patch
> it to stop all the threads upon shutdown of its surrounding servlet
> container (I use Jetty) but this is just code I will have to maintain going
> forward with new releases.
>
> Neither behaviour is particularly desirable but JNotify's age and lack of
> committers and Lift's usage scenarios are probably good reasons why the
> respective projects' resources are not spent on fixing this.
>
> Dan
>
>
> On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <nj...@gmail.com> wrote:
>
>> So, they give you API to start a bunch of threads, but not stop them?
>> Awesome...
>>
>> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <da...@elstensoftware.com>
>> wrote:
>>> In one case (JNotify) I create straight wrappers so the JARs are
>>> 'OSGi-ified', in another case I have the JARs embedded in the bundle that
>>> uses them (Lift).
>>>
>>> Adding the bundle activator might work if the support to shutdown the
>>> threads is in the API for the code I am using. However, it isn't, and as
>>> you know Java threads are co-operative so I can't simply stop them.
>>>
>>> Dan
>>>
>>>
>>> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fmeschbe@adobe.com
>>> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Just to be clear: you're preaching to the converted, I understand why
>> the
>>>>> threads should be stopped. The issue is that I am re-using other
>> projects
>>>>> that don't conform to these rules.... projects that were never
>> written as
>>>>> OSGi bundles. It's a bit like the class loading assumptions you see in
>>>>> other projects... except arguably more subtle.
>>>>
>>>> So you are using libraries which are not built with OSGi in mind. Still
>>>> you need OSGi manifests for the libraries to become bundles. So you at
>>>> least wrap the libraries somehow to generate the manifest.
>>>>
>>>> How about adding a BundleActivator as part of this manifest generation ?
>>>> That BundleActivator could in the stop method stop any running threads.
>> The
>>>> BundleActivator is part of the bundle so it may be aware of the library
>>>> internals and be able to stop any running threads.
>>>>
>>>> Regards
>>>> Felix
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: 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
>>
>>
>
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Considered that too... the trouble with that is OS X support. It would mean
having to install a Java runtime as part of an 'installation' process. On
OS X right now it's as simple as running a .app 'bundle' (overloaded term!)
inside a DMG. If Java 6 isn't installed already, OS X does the work of
installing for you. I sell my software, and I need as low a friction
solution as possible.
Dan
On Tue, May 14, 2013 at 3:52 PM, Bruce Jackson <br...@inqmobile.com> wrote:
> I'd remove JNotify and replace it with the new filesystem classes in J2SE
> 7. That way you'll be able to sort out the thread management yourself.
>
>
> On 14 May 2013, at 15:46, Dan Gravell <da...@elstensoftware.com> wrote:
>
> > Hmmmm, sorry, don't want to misrepresent things... In neither case do you
> > *explicitly* start threads.
> >
> > JNotify's threads are started by the class initialisers... so load the
> > class (as you do when you add a 'watch' via a static method for a
> > directory) and the thread starts.
> >
> > Lift's are started as part of its HTTP request handling. I managed to
> patch
> > it to stop all the threads upon shutdown of its surrounding servlet
> > container (I use Jetty) but this is just code I will have to maintain
> going
> > forward with new releases.
> >
> > Neither behaviour is particularly desirable but JNotify's age and lack of
> > committers and Lift's usage scenarios are probably good reasons why the
> > respective projects' resources are not spent on fixing this.
> >
> > Dan
> >
> >
> > On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <nj...@gmail.com>
> wrote:
> >
> >> So, they give you API to start a bunch of threads, but not stop them?
> >> Awesome...
> >>
> >> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <da...@elstensoftware.com>
> >> wrote:
> >>> In one case (JNotify) I create straight wrappers so the JARs are
> >>> 'OSGi-ified', in another case I have the JARs embedded in the bundle
> that
> >>> uses them (Lift).
> >>>
> >>> Adding the bundle activator might work if the support to shutdown the
> >>> threads is in the API for the code I am using. However, it isn't, and
> as
> >>> you know Java threads are co-operative so I can't simply stop them.
> >>>
> >>> Dan
> >>>
> >>>
> >>> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fmeschbe@adobe.com
> >>> wrote:
> >>>
> >>>> Hi Dan,
> >>>>
> >>>> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
> >>>>
> >>>>>> 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.
> >>>>>>
> >>>>>
> >>>>> Just to be clear: you're preaching to the converted, I understand why
> >> the
> >>>>> threads should be stopped. The issue is that I am re-using other
> >> projects
> >>>>> that don't conform to these rules.... projects that were never
> >> written as
> >>>>> OSGi bundles. It's a bit like the class loading assumptions you see
> in
> >>>>> other projects... except arguably more subtle.
> >>>>
> >>>> So you are using libraries which are not built with OSGi in mind.
> Still
> >>>> you need OSGi manifests for the libraries to become bundles. So you at
> >>>> least wrap the libraries somehow to generate the manifest.
> >>>>
> >>>> How about adding a BundleActivator as part of this manifest
> generation ?
> >>>> That BundleActivator could in the stop method stop any running
> threads.
> >> The
> >>>> BundleActivator is part of the bundle so it may be aware of the
> library
> >>>> internals and be able to stop any running threads.
> >>>>
> >>>> Regards
> >>>> Felix
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: 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
> >>
> >>
>
>
>
>
> This e-mail is only intended for the person(s) to whom it is addressed and
> may contain CONFIDENTIAL information. Any opinions or views are personal to
> the writer and do not represent those of INQ Mobile Limited, Hutchison
> Whampoa Limited or its group companies. If you are not the intended
> recipient, you are hereby notified that any use, retention, disclosure,
> copying, printing, forwarding or dissemination of this communication is
> strictly prohibited. If you have received this communication in error,
> please erase all copies of the message and its attachments and notify the
> sender immediately. INQ Mobile Limited is a company registered in the
> British Virgin Islands. www.inqmobile.com.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Giving up on in process update... suggestions for how to structure separate JVM update?
Posted by Bruce Jackson <br...@inqmobile.com>.
I'd remove JNotify and replace it with the new filesystem classes in J2SE 7. That way you'll be able to sort out the thread management yourself.
On 14 May 2013, at 15:46, Dan Gravell <da...@elstensoftware.com> wrote:
> Hmmmm, sorry, don't want to misrepresent things... In neither case do you
> *explicitly* start threads.
>
> JNotify's threads are started by the class initialisers... so load the
> class (as you do when you add a 'watch' via a static method for a
> directory) and the thread starts.
>
> Lift's are started as part of its HTTP request handling. I managed to patch
> it to stop all the threads upon shutdown of its surrounding servlet
> container (I use Jetty) but this is just code I will have to maintain going
> forward with new releases.
>
> Neither behaviour is particularly desirable but JNotify's age and lack of
> committers and Lift's usage scenarios are probably good reasons why the
> respective projects' resources are not spent on fixing this.
>
> Dan
>
>
> On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <nj...@gmail.com> wrote:
>
>> So, they give you API to start a bunch of threads, but not stop them?
>> Awesome...
>>
>> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <da...@elstensoftware.com>
>> wrote:
>>> In one case (JNotify) I create straight wrappers so the JARs are
>>> 'OSGi-ified', in another case I have the JARs embedded in the bundle that
>>> uses them (Lift).
>>>
>>> Adding the bundle activator might work if the support to shutdown the
>>> threads is in the API for the code I am using. However, it isn't, and as
>>> you know Java threads are co-operative so I can't simply stop them.
>>>
>>> Dan
>>>
>>>
>>> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fmeschbe@adobe.com
>>> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Just to be clear: you're preaching to the converted, I understand why
>> the
>>>>> threads should be stopped. The issue is that I am re-using other
>> projects
>>>>> that don't conform to these rules.... projects that were never
>> written as
>>>>> OSGi bundles. It's a bit like the class loading assumptions you see in
>>>>> other projects... except arguably more subtle.
>>>>
>>>> So you are using libraries which are not built with OSGi in mind. Still
>>>> you need OSGi manifests for the libraries to become bundles. So you at
>>>> least wrap the libraries somehow to generate the manifest.
>>>>
>>>> How about adding a BundleActivator as part of this manifest generation ?
>>>> That BundleActivator could in the stop method stop any running threads.
>> The
>>>> BundleActivator is part of the bundle so it may be aware of the library
>>>> internals and be able to stop any running threads.
>>>>
>>>> Regards
>>>> Felix
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: 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
>>
>>
This e-mail is only intended for the person(s) to whom it is addressed and may contain CONFIDENTIAL information. Any opinions or views are personal to the writer and do not represent those of INQ Mobile Limited, Hutchison Whampoa Limited or its group companies. If you are not the intended recipient, you are hereby notified that any use, retention, disclosure, copying, printing, forwarding or dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify the sender immediately. INQ Mobile Limited is a company registered in the British Virgin Islands. www.inqmobile.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Hmmmm, sorry, don't want to misrepresent things... In neither case do you
*explicitly* start threads.
JNotify's threads are started by the class initialisers... so load the
class (as you do when you add a 'watch' via a static method for a
directory) and the thread starts.
Lift's are started as part of its HTTP request handling. I managed to patch
it to stop all the threads upon shutdown of its surrounding servlet
container (I use Jetty) but this is just code I will have to maintain going
forward with new releases.
Neither behaviour is particularly desirable but JNotify's age and lack of
committers and Lift's usage scenarios are probably good reasons why the
respective projects' resources are not spent on fixing this.
Dan
On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <nj...@gmail.com> wrote:
> So, they give you API to start a bunch of threads, but not stop them?
> Awesome...
>
> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <da...@elstensoftware.com>
> wrote:
> > In one case (JNotify) I create straight wrappers so the JARs are
> > 'OSGi-ified', in another case I have the JARs embedded in the bundle that
> > uses them (Lift).
> >
> > Adding the bundle activator might work if the support to shutdown the
> > threads is in the API for the code I am using. However, it isn't, and as
> > you know Java threads are co-operative so I can't simply stop them.
> >
> > Dan
> >
> >
> > On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fmeschbe@adobe.com
> >wrote:
> >
> >> Hi Dan,
> >>
> >> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
> >>
> >> >> 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.
> >> >>
> >> >
> >> > Just to be clear: you're preaching to the converted, I understand why
> the
> >> > threads should be stopped. The issue is that I am re-using other
> projects
> >> > that don't conform to these rules.... projects that were never
> written as
> >> > OSGi bundles. It's a bit like the class loading assumptions you see in
> >> > other projects... except arguably more subtle.
> >>
> >> So you are using libraries which are not built with OSGi in mind. Still
> >> you need OSGi manifests for the libraries to become bundles. So you at
> >> least wrap the libraries somehow to generate the manifest.
> >>
> >> How about adding a BundleActivator as part of this manifest generation ?
> >> That BundleActivator could in the stop method stop any running threads.
> The
> >> BundleActivator is part of the bundle so it may be aware of the library
> >> internals and be able to stop any running threads.
> >>
> >> Regards
> >> Felix
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: 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
>
>
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Neil Bartlett <nj...@gmail.com>.
So, they give you API to start a bunch of threads, but not stop them? Awesome...
On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <da...@elstensoftware.com> wrote:
> In one case (JNotify) I create straight wrappers so the JARs are
> 'OSGi-ified', in another case I have the JARs embedded in the bundle that
> uses them (Lift).
>
> Adding the bundle activator might work if the support to shutdown the
> threads is in the API for the code I am using. However, it isn't, and as
> you know Java threads are co-operative so I can't simply stop them.
>
> Dan
>
>
> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fm...@adobe.com>wrote:
>
>> Hi Dan,
>>
>> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>>
>> >> 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.
>> >>
>> >
>> > Just to be clear: you're preaching to the converted, I understand why the
>> > threads should be stopped. The issue is that I am re-using other projects
>> > that don't conform to these rules.... projects that were never written as
>> > OSGi bundles. It's a bit like the class loading assumptions you see in
>> > other projects... except arguably more subtle.
>>
>> So you are using libraries which are not built with OSGi in mind. Still
>> you need OSGi manifests for the libraries to become bundles. So you at
>> least wrap the libraries somehow to generate the manifest.
>>
>> How about adding a BundleActivator as part of this manifest generation ?
>> That BundleActivator could in the stop method stop any running threads. The
>> BundleActivator is part of the bundle so it may be aware of the library
>> internals and be able to stop any running threads.
>>
>> Regards
>> Felix
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by Ferry Huberts <ma...@hupie.com>.
On 14/05/13 16:35, Dan Gravell wrote:
> In one case (JNotify) I create straight wrappers so the JARs are
> 'OSGi-ified', in another case I have the JARs embedded in the bundle that
> uses them (Lift).
>
> Adding the bundle activator might work if the support to shutdown the
> threads is in the API for the code I am using. However, it isn't, and as
Wow, another 'classic': think about starting up, but not about shutting
down...
That library might be more trouble than it's worth...
grtz
BTW. I just updated my JNotify fork to use a modern bndtools workspace
> you know Java threads are co-operative so I can't simply stop them.
>
> Dan
>
>
> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fm...@adobe.com>wrote:
>
>> Hi Dan,
>>
>> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>>
>>>> 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.
>>>>
>>>
>>> Just to be clear: you're preaching to the converted, I understand why the
>>> threads should be stopped. The issue is that I am re-using other projects
>>> that don't conform to these rules.... projects that were never written as
>>> OSGi bundles. It's a bit like the class loading assumptions you see in
>>> other projects... except arguably more subtle.
>>
>> So you are using libraries which are not built with OSGi in mind. Still
>> you need OSGi manifests for the libraries to become bundles. So you at
>> least wrap the libraries somehow to generate the manifest.
>>
>> How about adding a BundleActivator as part of this manifest generation ?
>> That BundleActivator could in the stop method stop any running threads. The
>> BundleActivator is part of the bundle so it may be aware of the library
>> internals and be able to stop any running threads.
>>
>> Regards
>> Felix
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
In one case (JNotify) I create straight wrappers so the JARs are
'OSGi-ified', in another case I have the JARs embedded in the bundle that
uses them (Lift).
Adding the bundle activator might work if the support to shutdown the
threads is in the API for the code I am using. However, it isn't, and as
you know Java threads are co-operative so I can't simply stop them.
Dan
On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi Dan,
>
> Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>
> >> 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.
> >>
> >
> > Just to be clear: you're preaching to the converted, I understand why the
> > threads should be stopped. The issue is that I am re-using other projects
> > that don't conform to these rules.... projects that were never written as
> > OSGi bundles. It's a bit like the class loading assumptions you see in
> > other projects... except arguably more subtle.
>
> So you are using libraries which are not built with OSGi in mind. Still
> you need OSGi manifests for the libraries to become bundles. So you at
> least wrap the libraries somehow to generate the manifest.
>
> How about adding a BundleActivator as part of this manifest generation ?
> That BundleActivator could in the stop method stop any running threads. The
> BundleActivator is part of the bundle so it may be aware of the library
> internals and be able to stop any running threads.
>
> Regards
> Felix
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Dan,
Am 14.05.2013 um 07:16 schrieb Dan Gravell:
>> 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.
>>
>
> Just to be clear: you're preaching to the converted, I understand why the
> threads should be stopped. The issue is that I am re-using other projects
> that don't conform to these rules.... projects that were never written as
> OSGi bundles. It's a bit like the class loading assumptions you see in
> other projects... except arguably more subtle.
So you are using libraries which are not built with OSGi in mind. Still you need OSGi manifests for the libraries to become bundles. So you at least wrap the libraries somehow to generate the manifest.
How about adding a BundleActivator as part of this manifest generation ? That BundleActivator could in the stop method stop any running threads. The BundleActivator is part of the bundle so it may be aware of the library internals and be able to stop any running threads.
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Neil,
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().
>
Ok, so it's not safe to update() a stop()ped bundle which has threads still
running that it started itself? That means the update process would have to
occur in a separate JVM invocation.
> 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.
>
Just to be clear: you're preaching to the converted, I understand why the
threads should be stopped. The issue is that I am re-using other projects
that don't conform to these rules.... projects that were never written as
OSGi bundles. It's a bit like the class loading assumptions you see in
other projects... except arguably more subtle.
For "teh google", what I commonly see are NullPointerExceptions (example):
java.lang.NullPointerException
at
org.apache.felix.framework.BundleRevisionImpl.calculateContentPath(BundleRevisionImpl.java:410)
at
org.apache.felix.framework.BundleRevisionImpl.initializeContentPath(BundleRevisionImpl.java:347)
at
org.apache.felix.framework.BundleRevisionImpl.getContentPath(BundleRevisionImpl.java:333)
at
org.apache.felix.framework.BundleRevisionImpl.getResourceLocal(BundleRevisionImpl.java:472)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.getResourceByDelegation(BundleWiringImpl.java:1360)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.getResource(BundleWiringImpl.java:2256)
Also in JNotify's case threads are started in the static initalizers and it
means the native code ends up calling incorrect listeners in the bundle,
meaning file notifications are missing. I believe Ferry Huberts wrote a
port for the Linux part of JNotify, but I also need to support OS X and
Windows.
I also see various stack traces in static initalizers... ImageIO is a
particular favourite:
java.lang.NullPointerException
at
org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:510)
at
org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1127)
at
org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1037)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1778)
at
org.eclipse.jetty.osgi.boot.internal.webapp.OSGiWebappClassLoader.getResources(OSGiWebappClassLoader.java:115)
at
java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:340)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:432)
at
javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:206)
at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:138)
at
javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:159)
at javax.imageio.ImageIO.<clinit>(ImageIO.java:64)
These are often threads started *after* an update, by *updated* bundles.
But conversations with Richard S Hall before suggested the underlying cause
of the problems were threads that were still running at update.
Anyway, the point is I have devoted quite a lot of time to trying to iron
these kinks out and I'm not getting that far, so I want to go back to
something I think will work.
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?
>
Thanks, what you wrote helps me understand the fundamental point. I and my
users are certainly seeing problems (some examples above) after the update,
and if the threads are the cause, and I can't expediently stop them
(expedience in terms of development time), that's why I'll go for the JVM
restart.
Dan
Re: Giving up on in process update... suggestions for how to structure
separate JVM update?
Posted by Rob Walker <ro...@ascert.com>.
Firstly - I 100% agree with everything Neil said, it's spot on.
We also hit issues with an "in process" restart (albeit for different
reasons) and also settled on a JVM restart approach as an easier model
for our initial solution. We based the approach on this article:
http://java.dzone.com/articles/programmatically-restart-java
It works for us - but maybe won't work in every scenario.
We didn't use the above model verbatim - we split the part where we "get
command line args" out and did that at startup, saving them away for
later. We also "wrappered" the shutdown, making sure we have an attempt
to shut felix down cleanly first, and only then do we register the
"restart shutdown hook" as described in the article, and call exit to
trigger the restart e.g.
/**
* Ensure any Felix instance we started is shutdown
*/
public void stop(boolean wait)
{
try
{
if (this.felix != null && this.felix.getState() ==
Bundle.ACTIVE)
{
this.felix.stop();
if (wait)
{
felix.waitForStop(20000);
}
}
}
catch (Exception ex)
{
System.out.println("*** Exception stopping felix:" + ex);
}
}
/Note we keep a "felix" reference in our launcher during startup for
later shutdown./
It's important to realise that whilst the above can work, it isn't
necessarily as clean or controllable as a proper in-OSGi restart.
Regards
-- Rob
On 14/05/2013 1:44 PM, Neil Bartlett wrote:
> 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 <da...@elstensoftware.com> 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
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Ascert - Taking systems to the edge
robw@ascert.com
+27 21 300 2028 ext 5119
www.ascert.com
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Neil Bartlett <nj...@gmail.com>.
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 <da...@elstensoftware.com> 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
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to structure separate JVM update?
Posted by Bruce Jackson <br...@inqmobile.com>.
Ah yes, well on that subject I can only reiterate what others have said, that the bundle needs to be responsible for its own threads and start/stop them in the BundleActivator appropriately.
Thanks
Bruce
On 14 May 2013, at 14:02, Dan Gravell <da...@elstensoftware.com> wrote:
> Thanks Bruce. The trouble is that calling stop() does not stop all the
> threads started by some of the bundles I use, so using start levels isn't
> helpful at the part where the bundles are updated. However, it may be
> useful for restart to *attempt* to make sure some "bootstrap" bundle is
> started first.
>
> Dan
>
> On Tue, May 14, 2013 at 12:23 PM, Bruce Jackson <br...@inqmobile.com> wrote:
>
>> I'm not sure exactly what you're trying to do, but in the past I'm used an
>> embedded Felix instance with a single 'management' bundle running at start
>> level 1 which was then able to download and deploy all of the other bundles
>> in my system at start levels > 1.
>>
>> In this setup, all I needed to do was to drop the platform start level to
>> 1 which had the effect of calling stop() on all of the installed bundles.
>> In this state you can then uninstall and bundles to be updated, then just
>> set the start level back up to the default.
>>
>> On 14 May 2013, at 12:17, Dan Gravell <da...@elstensoftware.com> 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
>>
>>
>>
>>
>> This e-mail is only intended for the person(s) to whom it is addressed and
>> may contain CONFIDENTIAL information. Any opinions or views are personal to
>> the writer and do not represent those of INQ Mobile Limited, Hutchison
>> Whampoa Limited or its group companies. If you are not the intended
>> recipient, you are hereby notified that any use, retention, disclosure,
>> copying, printing, forwarding or dissemination of this communication is
>> strictly prohibited. If you have received this communication in error,
>> please erase all copies of the message and its attachments and notify the
>> sender immediately. INQ Mobile Limited is a company registered in the
>> British Virgin Islands. www.inqmobile.com.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
This e-mail is only intended for the person(s) to whom it is addressed and may contain CONFIDENTIAL information. Any opinions or views are personal to the writer and do not represent those of INQ Mobile Limited, Hutchison Whampoa Limited or its group companies. If you are not the intended recipient, you are hereby notified that any use, retention, disclosure, copying, printing, forwarding or dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify the sender immediately. INQ Mobile Limited is a company registered in the British Virgin Islands. www.inqmobile.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Giving up on in process update... suggestions for how to
structure separate JVM update?
Posted by Dan Gravell <da...@elstensoftware.com>.
Thanks Bruce. The trouble is that calling stop() does not stop all the
threads started by some of the bundles I use, so using start levels isn't
helpful at the part where the bundles are updated. However, it may be
useful for restart to *attempt* to make sure some "bootstrap" bundle is
started first.
Dan
On Tue, May 14, 2013 at 12:23 PM, Bruce Jackson <br...@inqmobile.com> wrote:
> I'm not sure exactly what you're trying to do, but in the past I'm used an
> embedded Felix instance with a single 'management' bundle running at start
> level 1 which was then able to download and deploy all of the other bundles
> in my system at start levels > 1.
>
> In this setup, all I needed to do was to drop the platform start level to
> 1 which had the effect of calling stop() on all of the installed bundles.
> In this state you can then uninstall and bundles to be updated, then just
> set the start level back up to the default.
>
> On 14 May 2013, at 12:17, Dan Gravell <da...@elstensoftware.com> 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
>
>
>
>
> This e-mail is only intended for the person(s) to whom it is addressed and
> may contain CONFIDENTIAL information. Any opinions or views are personal to
> the writer and do not represent those of INQ Mobile Limited, Hutchison
> Whampoa Limited or its group companies. If you are not the intended
> recipient, you are hereby notified that any use, retention, disclosure,
> copying, printing, forwarding or dissemination of this communication is
> strictly prohibited. If you have received this communication in error,
> please erase all copies of the message and its attachments and notify the
> sender immediately. INQ Mobile Limited is a company registered in the
> British Virgin Islands. www.inqmobile.com.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Giving up on in process update... suggestions for how to structure separate JVM update?
Posted by Bruce Jackson <br...@inqmobile.com>.
I'm not sure exactly what you're trying to do, but in the past I'm used an embedded Felix instance with a single 'management' bundle running at start level 1 which was then able to download and deploy all of the other bundles in my system at start levels > 1.
In this setup, all I needed to do was to drop the platform start level to 1 which had the effect of calling stop() on all of the installed bundles. In this state you can then uninstall and bundles to be updated, then just set the start level back up to the default.
On 14 May 2013, at 12:17, Dan Gravell <da...@elstensoftware.com> 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
This e-mail is only intended for the person(s) to whom it is addressed and may contain CONFIDENTIAL information. Any opinions or views are personal to the writer and do not represent those of INQ Mobile Limited, Hutchison Whampoa Limited or its group companies. If you are not the intended recipient, you are hereby notified that any use, retention, disclosure, copying, printing, forwarding or dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify the sender immediately. INQ Mobile Limited is a company registered in the British Virgin Islands. www.inqmobile.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org