Telling whether startup is really complete

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Telling whether startup is really complete

Christoph Gritschenberger
Hi,

I had another meeting with a customer today who asked me: "How can I
tell whether it is started up completely?". ("It" being our karaf-based
product)

So I had a look at several alternatives how I could accomplish this and
had an idea I wanted to discuss.

I know that I can modify the Start-level of the Shell-bundle but I don't
think that's enough.
Recently Christian Schneider implemented something to delay the startup
of the shell until all bundles are active. I think that's a good start,
but does not solve the problem completely for me. I encountered several
issues with the approach:

1. There is a short delay between the point where all karaf-base-bundles
are loaded and the feature-installer starts installing features
specified in "featuresBoot". When starting up the first time, this
almost always happens

...
        [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
        [  46] [  Resolved] [   20] Apache Aries Blueprint Core Compatiblity
Fragment Bundle (1.0.0), Hosts: 26
        [  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
(3.0.0.SNAPSHOT)
        [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
(3.0.0.SNAPSHOT)
        karaf@root()>

After a few seconds the installing of the features commences:

...
        [  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
(3.0.0.SNAPSHOT)
        [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
(3.0.0.SNAPSHOT)
        [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
(3.0.0.SNAPSHOT)
        [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Commands
(3.0.0.SNAPSHOT)
...

So the condition "all non-fragment bundles are ACTIVE" does not
necessarily mean "startup is complete".

2. Even if all features are installed completely and all bundles are
ACTIVE, they may contain a blueprint-file and the blueprint-container
might take even longer to start up.


So I had an idea, I wanted to discuss:
How about introducing an additional interface (like "StartupIndicator"
with a method "boolean isStartupComplete()" or "int
getStartupProgress()"). The FeatureService could implement this
interface and provide the Service be registered with this additional
interface.
The Shell-bundle could then pick up all "StartupIndicator"-services and
require all of them to return true before actually showing the prompt.
Another StartupIndicator could check for BlueprintContainers to be
available.

This way, the shell would not actually have a direct dependency to the
FeatureService, but could delay the prompt until all features are
installed and active.

Another advantage is, that users would be able to implement their own
"StartupIndicator"-services to introduce even more delays.

WDYT?

kind regards,
christoph


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

jbonofre
Hi Christoph,

FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
progress bar while Karaf is starting and the shell console arrives only
when the startup is complete.

I invite you to take a look on that.

Regards
JB

On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:

> Hi,
>
> I had another meeting with a customer today who asked me: "How can I
> tell whether it is started up completely?". ("It" being our karaf-based
> product)
>
> So I had a look at several alternatives how I could accomplish this and
> had an idea I wanted to discuss.
>
> I know that I can modify the Start-level of the Shell-bundle but I don't
> think that's enough.
> Recently Christian Schneider implemented something to delay the startup
> of the shell until all bundles are active. I think that's a good start,
> but does not solve the problem completely for me. I encountered several
> issues with the approach:
>
> 1. There is a short delay between the point where all karaf-base-bundles
> are loaded and the feature-installer starts installing features
> specified in "featuresBoot". When starting up the first time, this
> almost always happens
>
> ...
> [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
> [  46] [  Resolved] [   20] Apache Aries Blueprint Core Compatiblity
> Fragment Bundle (1.0.0), Hosts: 26
> [  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
> (3.0.0.SNAPSHOT)
> [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
> (3.0.0.SNAPSHOT)
> karaf@root()>
>
> After a few seconds the installing of the features commences:
>
> ...
> [  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
> (3.0.0.SNAPSHOT)
> [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
> (3.0.0.SNAPSHOT)
> [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
> (3.0.0.SNAPSHOT)
> [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Commands
> (3.0.0.SNAPSHOT)
> ...
>
> So the condition "all non-fragment bundles are ACTIVE" does not
> necessarily mean "startup is complete".
>
> 2. Even if all features are installed completely and all bundles are
> ACTIVE, they may contain a blueprint-file and the blueprint-container
> might take even longer to start up.
>
>
> So I had an idea, I wanted to discuss:
> How about introducing an additional interface (like "StartupIndicator"
> with a method "boolean isStartupComplete()" or "int
> getStartupProgress()"). The FeatureService could implement this
> interface and provide the Service be registered with this additional
> interface.
> The Shell-bundle could then pick up all "StartupIndicator"-services and
> require all of them to return true before actually showing the prompt.
> Another StartupIndicator could check for BlueprintContainers to be
> available.
>
> This way, the shell would not actually have a direct dependency to the
> FeatureService, but could delay the prompt until all features are
> installed and active.
>
> Another advantage is, that users would be able to implement their own
> "StartupIndicator"-services to introduce even more delays.
>
> WDYT?
>
> kind regards,
> christoph
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Andreas Pieber
Hey guys,

While the 2.3.x code looks ways more stable than the one on the master
I'm not convinced that it will solve Christoph's problem. As Christoph
pointed out:

"There is a short delay between the point where all karaf-base-bundles
are loaded and the feature-installer starts installing features
specified in "featuresBoot". When starting up the first time, this
almost always happens"

I would say the relevant parts in Karaf 2.3.x are:

a) StartupListener.java
b) DelayedStarted.java

So, If I'm correct (a) is printing the number of active
bundles/available bundles till (b) set a constant which will occur the
moment a bundle is added with a start lvl higher than
"org.osgi.framework.startlevel.beginning". That's basically fine, but
this will still not fix the problem with the feature service adding
bundles (with even higher start lvls) AFTER the framework startup. In
addition we've the "old" problem of various parts (blueprint, webapps,
deployer, ...) starting up async. While most of those components know
when they're finished (a) cannot know. This has the advantage that it
has no problem if a bundle is e.g. caught in a startup loop, but on
the other hand you wont know when all bundles are active. In addition
it will show the framework ready although bundles with a startup lvl
higher than "org.osgi.framework.startlevel.beginning" are still
starting.

Therefore I'm curious if the process shouldn't be something like

a) wait till all bundles are active or one have failed
b) once all bundles are active query for a StartupIndicator service
and wait till all of them either return finished or failed
c) once all startup indicators are finished wait again till all
(possibly new bundles) are active
d) now there are maybe new StartupIndicators available or everything
is up and running

Do I miss anything? WDYT?

Kind regards,
Andreas

On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]> wrote:

> Hi Christoph,
>
> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
> progress bar while Karaf is starting and the shell console arrives only when
> the startup is complete.
>
> I invite you to take a look on that.
>
> Regards
> JB
>
>
> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>
>> Hi,
>>
>> I had another meeting with a customer today who asked me: "How can I
>> tell whether it is started up completely?". ("It" being our karaf-based
>> product)
>>
>> So I had a look at several alternatives how I could accomplish this and
>> had an idea I wanted to discuss.
>>
>> I know that I can modify the Start-level of the Shell-bundle but I don't
>> think that's enough.
>> Recently Christian Schneider implemented something to delay the startup
>> of the shell until all bundles are active. I think that's a good start,
>> but does not solve the problem completely for me. I encountered several
>> issues with the approach:
>>
>> 1. There is a short delay between the point where all karaf-base-bundles
>> are loaded and the feature-installer starts installing features
>> specified in "featuresBoot". When starting up the first time, this
>> almost always happens
>>
>> ...
>>         [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>         [  46] [  Resolved] [   20] Apache Aries Blueprint Core
>> Compatiblity
>> Fragment Bundle (1.0.0), Hosts: 26
>>         [  47] [    Active] [   30] Apache Karaf :: System :: Shell
>> Commands
>> (3.0.0.SNAPSHOT)
>>         [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
>> (3.0.0.SNAPSHOT)
>>         karaf@root()>
>>
>> After a few seconds the installing of the features commences:
>>
>> ...
>>         [  47] [    Active] [   30] Apache Karaf :: System :: Shell
>> Commands
>> (3.0.0.SNAPSHOT)
>>         [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
>> (3.0.0.SNAPSHOT)
>>         [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
>> (3.0.0.SNAPSHOT)
>>         [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin ::
>> Commands
>> (3.0.0.SNAPSHOT)
>> ...
>>
>> So the condition "all non-fragment bundles are ACTIVE" does not
>> necessarily mean "startup is complete".
>>
>> 2. Even if all features are installed completely and all bundles are
>> ACTIVE, they may contain a blueprint-file and the blueprint-container
>> might take even longer to start up.
>>
>>
>> So I had an idea, I wanted to discuss:
>> How about introducing an additional interface (like "StartupIndicator"
>> with a method "boolean isStartupComplete()" or "int
>> getStartupProgress()"). The FeatureService could implement this
>> interface and provide the Service be registered with this additional
>> interface.
>> The Shell-bundle could then pick up all "StartupIndicator"-services and
>> require all of them to return true before actually showing the prompt.
>> Another StartupIndicator could check for BlueprintContainers to be
>> available.
>>
>> This way, the shell would not actually have a direct dependency to the
>> FeatureService, but could delay the prompt until all features are
>> installed and active.
>>
>> Another advantage is, that users would be able to implement their own
>> "StartupIndicator"-services to introduce even more delays.
>>
>> WDYT?
>>
>> kind regards,
>> christoph
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

jbonofre
Hi Andreas,

it depends what we consider when saying "bundle started". From a OSGi
perspective, the bundle is started.

However I'm agree about the featuresBoot (AFAIR we have a Jira about that).

I will take time deeper later (time to go dinner for me here ;)).

Regards
JB

On 08/09/2012 05:08 AM, Andreas Pieber wrote:

> Hey guys,
>
> While the 2.3.x code looks ways more stable than the one on the master
> I'm not convinced that it will solve Christoph's problem. As Christoph
> pointed out:
>
> "There is a short delay between the point where all karaf-base-bundles
> are loaded and the feature-installer starts installing features
> specified in "featuresBoot". When starting up the first time, this
> almost always happens"
>
> I would say the relevant parts in Karaf 2.3.x are:
>
> a) StartupListener.java
> b) DelayedStarted.java
>
> So, If I'm correct (a) is printing the number of active
> bundles/available bundles till (b) set a constant which will occur the
> moment a bundle is added with a start lvl higher than
> "org.osgi.framework.startlevel.beginning". That's basically fine, but
> this will still not fix the problem with the feature service adding
> bundles (with even higher start lvls) AFTER the framework startup. In
> addition we've the "old" problem of various parts (blueprint, webapps,
> deployer, ...) starting up async. While most of those components know
> when they're finished (a) cannot know. This has the advantage that it
> has no problem if a bundle is e.g. caught in a startup loop, but on
> the other hand you wont know when all bundles are active. In addition
> it will show the framework ready although bundles with a startup lvl
> higher than "org.osgi.framework.startlevel.beginning" are still
> starting.
>
> Therefore I'm curious if the process shouldn't be something like
>
> a) wait till all bundles are active or one have failed
> b) once all bundles are active query for a StartupIndicator service
> and wait till all of them either return finished or failed
> c) once all startup indicators are finished wait again till all
> (possibly new bundles) are active
> d) now there are maybe new StartupIndicators available or everything
> is up and running
>
> Do I miss anything? WDYT?
>
> Kind regards,
> Andreas
>
> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]> wrote:
>> Hi Christoph,
>>
>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
>> progress bar while Karaf is starting and the shell console arrives only when
>> the startup is complete.
>>
>> I invite you to take a look on that.
>>
>> Regards
>> JB
>>
>>
>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>
>>> Hi,
>>>
>>> I had another meeting with a customer today who asked me: "How can I
>>> tell whether it is started up completely?". ("It" being our karaf-based
>>> product)
>>>
>>> So I had a look at several alternatives how I could accomplish this and
>>> had an idea I wanted to discuss.
>>>
>>> I know that I can modify the Start-level of the Shell-bundle but I don't
>>> think that's enough.
>>> Recently Christian Schneider implemented something to delay the startup
>>> of the shell until all bundles are active. I think that's a good start,
>>> but does not solve the problem completely for me. I encountered several
>>> issues with the approach:
>>>
>>> 1. There is a short delay between the point where all karaf-base-bundles
>>> are loaded and the feature-installer starts installing features
>>> specified in "featuresBoot". When starting up the first time, this
>>> almost always happens
>>>
>>> ...
>>>          [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>          [  46] [  Resolved] [   20] Apache Aries Blueprint Core
>>> Compatiblity
>>> Fragment Bundle (1.0.0), Hosts: 26
>>>          [  47] [    Active] [   30] Apache Karaf :: System :: Shell
>>> Commands
>>> (3.0.0.SNAPSHOT)
>>>          [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
>>> (3.0.0.SNAPSHOT)
>>>          karaf@root()>
>>>
>>> After a few seconds the installing of the features commences:
>>>
>>> ...
>>>          [  47] [    Active] [   30] Apache Karaf :: System :: Shell
>>> Commands
>>> (3.0.0.SNAPSHOT)
>>>          [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
>>> (3.0.0.SNAPSHOT)
>>>          [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
>>> (3.0.0.SNAPSHOT)
>>>          [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin ::
>>> Commands
>>> (3.0.0.SNAPSHOT)
>>> ...
>>>
>>> So the condition "all non-fragment bundles are ACTIVE" does not
>>> necessarily mean "startup is complete".
>>>
>>> 2. Even if all features are installed completely and all bundles are
>>> ACTIVE, they may contain a blueprint-file and the blueprint-container
>>> might take even longer to start up.
>>>
>>>
>>> So I had an idea, I wanted to discuss:
>>> How about introducing an additional interface (like "StartupIndicator"
>>> with a method "boolean isStartupComplete()" or "int
>>> getStartupProgress()"). The FeatureService could implement this
>>> interface and provide the Service be registered with this additional
>>> interface.
>>> The Shell-bundle could then pick up all "StartupIndicator"-services and
>>> require all of them to return true before actually showing the prompt.
>>> Another StartupIndicator could check for BlueprintContainers to be
>>> available.
>>>
>>> This way, the shell would not actually have a direct dependency to the
>>> FeatureService, but could delay the prompt until all features are
>>> installed and active.
>>>
>>> Another advantage is, that users would be able to implement their own
>>> "StartupIndicator"-services to introduce even more delays.
>>>
>>> WDYT?
>>>
>>> kind regards,
>>> christoph
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Andreas Pieber
Hey JB,

On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]> wrote:
> Hi Andreas,
>
> it depends what we consider when saying "bundle started". From a OSGi
> perspective, the bundle is started.

I think there are various lvls here (and thats the reason why I
consider the ReadyService, as proposed by Christoph, such a good
idea). Consider that we register those ReadyServices via the activator
they will be available once the bundle is active; once all framework
bundles are active the feature service can state once he had installed
all features, the deployer can state once all bundles from the deploy
folder had been added, a custom application bundle can e.g. check if a
specific url could be reached and so on; This could finally provide a
"suite" which could be adapted to give a user a quite accurate "real"
start-point (even if it requires some manual adaption). I'm really
interested what you think about this once you've given it a little bit
more time for consideration :-)

>
> However I'm agree about the featuresBoot (AFAIR we have a Jira about that).
>
> I will take time deeper later (time to go dinner for me here ;)).

Dinner? Wow, I really should take more time keeping up-to-date; where
the hell are you :-)

Kind regards,
Andreas

>
> Regards
> JB
>
>
> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>
>> Hey guys,
>>
>> While the 2.3.x code looks ways more stable than the one on the master
>> I'm not convinced that it will solve Christoph's problem. As Christoph
>> pointed out:
>>
>> "There is a short delay between the point where all karaf-base-bundles
>> are loaded and the feature-installer starts installing features
>> specified in "featuresBoot". When starting up the first time, this
>> almost always happens"
>>
>> I would say the relevant parts in Karaf 2.3.x are:
>>
>> a) StartupListener.java
>> b) DelayedStarted.java
>>
>> So, If I'm correct (a) is printing the number of active
>> bundles/available bundles till (b) set a constant which will occur the
>> moment a bundle is added with a start lvl higher than
>> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>> this will still not fix the problem with the feature service adding
>> bundles (with even higher start lvls) AFTER the framework startup. In
>> addition we've the "old" problem of various parts (blueprint, webapps,
>> deployer, ...) starting up async. While most of those components know
>> when they're finished (a) cannot know. This has the advantage that it
>> has no problem if a bundle is e.g. caught in a startup loop, but on
>> the other hand you wont know when all bundles are active. In addition
>> it will show the framework ready although bundles with a startup lvl
>> higher than "org.osgi.framework.startlevel.beginning" are still
>> starting.
>>
>> Therefore I'm curious if the process shouldn't be something like
>>
>> a) wait till all bundles are active or one have failed
>> b) once all bundles are active query for a StartupIndicator service
>> and wait till all of them either return finished or failed
>> c) once all startup indicators are finished wait again till all
>> (possibly new bundles) are active
>> d) now there are maybe new StartupIndicators available or everything
>> is up and running
>>
>> Do I miss anything? WDYT?
>>
>> Kind regards,
>> Andreas
>>
>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
>> wrote:
>>>
>>> Hi Christoph,
>>>
>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
>>> progress bar while Karaf is starting and the shell console arrives only
>>> when
>>> the startup is complete.
>>>
>>> I invite you to take a look on that.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I had another meeting with a customer today who asked me: "How can I
>>>> tell whether it is started up completely?". ("It" being our karaf-based
>>>> product)
>>>>
>>>> So I had a look at several alternatives how I could accomplish this and
>>>> had an idea I wanted to discuss.
>>>>
>>>> I know that I can modify the Start-level of the Shell-bundle but I don't
>>>> think that's enough.
>>>> Recently Christian Schneider implemented something to delay the startup
>>>> of the shell until all bundles are active. I think that's a good start,
>>>> but does not solve the problem completely for me. I encountered several
>>>> issues with the approach:
>>>>
>>>> 1. There is a short delay between the point where all karaf-base-bundles
>>>> are loaded and the feature-installer starts installing features
>>>> specified in "featuresBoot". When starting up the first time, this
>>>> almost always happens
>>>>
>>>> ...
>>>>          [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>          [  46] [  Resolved] [   20] Apache Aries Blueprint Core
>>>> Compatiblity
>>>> Fragment Bundle (1.0.0), Hosts: 26
>>>>          [  47] [    Active] [   30] Apache Karaf :: System :: Shell
>>>> Commands
>>>> (3.0.0.SNAPSHOT)
>>>>          [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
>>>> (3.0.0.SNAPSHOT)
>>>>          karaf@root()>
>>>>
>>>> After a few seconds the installing of the features commences:
>>>>
>>>> ...
>>>>          [  47] [    Active] [   30] Apache Karaf :: System :: Shell
>>>> Commands
>>>> (3.0.0.SNAPSHOT)
>>>>          [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
>>>> (3.0.0.SNAPSHOT)
>>>>          [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
>>>> (3.0.0.SNAPSHOT)
>>>>          [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin ::
>>>> Commands
>>>> (3.0.0.SNAPSHOT)
>>>> ...
>>>>
>>>> So the condition "all non-fragment bundles are ACTIVE" does not
>>>> necessarily mean "startup is complete".
>>>>
>>>> 2. Even if all features are installed completely and all bundles are
>>>> ACTIVE, they may contain a blueprint-file and the blueprint-container
>>>> might take even longer to start up.
>>>>
>>>>
>>>> So I had an idea, I wanted to discuss:
>>>> How about introducing an additional interface (like "StartupIndicator"
>>>> with a method "boolean isStartupComplete()" or "int
>>>> getStartupProgress()"). The FeatureService could implement this
>>>> interface and provide the Service be registered with this additional
>>>> interface.
>>>> The Shell-bundle could then pick up all "StartupIndicator"-services and
>>>> require all of them to return true before actually showing the prompt.
>>>> Another StartupIndicator could check for BlueprintContainers to be
>>>> available.
>>>>
>>>> This way, the shell would not actually have a direct dependency to the
>>>> FeatureService, but could delay the prompt until all features are
>>>> installed and active.
>>>>
>>>> Another advantage is, that users would be able to implement their own
>>>> "StartupIndicator"-services to introduce even more delays.
>>>>
>>>> WDYT?
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Charles Moulliard-2
Hi,

From my point of view, this is not because a bundle is started or even an
OSGI service is registered (in the OSGI registry) that we could say that
the "Services" deployed on the platform (Bundles, Camel routes, Web
Services, Web modules, ....) are operational. This is why for that reason I
always recommend to our clients that they add in their services some MBeans
methods, log trace, use WireTap EIP, ...  to capture that information and
report it into a dashboard (DataBase, ...) that operational guys can use to
be informed if everything is "operational = services well deployed and
started)

Regards,

Charles Moulliard

Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com

On Thu, Aug 9, 2012 at 5:55 AM, Andreas Pieber <[hidden email]> wrote:

> Hey JB,
>
> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]>
> wrote:
> > Hi Andreas,
> >
> > it depends what we consider when saying "bundle started". From a OSGi
> > perspective, the bundle is started.
>
> I think there are various lvls here (and thats the reason why I
> consider the ReadyService, as proposed by Christoph, such a good
> idea). Consider that we register those ReadyServices via the activator
> they will be available once the bundle is active; once all framework
> bundles are active the feature service can state once he had installed
> all features, the deployer can state once all bundles from the deploy
> folder had been added, a custom application bundle can e.g. check if a
> specific url could be reached and so on; This could finally provide a
> "suite" which could be adapted to give a user a quite accurate "real"
> start-point (even if it requires some manual adaption). I'm really
> interested what you think about this once you've given it a little bit
> more time for consideration :-)
>
> >
> > However I'm agree about the featuresBoot (AFAIR we have a Jira about
> that).
> >
> > I will take time deeper later (time to go dinner for me here ;)).
>
> Dinner? Wow, I really should take more time keeping up-to-date; where
> the hell are you :-)
>
> Kind regards,
> Andreas
>
> >
> > Regards
> > JB
> >
> >
> > On 08/09/2012 05:08 AM, Andreas Pieber wrote:
> >>
> >> Hey guys,
> >>
> >> While the 2.3.x code looks ways more stable than the one on the master
> >> I'm not convinced that it will solve Christoph's problem. As Christoph
> >> pointed out:
> >>
> >> "There is a short delay between the point where all karaf-base-bundles
> >> are loaded and the feature-installer starts installing features
> >> specified in "featuresBoot". When starting up the first time, this
> >> almost always happens"
> >>
> >> I would say the relevant parts in Karaf 2.3.x are:
> >>
> >> a) StartupListener.java
> >> b) DelayedStarted.java
> >>
> >> So, If I'm correct (a) is printing the number of active
> >> bundles/available bundles till (b) set a constant which will occur the
> >> moment a bundle is added with a start lvl higher than
> >> "org.osgi.framework.startlevel.beginning". That's basically fine, but
> >> this will still not fix the problem with the feature service adding
> >> bundles (with even higher start lvls) AFTER the framework startup. In
> >> addition we've the "old" problem of various parts (blueprint, webapps,
> >> deployer, ...) starting up async. While most of those components know
> >> when they're finished (a) cannot know. This has the advantage that it
> >> has no problem if a bundle is e.g. caught in a startup loop, but on
> >> the other hand you wont know when all bundles are active. In addition
> >> it will show the framework ready although bundles with a startup lvl
> >> higher than "org.osgi.framework.startlevel.beginning" are still
> >> starting.
> >>
> >> Therefore I'm curious if the process shouldn't be something like
> >>
> >> a) wait till all bundles are active or one have failed
> >> b) once all bundles are active query for a StartupIndicator service
> >> and wait till all of them either return finished or failed
> >> c) once all startup indicators are finished wait again till all
> >> (possibly new bundles) are active
> >> d) now there are maybe new StartupIndicators available or everything
> >> is up and running
> >>
> >> Do I miss anything? WDYT?
> >>
> >> Kind regards,
> >> Andreas
> >>
> >> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
> >> wrote:
> >>>
> >>> Hi Christoph,
> >>>
> >>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
> >>> progress bar while Karaf is starting and the shell console arrives only
> >>> when
> >>> the startup is complete.
> >>>
> >>> I invite you to take a look on that.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I had another meeting with a customer today who asked me: "How can I
> >>>> tell whether it is started up completely?". ("It" being our
> karaf-based
> >>>> product)
> >>>>
> >>>> So I had a look at several alternatives how I could accomplish this
> and
> >>>> had an idea I wanted to discuss.
> >>>>
> >>>> I know that I can modify the Start-level of the Shell-bundle but I
> don't
> >>>> think that's enough.
> >>>> Recently Christian Schneider implemented something to delay the
> startup
> >>>> of the shell until all bundles are active. I think that's a good
> start,
> >>>> but does not solve the problem completely for me. I encountered
> several
> >>>> issues with the approach:
> >>>>
> >>>> 1. There is a short delay between the point where all
> karaf-base-bundles
> >>>> are loaded and the feature-installer starts installing features
> >>>> specified in "featuresBoot". When starting up the first time, this
> >>>> almost always happens
> >>>>
> >>>> ...
> >>>>          [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
> >>>>          [  46] [  Resolved] [   20] Apache Aries Blueprint Core
> >>>> Compatiblity
> >>>> Fragment Bundle (1.0.0), Hosts: 26
> >>>>          [  47] [    Active] [   30] Apache Karaf :: System :: Shell
> >>>> Commands
> >>>> (3.0.0.SNAPSHOT)
> >>>>          [  48] [    Active] [   24] Apache Karaf :: Deployer ::
> Spring
> >>>> (3.0.0.SNAPSHOT)
> >>>>          karaf@root()>
> >>>>
> >>>> After a few seconds the installing of the features commences:
> >>>>
> >>>> ...
> >>>>          [  47] [    Active] [   30] Apache Karaf :: System :: Shell
> >>>> Commands
> >>>> (3.0.0.SNAPSHOT)
> >>>>          [  48] [    Active] [   24] Apache Karaf :: Deployer ::
> Spring
> >>>> (3.0.0.SNAPSHOT)
> >>>>          [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin ::
> Core
> >>>> (3.0.0.SNAPSHOT)
> >>>>          [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin ::
> >>>> Commands
> >>>> (3.0.0.SNAPSHOT)
> >>>> ...
> >>>>
> >>>> So the condition "all non-fragment bundles are ACTIVE" does not
> >>>> necessarily mean "startup is complete".
> >>>>
> >>>> 2. Even if all features are installed completely and all bundles are
> >>>> ACTIVE, they may contain a blueprint-file and the blueprint-container
> >>>> might take even longer to start up.
> >>>>
> >>>>
> >>>> So I had an idea, I wanted to discuss:
> >>>> How about introducing an additional interface (like "StartupIndicator"
> >>>> with a method "boolean isStartupComplete()" or "int
> >>>> getStartupProgress()"). The FeatureService could implement this
> >>>> interface and provide the Service be registered with this additional
> >>>> interface.
> >>>> The Shell-bundle could then pick up all "StartupIndicator"-services
> and
> >>>> require all of them to return true before actually showing the prompt.
> >>>> Another StartupIndicator could check for BlueprintContainers to be
> >>>> available.
> >>>>
> >>>> This way, the shell would not actually have a direct dependency to the
> >>>> FeatureService, but could delay the prompt until all features are
> >>>> installed and active.
> >>>>
> >>>> Another advantage is, that users would be able to implement their own
> >>>> "StartupIndicator"-services to introduce even more delays.
> >>>>
> >>>> WDYT?
> >>>>
> >>>> kind regards,
> >>>> christoph
> >>>>
> >>>
> >>> --
> >>> Jean-Baptiste Onofré
> >>> [hidden email]
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >
> >
> > --
> > Jean-Baptiste Onofré
> > [hidden email]
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

cschneider
In reply to this post by Christoph Gritschenberger
Hi Christoph,

the current implementation uses the start level as an indicator to start
the shell. So the shell starts once the FRAMEWORK_BEGINNING_STARTLEVEL
is reached. As by default we start blueprint contexts synchronously this
should be a quite good indicator that all desired bundles are up or failed.

So I think the current solution already shows that karaf has fully
started. It does not show of course that the startup was successfully as
we would not want the shell
to "hang" if a bundle fails.

For Karaf 3 I have done a solution for determining if something is wrong
in the framework. I have used this in the new bundle:diag command that
shows all typical problems.
I have also enhanced the bundleService.getInfo method. It now shows that
combined status of the OSGi state and all BundleStateServices that are
available.

BundleStateService is a SPI that allows to implement a service to
determine a state and diagnostic informations for a bundle regarding a
certain technology. I have implemented this for Spring DM and Blueprint
but we could add more implementations like for DS. Users could also
implement this service to provide their own diagnostics.

This aproach is a bit different to the StartupIndicator you proposed. I
think the BundleStateService is a better option for monitoring as it
also works while the framework is running and not only ar startup. This
is important as probably once you solved the question "When is the
frameowork fully up?" the next question will be "how can we check it is
still working?".

So I think the BundleStateService which is also available in JMX is
already a nice thing to monitor. If it reports any bundle that is not
active then the admin knows soemthing is wrong.

I think we could improve the startup of the shell by displaying a
message if any non fragment bundle is in a state other than Active. Like:
"Warning some bundles did not start correctly. Type bundle:diag to get
more informations."

What do you think?

Christian


Am 08.08.2012 20:43, schrieb Christoph Gritschenberger:

> Hi,
>
> I had another meeting with a customer today who asked me: "How can I
> tell whether it is started up completely?". ("It" being our karaf-based
> product)
>
> So I had a look at several alternatives how I could accomplish this and
> had an idea I wanted to discuss.
>
> I know that I can modify the Start-level of the Shell-bundle but I don't
> think that's enough.
> Recently Christian Schneider implemented something to delay the startup
> of the shell until all bundles are active. I think that's a good start,
> but does not solve the problem completely for me. I encountered several
> issues with the approach:
>
> 1. There is a short delay between the point where all karaf-base-bundles
> are loaded and the feature-installer starts installing features
> specified in "featuresBoot". When starting up the first time, this
> almost always happens
>
> ...
> [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
> [  46] [  Resolved] [   20] Apache Aries Blueprint Core Compatiblity
> Fragment Bundle (1.0.0), Hosts: 26
> [  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
> (3.0.0.SNAPSHOT)
> [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
> (3.0.0.SNAPSHOT)
> karaf@root()>
>
> After a few seconds the installing of the features commences:
>
> ...
> [  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
> (3.0.0.SNAPSHOT)
> [  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
> (3.0.0.SNAPSHOT)
> [  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
> (3.0.0.SNAPSHOT)
> [  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Commands
> (3.0.0.SNAPSHOT)
> ...
>
> So the condition "all non-fragment bundles are ACTIVE" does not
> necessarily mean "startup is complete".
>
> 2. Even if all features are installed completely and all bundles are
> ACTIVE, they may contain a blueprint-file and the blueprint-container
> might take even longer to start up.
>
>
> So I had an idea, I wanted to discuss:
> How about introducing an additional interface (like "StartupIndicator"
> with a method "boolean isStartupComplete()" or "int
> getStartupProgress()"). The FeatureService could implement this
> interface and provide the Service be registered with this additional
> interface.
> The Shell-bundle could then pick up all "StartupIndicator"-services and
> require all of them to return true before actually showing the prompt.
> Another StartupIndicator could check for BlueprintContainers to be
> available.
>
> This way, the shell would not actually have a direct dependency to the
> FeatureService, but could delay the prompt until all features are
> installed and active.
>
> Another advantage is, that users would be able to implement their own
> "StartupIndicator"-services to introduce even more delays.
>
> WDYT?
>
> kind regards,
> christoph
>


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Guillaume Nodet
In reply to this post by Andreas Pieber
Remember extenders can start bundles asynchronously, so the ReadyService
should be registered by the extender from an activator.
I'd think aries quiesce api could be a good location for that as it could
be included in blueprint.
However, failures should be taken into account in the api, as a failed
bundle state won't change anymore.

On Thursday, August 9, 2012, Andreas Pieber wrote:

> Hey JB,
>
> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]<javascript:;>>
> wrote:
> > Hi Andreas,
> >
> > it depends what we consider when saying "bundle started". From a OSGi
> > perspective, the bundle is started.
>
> I think there are various lvls here (and thats the reason why I
> consider the ReadyService, as proposed by Christoph, such a good
> idea). Consider that we register those ReadyServices via the activator
> they will be available once the bundle is active; once all framework
> bundles are active the feature service can state once he had installed
> all features, the deployer can state once all bundles from the deploy
> folder had been added, a custom application bundle can e.g. check if a
> specific url could be reached and so on; This could finally provide a
> "suite" which could be adapted to give a user a quite accurate "real"
> start-point (even if it requires some manual adaption). I'm really
> interested what you think about this once you've given it a little bit
> more time for consideration :-)
>
> >
> > However I'm agree about the featuresBoot (AFAIR we have a Jira about
> that).
> >
> > I will take time deeper later (time to go dinner for me here ;)).
>
> Dinner? Wow, I really should take more time keeping up-to-date; where
> the hell are you :-)
>
> Kind regards,
> Andreas
>
> >
> > Regards
> > JB
> >
> >
> > On 08/09/2012 05:08 AM, Andreas Pieber wrote:
> >>
> >> Hey guys,
> >>
> >> While the 2.3.x code looks ways more stable than the one on the master
> >> I'm not convinced that it will solve Christoph's problem. As Christoph
> >> pointed out:
> >>
> >> "There is a short delay between the point where all karaf-base-bundles
> >> are loaded and the feature-installer starts installing features
> >> specified in "featuresBoot". When starting up the first time, this
> >> almost always happens"
> >>
> >> I would say the relevant parts in Karaf 2.3.x are:
> >>
> >> a) StartupListener.java
> >> b) DelayedStarted.java
> >>
> >> So, If I'm correct (a) is printing the number of active
> >> bundles/available bundles till (b) set a constant which will occur the
> >> moment a bundle is added with a start lvl higher than
> >> "org.osgi.framework.startlevel.beginning". That's basically fine, but
> >> this will still not fix the problem with the feature service adding
> >> bundles (with even higher start lvls) AFTER the framework startup. In
> >> addition we've the "old" problem of various parts (blueprint, webapps,
> >> deployer, ...) starting up async. While most of those components know
> >> when they're finished (a) cannot know. This has the advantage that it
> >> has no problem if a bundle is e.g. caught in a startup loop, but on
> >> the other hand you wont know when all bundles are active. In addition
> >> it will show the framework ready although bundles with a startup lvl
> >> higher than "org.osgi.framework.startlevel.beginning" are still
> >> starting.
> >>
> >> Therefore I'm curious if the process shouldn't be something like
> >>
> >> a) wait till all bundles are active or one have failed
> >> b) once all bundles are active query for a StartupIndicator service
> >> and wait till all of them either return finished or failed
> >> c) once all startup indicators are finished wait again till all
> >> (possibly new bundles) are active
> >> d) now there are maybe new StartupIndicators available or everything
> >> is up and running
> >>
> >> Do I miss anything? WDYT?
> >>
> >> Kind regards,
> >> Andreas
> >>
> >> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
> >> wrote:
> >>>
> >>> Hi Christoph,
> >>>
> >>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
> >>> progress bar while Karaf is starting and the shell console arrives only
> >>> when
> >>> the startup is complete.
> >>>
> >>> I invite you to take a look on that.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I had another meeting with a customer today who asked me: "How can I
> >>>> tell whether it is started up completely?". ("It" being our
> karaf-based
> >>>> product)
> >>>>
> >>>> So I had a look at several alternatives how I could accomplish this
> and
> >>>> had an idea I wanted to discuss.
> >>>>
> >>>> I know that I can modify the Start-level of the Shell-bundle but I
> don't
> >>>> think that's enough.
> >>>> Recently Christian Schneider implemented something to delay the
> startup
> >>>> of the shell until all bundles are active. I think that's a good
> start,
> >>>> but does not solve the problem completely for me. I encountered
> several
> >>>> issues with the approach:
> >>>>
> >>>> 1. There is a short delay between the point where all
> karaf-base-bundles
> >>>> are loaded and the feature-installer starts installing features
> >>>> specified in "featuresBoot". When starting up the first time, this
> >>>> almost always happens
> >>>>
> >>>> ...
> >>>>          [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
> >>>>          [  46] [



--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

jgoodyear
Just my 2 cents CAD...

I think that this effort may be leading to diminishing returns ..
there are many edge cases we may hit here, and i don't want to see
Karaf's console take minutes to become available. So here is my
alternative suggestion:

Allow Karaf console to come up as per start level as we've been doing
for a long time now, but include two new messages that will be printed
to the console screen:

1: Welcome to Karaf ${version}, bundles are still loading....
2: All bundles started, happy hacking!

The message content can be changed to suit our needs - the main thing
is that the console will be available to users right away.

Cheers,
Jamie

On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]> wrote:

> Remember extenders can start bundles asynchronously, so the ReadyService
> should be registered by the extender from an activator.
> I'd think aries quiesce api could be a good location for that as it could
> be included in blueprint.
> However, failures should be taken into account in the api, as a failed
> bundle state won't change anymore.
>
> On Thursday, August 9, 2012, Andreas Pieber wrote:
>
>> Hey JB,
>>
>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]<javascript:;>>
>> wrote:
>> > Hi Andreas,
>> >
>> > it depends what we consider when saying "bundle started". From a OSGi
>> > perspective, the bundle is started.
>>
>> I think there are various lvls here (and thats the reason why I
>> consider the ReadyService, as proposed by Christoph, such a good
>> idea). Consider that we register those ReadyServices via the activator
>> they will be available once the bundle is active; once all framework
>> bundles are active the feature service can state once he had installed
>> all features, the deployer can state once all bundles from the deploy
>> folder had been added, a custom application bundle can e.g. check if a
>> specific url could be reached and so on; This could finally provide a
>> "suite" which could be adapted to give a user a quite accurate "real"
>> start-point (even if it requires some manual adaption). I'm really
>> interested what you think about this once you've given it a little bit
>> more time for consideration :-)
>>
>> >
>> > However I'm agree about the featuresBoot (AFAIR we have a Jira about
>> that).
>> >
>> > I will take time deeper later (time to go dinner for me here ;)).
>>
>> Dinner? Wow, I really should take more time keeping up-to-date; where
>> the hell are you :-)
>>
>> Kind regards,
>> Andreas
>>
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>> >>
>> >> Hey guys,
>> >>
>> >> While the 2.3.x code looks ways more stable than the one on the master
>> >> I'm not convinced that it will solve Christoph's problem. As Christoph
>> >> pointed out:
>> >>
>> >> "There is a short delay between the point where all karaf-base-bundles
>> >> are loaded and the feature-installer starts installing features
>> >> specified in "featuresBoot". When starting up the first time, this
>> >> almost always happens"
>> >>
>> >> I would say the relevant parts in Karaf 2.3.x are:
>> >>
>> >> a) StartupListener.java
>> >> b) DelayedStarted.java
>> >>
>> >> So, If I'm correct (a) is printing the number of active
>> >> bundles/available bundles till (b) set a constant which will occur the
>> >> moment a bundle is added with a start lvl higher than
>> >> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>> >> this will still not fix the problem with the feature service adding
>> >> bundles (with even higher start lvls) AFTER the framework startup. In
>> >> addition we've the "old" problem of various parts (blueprint, webapps,
>> >> deployer, ...) starting up async. While most of those components know
>> >> when they're finished (a) cannot know. This has the advantage that it
>> >> has no problem if a bundle is e.g. caught in a startup loop, but on
>> >> the other hand you wont know when all bundles are active. In addition
>> >> it will show the framework ready although bundles with a startup lvl
>> >> higher than "org.osgi.framework.startlevel.beginning" are still
>> >> starting.
>> >>
>> >> Therefore I'm curious if the process shouldn't be something like
>> >>
>> >> a) wait till all bundles are active or one have failed
>> >> b) once all bundles are active query for a StartupIndicator service
>> >> and wait till all of them either return finished or failed
>> >> c) once all startup indicators are finished wait again till all
>> >> (possibly new bundles) are active
>> >> d) now there are maybe new StartupIndicators available or everything
>> >> is up and running
>> >>
>> >> Do I miss anything? WDYT?
>> >>
>> >> Kind regards,
>> >> Andreas
>> >>
>> >> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Hi Christoph,
>> >>>
>> >>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
>> >>> progress bar while Karaf is starting and the shell console arrives only
>> >>> when
>> >>> the startup is complete.
>> >>>
>> >>> I invite you to take a look on that.
>> >>>
>> >>> Regards
>> >>> JB
>> >>>
>> >>>
>> >>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>> >>>>
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I had another meeting with a customer today who asked me: "How can I
>> >>>> tell whether it is started up completely?". ("It" being our
>> karaf-based
>> >>>> product)
>> >>>>
>> >>>> So I had a look at several alternatives how I could accomplish this
>> and
>> >>>> had an idea I wanted to discuss.
>> >>>>
>> >>>> I know that I can modify the Start-level of the Shell-bundle but I
>> don't
>> >>>> think that's enough.
>> >>>> Recently Christian Schneider implemented something to delay the
>> startup
>> >>>> of the shell until all bundles are active. I think that's a good
>> start,
>> >>>> but does not solve the problem completely for me. I encountered
>> several
>> >>>> issues with the approach:
>> >>>>
>> >>>> 1. There is a short delay between the point where all
>> karaf-base-bundles
>> >>>> are loaded and the feature-installer starts installing features
>> >>>> specified in "featuresBoot". When starting up the first time, this
>> >>>> almost always happens
>> >>>>
>> >>>> ...
>> >>>>          [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>> >>>>          [  46] [
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Achim Nierbeck
Hi,

I have to second Jamie on this, cause right now I'm quite happy with
having a shell right away so
if I'm really in need for knowing if all bundles are up and runnig
I'll do a "la" and I'm fine knowing how it's proceeding.
For me there is no real need to hide the shell from users, cause let's
take a look on how long is a Server process supposed to run
at best forever or the time the machine dies. So basically it'll have
the same up-time as the machine which will be longer on
linux then on windows. Compared to the uptime the time it takes to
load the complete set of bundles (if it's about a 100) is about 3
minutes (worst case).
Now  3 / infinity = 0 so I don't see a point of making so much fuzz
about a 3 minutes window for starting a fresh karaf (a reboot is
always much faster).
For knowing if my application is around I'm with charles to say, hey
use JMX to monitor your application. There are plenty of Nexus
connectors around to monitor
any application with JMX.

Just my 2 cents here ...

regards, Achim

2012/8/9 Jamie G. <[hidden email]>:

> Just my 2 cents CAD...
>
> I think that this effort may be leading to diminishing returns ..
> there are many edge cases we may hit here, and i don't want to see
> Karaf's console take minutes to become available. So here is my
> alternative suggestion:
>
> Allow Karaf console to come up as per start level as we've been doing
> for a long time now, but include two new messages that will be printed
> to the console screen:
>
> 1: Welcome to Karaf ${version}, bundles are still loading....
> 2: All bundles started, happy hacking!
>
> The message content can be changed to suit our needs - the main thing
> is that the console will be available to users right away.
>
> Cheers,
> Jamie
>
> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]> wrote:
>> Remember extenders can start bundles asynchronously, so the ReadyService
>> should be registered by the extender from an activator.
>> I'd think aries quiesce api could be a good location for that as it could
>> be included in blueprint.
>> However, failures should be taken into account in the api, as a failed
>> bundle state won't change anymore.
>>
>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>
>>> Hey JB,
>>>
>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]<javascript:;>>
>>> wrote:
>>> > Hi Andreas,
>>> >
>>> > it depends what we consider when saying "bundle started". From a OSGi
>>> > perspective, the bundle is started.
>>>
>>> I think there are various lvls here (and thats the reason why I
>>> consider the ReadyService, as proposed by Christoph, such a good
>>> idea). Consider that we register those ReadyServices via the activator
>>> they will be available once the bundle is active; once all framework
>>> bundles are active the feature service can state once he had installed
>>> all features, the deployer can state once all bundles from the deploy
>>> folder had been added, a custom application bundle can e.g. check if a
>>> specific url could be reached and so on; This could finally provide a
>>> "suite" which could be adapted to give a user a quite accurate "real"
>>> start-point (even if it requires some manual adaption). I'm really
>>> interested what you think about this once you've given it a little bit
>>> more time for consideration :-)
>>>
>>> >
>>> > However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>> that).
>>> >
>>> > I will take time deeper later (time to go dinner for me here ;)).
>>>
>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>> the hell are you :-)
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> >
>>> > Regards
>>> > JB
>>> >
>>> >
>>> > On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>> >>
>>> >> Hey guys,
>>> >>
>>> >> While the 2.3.x code looks ways more stable than the one on the master
>>> >> I'm not convinced that it will solve Christoph's problem. As Christoph
>>> >> pointed out:
>>> >>
>>> >> "There is a short delay between the point where all karaf-base-bundles
>>> >> are loaded and the feature-installer starts installing features
>>> >> specified in "featuresBoot". When starting up the first time, this
>>> >> almost always happens"
>>> >>
>>> >> I would say the relevant parts in Karaf 2.3.x are:
>>> >>
>>> >> a) StartupListener.java
>>> >> b) DelayedStarted.java
>>> >>
>>> >> So, If I'm correct (a) is printing the number of active
>>> >> bundles/available bundles till (b) set a constant which will occur the
>>> >> moment a bundle is added with a start lvl higher than
>>> >> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>>> >> this will still not fix the problem with the feature service adding
>>> >> bundles (with even higher start lvls) AFTER the framework startup. In
>>> >> addition we've the "old" problem of various parts (blueprint, webapps,
>>> >> deployer, ...) starting up async. While most of those components know
>>> >> when they're finished (a) cannot know. This has the advantage that it
>>> >> has no problem if a bundle is e.g. caught in a startup loop, but on
>>> >> the other hand you wont know when all bundles are active. In addition
>>> >> it will show the framework ready although bundles with a startup lvl
>>> >> higher than "org.osgi.framework.startlevel.beginning" are still
>>> >> starting.
>>> >>
>>> >> Therefore I'm curious if the process shouldn't be something like
>>> >>
>>> >> a) wait till all bundles are active or one have failed
>>> >> b) once all bundles are active query for a StartupIndicator service
>>> >> and wait till all of them either return finished or failed
>>> >> c) once all startup indicators are finished wait again till all
>>> >> (possibly new bundles) are active
>>> >> d) now there are maybe new StartupIndicators available or everything
>>> >> is up and running
>>> >>
>>> >> Do I miss anything? WDYT?
>>> >>
>>> >> Kind regards,
>>> >> Andreas
>>> >>
>>> >> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> Hi Christoph,
>>> >>>
>>> >>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
>>> >>> progress bar while Karaf is starting and the shell console arrives only
>>> >>> when
>>> >>> the startup is complete.
>>> >>>
>>> >>> I invite you to take a look on that.
>>> >>>
>>> >>> Regards
>>> >>> JB
>>> >>>
>>> >>>
>>> >>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>> >>>>
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> I had another meeting with a customer today who asked me: "How can I
>>> >>>> tell whether it is started up completely?". ("It" being our
>>> karaf-based
>>> >>>> product)
>>> >>>>
>>> >>>> So I had a look at several alternatives how I could accomplish this
>>> and
>>> >>>> had an idea I wanted to discuss.
>>> >>>>
>>> >>>> I know that I can modify the Start-level of the Shell-bundle but I
>>> don't
>>> >>>> think that's enough.
>>> >>>> Recently Christian Schneider implemented something to delay the
>>> startup
>>> >>>> of the shell until all bundles are active. I think that's a good
>>> start,
>>> >>>> but does not solve the problem completely for me. I encountered
>>> several
>>> >>>> issues with the approach:
>>> >>>>
>>> >>>> 1. There is a short delay between the point where all
>>> karaf-base-bundles
>>> >>>> are loaded and the feature-installer starts installing features
>>> >>>> specified in "featuresBoot". When starting up the first time, this
>>> >>>> almost always happens
>>> >>>>
>>> >>>> ...
>>> >>>>          [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>> >>>>          [  46] [
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com



--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

seijoed
+2 pence.

On Aug 9, 2012, at 5:26 AM, Achim Nierbeck wrote:

> Hi,
>
> I have to second Jamie on this, cause right now I'm quite happy with
> having a shell right away so
> if I'm really in need for knowing if all bundles are up and runnig
> I'll do a "la" and I'm fine knowing how it's proceeding.
> For me there is no real need to hide the shell from users, cause let's
> take a look on how long is a Server process supposed to run
> at best forever or the time the machine dies. So basically it'll have
> the same up-time as the machine which will be longer on
> linux then on windows. Compared to the uptime the time it takes to
> load the complete set of bundles (if it's about a 100) is about 3
> minutes (worst case).
> Now  3 / infinity = 0 so I don't see a point of making so much fuzz
> about a 3 minutes window for starting a fresh karaf (a reboot is
> always much faster).
> For knowing if my application is around I'm with charles to say, hey
> use JMX to monitor your application. There are plenty of Nexus
> connectors around to monitor
> any application with JMX.
>
> Just my 2 cents here ...
>
> regards, Achim
>
> 2012/8/9 Jamie G. <[hidden email]>:
>> Just my 2 cents CAD...
>>
>> I think that this effort may be leading to diminishing returns ..
>> there are many edge cases we may hit here, and i don't want to see
>> Karaf's console take minutes to become available. So here is my
>> alternative suggestion:
>>
>> Allow Karaf console to come up as per start level as we've been doing
>> for a long time now, but include two new messages that will be printed
>> to the console screen:
>>
>> 1: Welcome to Karaf ${version}, bundles are still loading....
>> 2: All bundles started, happy hacking!
>>
>> The message content can be changed to suit our needs - the main thing
>> is that the console will be available to users right away.
>>
>> Cheers,
>> Jamie
>>
>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]> wrote:
>>> Remember extenders can start bundles asynchronously, so the ReadyService
>>> should be registered by the extender from an activator.
>>> I'd think aries quiesce api could be a good location for that as it could
>>> be included in blueprint.
>>> However, failures should be taken into account in the api, as a failed
>>> bundle state won't change anymore.
>>>
>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>
>>>> Hey JB,
>>>>
>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]<javascript:;>>
>>>> wrote:
>>>>> Hi Andreas,
>>>>>
>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>> perspective, the bundle is started.
>>>>
>>>> I think there are various lvls here (and thats the reason why I
>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>> idea). Consider that we register those ReadyServices via the activator
>>>> they will be available once the bundle is active; once all framework
>>>> bundles are active the feature service can state once he had installed
>>>> all features, the deployer can state once all bundles from the deploy
>>>> folder had been added, a custom application bundle can e.g. check if a
>>>> specific url could be reached and so on; This could finally provide a
>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>> start-point (even if it requires some manual adaption). I'm really
>>>> interested what you think about this once you've given it a little bit
>>>> more time for consideration :-)
>>>>
>>>>>
>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>> that).
>>>>>
>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>
>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>> the hell are you :-)
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> While the 2.3.x code looks ways more stable than the one on the master
>>>>>> I'm not convinced that it will solve Christoph's problem. As Christoph
>>>>>> pointed out:
>>>>>>
>>>>>> "There is a short delay between the point where all karaf-base-bundles
>>>>>> are loaded and the feature-installer starts installing features
>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>> almost always happens"
>>>>>>
>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>
>>>>>> a) StartupListener.java
>>>>>> b) DelayedStarted.java
>>>>>>
>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>> bundles/available bundles till (b) set a constant which will occur the
>>>>>> moment a bundle is added with a start lvl higher than
>>>>>> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>>>>>> this will still not fix the problem with the feature service adding
>>>>>> bundles (with even higher start lvls) AFTER the framework startup. In
>>>>>> addition we've the "old" problem of various parts (blueprint, webapps,
>>>>>> deployer, ...) starting up async. While most of those components know
>>>>>> when they're finished (a) cannot know. This has the advantage that it
>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>> the other hand you wont know when all bundles are active. In addition
>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>> higher than "org.osgi.framework.startlevel.beginning" are still
>>>>>> starting.
>>>>>>
>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>
>>>>>> a) wait till all bundles are active or one have failed
>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>> and wait till all of them either return finished or failed
>>>>>> c) once all startup indicators are finished wait again till all
>>>>>> (possibly new bundles) are active
>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>> is up and running
>>>>>>
>>>>>> Do I miss anything? WDYT?
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Christoph,
>>>>>>>
>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
>>>>>>> progress bar while Karaf is starting and the shell console arrives only
>>>>>>> when
>>>>>>> the startup is complete.
>>>>>>>
>>>>>>> I invite you to take a look on that.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I had another meeting with a customer today who asked me: "How can I
>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>> karaf-based
>>>>>>>> product)
>>>>>>>>
>>>>>>>> So I had a look at several alternatives how I could accomplish this
>>>> and
>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>
>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>> don't
>>>>>>>> think that's enough.
>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>> startup
>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>> start,
>>>>>>>> but does not solve the problem completely for me. I encountered
>>>> several
>>>>>>>> issues with the approach:
>>>>>>>>
>>>>>>>> 1. There is a short delay between the point where all
>>>> karaf-base-bundles
>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>> almost always happens
>>>>>>>>
>>>>>>>> ...
>>>>>>>>         [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>         [  46] [
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>

Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

cschneider
In reply to this post by jgoodyear
This is almost like the current solution.

The only difference is that the shell currently only starts when the
startlevel is reached or when the user presses enter.

I also thought about printing a message when karaf finished loading. The
problem is that the user might just be typing at that moment so the
message would scramble his input. This
is why the current solution waits. When the user presses enter the
progress bar is stopped and no further messages are printed. So we do
not interfere with the user input.

So I really like what we have right now and think we should not add a
further listener to the startup. Like proposed before.

The case of monitoring is completely different and I think the new
BundleService in karaf 3 can help with that case a lot like mentioned in
my other mail.

About the startup time vs run time in production Achim mentioned. This
is definately true for the long run. We should remember though that the
startup of karaf is the first thing a users sees when starting karaf for
the first time. So I think it is worth putting some effort into the
startup to make the first experience with karaf a pleasant one for the
user. For many people these first moments may decide if they are willing
to put more effort into understanding and using karaf or try the next
product.

Christian

Am 09.08.2012 13:19, schrieb Jamie G.:

> Just my 2 cents CAD...
>
> I think that this effort may be leading to diminishing returns ..
> there are many edge cases we may hit here, and i don't want to see
> Karaf's console take minutes to become available. So here is my
> alternative suggestion:
>
> Allow Karaf console to come up as per start level as we've been doing
> for a long time now, but include two new messages that will be printed
> to the console screen:
>
> 1: Welcome to Karaf ${version}, bundles are still loading....
> 2: All bundles started, happy hacking!
>
> The message content can be changed to suit our needs - the main thing
> is that the console will be available to users right away.
>
> Cheers,
> Jamie
>
> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]> wrote:
>> Remember extenders can start bundles asynchronously, so the ReadyService
>> should be registered by the extender from an activator.
>> I'd think aries quiesce api could be a good location for that as it could
>> be included in blueprint.
>> However, failures should be taken into account in the api, as a failed
>> bundle state won't change anymore.
>>
>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>
>>> Hey JB,
>>>
>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <[hidden email]<javascript:;>>
>>> wrote:
>>>> Hi Andreas,
>>>>
>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>> perspective, the bundle is started.
>>> I think there are various lvls here (and thats the reason why I
>>> consider the ReadyService, as proposed by Christoph, such a good
>>> idea). Consider that we register those ReadyServices via the activator
>>> they will be available once the bundle is active; once all framework
>>> bundles are active the feature service can state once he had installed
>>> all features, the deployer can state once all bundles from the deploy
>>> folder had been added, a custom application bundle can e.g. check if a
>>> specific url could be reached and so on; This could finally provide a
>>> "suite" which could be adapted to give a user a quite accurate "real"
>>> start-point (even if it requires some manual adaption). I'm really
>>> interested what you think about this once you've given it a little bit
>>> more time for consideration :-)
>>>
>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>> that).
>>>> I will take time deeper later (time to go dinner for me here ;)).
>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>> the hell are you :-)
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>> Hey guys,
>>>>>
>>>>> While the 2.3.x code looks ways more stable than the one on the master
>>>>> I'm not convinced that it will solve Christoph's problem. As Christoph
>>>>> pointed out:
>>>>>
>>>>> "There is a short delay between the point where all karaf-base-bundles
>>>>> are loaded and the feature-installer starts installing features
>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>> almost always happens"
>>>>>
>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>
>>>>> a) StartupListener.java
>>>>> b) DelayedStarted.java
>>>>>
>>>>> So, If I'm correct (a) is printing the number of active
>>>>> bundles/available bundles till (b) set a constant which will occur the
>>>>> moment a bundle is added with a start lvl higher than
>>>>> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>>>>> this will still not fix the problem with the feature service adding
>>>>> bundles (with even higher start lvls) AFTER the framework startup. In
>>>>> addition we've the "old" problem of various parts (blueprint, webapps,
>>>>> deployer, ...) starting up async. While most of those components know
>>>>> when they're finished (a) cannot know. This has the advantage that it
>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>> the other hand you wont know when all bundles are active. In addition
>>>>> it will show the framework ready although bundles with a startup lvl
>>>>> higher than "org.osgi.framework.startlevel.beginning" are still
>>>>> starting.
>>>>>
>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>
>>>>> a) wait till all bundles are active or one have failed
>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>> and wait till all of them either return finished or failed
>>>>> c) once all startup indicators are finished wait again till all
>>>>> (possibly new bundles) are active
>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>> is up and running
>>>>>
>>>>> Do I miss anything? WDYT?
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <[hidden email]>
>>>>> wrote:
>>>>>> Hi Christoph,
>>>>>>
>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
>>>>>> progress bar while Karaf is starting and the shell console arrives only
>>>>>> when
>>>>>> the startup is complete.
>>>>>>
>>>>>> I invite you to take a look on that.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I had another meeting with a customer today who asked me: "How can I
>>>>>>> tell whether it is started up completely?". ("It" being our
>>> karaf-based
>>>>>>> product)
>>>>>>>
>>>>>>> So I had a look at several alternatives how I could accomplish this
>>> and
>>>>>>> had an idea I wanted to discuss.
>>>>>>>
>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>> don't
>>>>>>> think that's enough.
>>>>>>> Recently Christian Schneider implemented something to delay the
>>> startup
>>>>>>> of the shell until all bundles are active. I think that's a good
>>> start,
>>>>>>> but does not solve the problem completely for me. I encountered
>>> several
>>>>>>> issues with the approach:
>>>>>>>
>>>>>>> 1. There is a short delay between the point where all
>>> karaf-base-bundles
>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>> almost always happens
>>>>>>>
>>>>>>> ...
>>>>>>>           [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>           [  46] [
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com


--
 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Christoph Gritschenberger
I understand that when using karaf as a developer one would want the
shell as fast as possible and don't wait for a minute or something.
That's why Christian implemented the "Press Enter to start it
anyway"-thing I think.
Maybe it's a better option to make it optional after all and disable it
in the karaf-distributions, but allowing users to modify some
config-file to get the delayed-console-startup.
This way developers are not annoyed by long startup-times, but
karaf-based products could provide the user with proper feedback.

And about the uptime vs startup time: I agree with Christian here. But
we have a customer who develops his own external systems that interact
with our karaf-based application. Their developers complained, they
can't tell when karaf is started, and they need to start and stop it
more often during development, but don't really want to get into karaf
to deeply because it's just an external system.

I could also try to implement something like that myself. The solution
with the "StartupIndicator"-services makes it easier to maintain because
I can describe the conditions to be met in the corresponding bundle
(which I reuse in several assemblies).
I could create an additional bundle querying those services and delay
the console with the right use of start-levels.

But at some points a tighter integration into karaf would be nice (like
the FeatureService).

kind regards,
christoph


On 09/08/12 13:59, Christian Schneider wrote:

> This is almost like the current solution.
>
> The only difference is that the shell currently only starts when the
> startlevel is reached or when the user presses enter.
>
> I also thought about printing a message when karaf finished loading. The
> problem is that the user might just be typing at that moment so the
> message would scramble his input. This
> is why the current solution waits. When the user presses enter the
> progress bar is stopped and no further messages are printed. So we do
> not interfere with the user input.
>
> So I really like what we have right now and think we should not add a
> further listener to the startup. Like proposed before.
>
> The case of monitoring is completely different and I think the new
> BundleService in karaf 3 can help with that case a lot like mentioned in
> my other mail.
>
> About the startup time vs run time in production Achim mentioned. This
> is definately true for the long run. We should remember though that the
> startup of karaf is the first thing a users sees when starting karaf for
> the first time. So I think it is worth putting some effort into the
> startup to make the first experience with karaf a pleasant one for the
> user. For many people these first moments may decide if they are willing
> to put more effort into understanding and using karaf or try the next
> product.
>
> Christian
>
> Am 09.08.2012 13:19, schrieb Jamie G.:
>> Just my 2 cents CAD...
>>
>> I think that this effort may be leading to diminishing returns ..
>> there are many edge cases we may hit here, and i don't want to see
>> Karaf's console take minutes to become available. So here is my
>> alternative suggestion:
>>
>> Allow Karaf console to come up as per start level as we've been doing
>> for a long time now, but include two new messages that will be printed
>> to the console screen:
>>
>> 1: Welcome to Karaf ${version}, bundles are still loading....
>> 2: All bundles started, happy hacking!
>>
>> The message content can be changed to suit our needs - the main thing
>> is that the console will be available to users right away.
>>
>> Cheers,
>> Jamie
>>
>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]> wrote:
>>> Remember extenders can start bundles asynchronously, so the ReadyService
>>> should be registered by the extender from an activator.
>>> I'd think aries quiesce api could be a good location for that as it
>>> could
>>> be included in blueprint.
>>> However, failures should be taken into account in the api, as a failed
>>> bundle state won't change anymore.
>>>
>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>
>>>> Hey JB,
>>>>
>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>> <[hidden email]<javascript:;>>
>>>> wrote:
>>>>> Hi Andreas,
>>>>>
>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>> perspective, the bundle is started.
>>>> I think there are various lvls here (and thats the reason why I
>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>> idea). Consider that we register those ReadyServices via the activator
>>>> they will be available once the bundle is active; once all framework
>>>> bundles are active the feature service can state once he had installed
>>>> all features, the deployer can state once all bundles from the deploy
>>>> folder had been added, a custom application bundle can e.g. check if a
>>>> specific url could be reached and so on; This could finally provide a
>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>> start-point (even if it requires some manual adaption). I'm really
>>>> interested what you think about this once you've given it a little bit
>>>> more time for consideration :-)
>>>>
>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>> that).
>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>> the hell are you :-)
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>> Hey guys,
>>>>>>
>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>> master
>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>> Christoph
>>>>>> pointed out:
>>>>>>
>>>>>> "There is a short delay between the point where all
>>>>>> karaf-base-bundles
>>>>>> are loaded and the feature-installer starts installing features
>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>> almost always happens"
>>>>>>
>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>
>>>>>> a) StartupListener.java
>>>>>> b) DelayedStarted.java
>>>>>>
>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>> the
>>>>>> moment a bundle is added with a start lvl higher than
>>>>>> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>>>>>> this will still not fix the problem with the feature service adding
>>>>>> bundles (with even higher start lvls) AFTER the framework startup. In
>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>> webapps,
>>>>>> deployer, ...) starting up async. While most of those components know
>>>>>> when they're finished (a) cannot know. This has the advantage that it
>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>> the other hand you wont know when all bundles are active. In addition
>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>> higher than "org.osgi.framework.startlevel.beginning" are still
>>>>>> starting.
>>>>>>
>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>
>>>>>> a) wait till all bundles are active or one have failed
>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>> and wait till all of them either return finished or failed
>>>>>> c) once all startup indicators are finished wait again till all
>>>>>> (possibly new bundles) are active
>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>> is up and running
>>>>>>
>>>>>> Do I miss anything? WDYT?
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>> <[hidden email]>
>>>>>> wrote:
>>>>>>> Hi Christoph,
>>>>>>>
>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>> have a
>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>> arrives only
>>>>>>> when
>>>>>>> the startup is complete.
>>>>>>>
>>>>>>> I invite you to take a look on that.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>> can I
>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>> karaf-based
>>>>>>>> product)
>>>>>>>>
>>>>>>>> So I had a look at several alternatives how I could accomplish this
>>>> and
>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>
>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>> don't
>>>>>>>> think that's enough.
>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>> startup
>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>> start,
>>>>>>>> but does not solve the problem completely for me. I encountered
>>>> several
>>>>>>>> issues with the approach:
>>>>>>>>
>>>>>>>> 1. There is a short delay between the point where all
>>>> karaf-base-bundles
>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>> almost always happens
>>>>>>>>
>>>>>>>> ...
>>>>>>>>           [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>           [  46] [
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>
>


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

jbonofre
Hi,

I'm not fully agree.

Karaf is a container, with the purpose to be fast, lightweight.
So what does it mean "Karaf started" ?

For instance, I gonna compare with JEE application server. When do you
consider that an application server is started:
- when the application server itself is up and running ?
- when the resources in the application server are up (datasource, JMS
server, etc) ?
- when the applications are started ?

All is question of perspective.

Regards
JB

On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:

> I understand that when using karaf as a developer one would want the
> shell as fast as possible and don't wait for a minute or something.
> That's why Christian implemented the "Press Enter to start it
> anyway"-thing I think.
> Maybe it's a better option to make it optional after all and disable it
> in the karaf-distributions, but allowing users to modify some
> config-file to get the delayed-console-startup.
> This way developers are not annoyed by long startup-times, but
> karaf-based products could provide the user with proper feedback.
>
> And about the uptime vs startup time: I agree with Christian here. But
> we have a customer who develops his own external systems that interact
> with our karaf-based application. Their developers complained, they
> can't tell when karaf is started, and they need to start and stop it
> more often during development, but don't really want to get into karaf
> to deeply because it's just an external system.
>
> I could also try to implement something like that myself. The solution
> with the "StartupIndicator"-services makes it easier to maintain because
> I can describe the conditions to be met in the corresponding bundle
> (which I reuse in several assemblies).
> I could create an additional bundle querying those services and delay
> the console with the right use of start-levels.
>
> But at some points a tighter integration into karaf would be nice (like
> the FeatureService).
>
> kind regards,
> christoph
>
>
> On 09/08/12 13:59, Christian Schneider wrote:
>> This is almost like the current solution.
>>
>> The only difference is that the shell currently only starts when the
>> startlevel is reached or when the user presses enter.
>>
>> I also thought about printing a message when karaf finished loading. The
>> problem is that the user might just be typing at that moment so the
>> message would scramble his input. This
>> is why the current solution waits. When the user presses enter the
>> progress bar is stopped and no further messages are printed. So we do
>> not interfere with the user input.
>>
>> So I really like what we have right now and think we should not add a
>> further listener to the startup. Like proposed before.
>>
>> The case of monitoring is completely different and I think the new
>> BundleService in karaf 3 can help with that case a lot like mentioned in
>> my other mail.
>>
>> About the startup time vs run time in production Achim mentioned. This
>> is definately true for the long run. We should remember though that the
>> startup of karaf is the first thing a users sees when starting karaf for
>> the first time. So I think it is worth putting some effort into the
>> startup to make the first experience with karaf a pleasant one for the
>> user. For many people these first moments may decide if they are willing
>> to put more effort into understanding and using karaf or try the next
>> product.
>>
>> Christian
>>
>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>> Just my 2 cents CAD...
>>>
>>> I think that this effort may be leading to diminishing returns ..
>>> there are many edge cases we may hit here, and i don't want to see
>>> Karaf's console take minutes to become available. So here is my
>>> alternative suggestion:
>>>
>>> Allow Karaf console to come up as per start level as we've been doing
>>> for a long time now, but include two new messages that will be printed
>>> to the console screen:
>>>
>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>> 2: All bundles started, happy hacking!
>>>
>>> The message content can be changed to suit our needs - the main thing
>>> is that the console will be available to users right away.
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]> wrote:
>>>> Remember extenders can start bundles asynchronously, so the ReadyService
>>>> should be registered by the extender from an activator.
>>>> I'd think aries quiesce api could be a good location for that as it
>>>> could
>>>> be included in blueprint.
>>>> However, failures should be taken into account in the api, as a failed
>>>> bundle state won't change anymore.
>>>>
>>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>>
>>>>> Hey JB,
>>>>>
>>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>>> <[hidden email]<javascript:;>>
>>>>> wrote:
>>>>>> Hi Andreas,
>>>>>>
>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>> perspective, the bundle is started.
>>>>> I think there are various lvls here (and thats the reason why I
>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>> they will be available once the bundle is active; once all framework
>>>>> bundles are active the feature service can state once he had installed
>>>>> all features, the deployer can state once all bundles from the deploy
>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>> specific url could be reached and so on; This could finally provide a
>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>> interested what you think about this once you've given it a little bit
>>>>> more time for consideration :-)
>>>>>
>>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>> that).
>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>> the hell are you :-)
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>> master
>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>> Christoph
>>>>>>> pointed out:
>>>>>>>
>>>>>>> "There is a short delay between the point where all
>>>>>>> karaf-base-bundles
>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>> almost always happens"
>>>>>>>
>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>
>>>>>>> a) StartupListener.java
>>>>>>> b) DelayedStarted.java
>>>>>>>
>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>> the
>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>> bundles (with even higher start lvls) AFTER the framework startup. In
>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>> webapps,
>>>>>>> deployer, ...) starting up async. While most of those components know
>>>>>>> when they're finished (a) cannot know. This has the advantage that it
>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>> the other hand you wont know when all bundles are active. In addition
>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>> higher than "org.osgi.framework.startlevel.beginning" are still
>>>>>>> starting.
>>>>>>>
>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>
>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>> and wait till all of them either return finished or failed
>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>> (possibly new bundles) are active
>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>> is up and running
>>>>>>>
>>>>>>> Do I miss anything? WDYT?
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Andreas
>>>>>>>
>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>> <[hidden email]>
>>>>>>> wrote:
>>>>>>>> Hi Christoph,
>>>>>>>>
>>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>>> have a
>>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>>> arrives only
>>>>>>>> when
>>>>>>>> the startup is complete.
>>>>>>>>
>>>>>>>> I invite you to take a look on that.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>>> can I
>>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>>> karaf-based
>>>>>>>>> product)
>>>>>>>>>
>>>>>>>>> So I had a look at several alternatives how I could accomplish this
>>>>> and
>>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>>
>>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>>> don't
>>>>>>>>> think that's enough.
>>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>>> startup
>>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>>> start,
>>>>>>>>> but does not solve the problem completely for me. I encountered
>>>>> several
>>>>>>>>> issues with the approach:
>>>>>>>>>
>>>>>>>>> 1. There is a short delay between the point where all
>>>>> karaf-base-bundles
>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>> almost always happens
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>            [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>>            [  46] [
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>>
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Charles Moulliard-2
Well said JB. This is exactly what I have explained this morning.

On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <[hidden email]>wrote:

> Hi,
>
> I'm not fully agree.
>
> Karaf is a container, with the purpose to be fast, lightweight.
> So what does it mean "Karaf started" ?
>
> For instance, I gonna compare with JEE application server. When do you
> consider that an application server is started:
> - when the application server itself is up and running ?
> - when the resources in the application server are up (datasource, JMS
> server, etc) ?
> - when the applications are started ?
>
> All is question of perspective.
>
> Regards
> JB
>
>
> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>
>> I understand that when using karaf as a developer one would want the
>> shell as fast as possible and don't wait for a minute or something.
>> That's why Christian implemented the "Press Enter to start it
>> anyway"-thing I think.
>> Maybe it's a better option to make it optional after all and disable it
>> in the karaf-distributions, but allowing users to modify some
>> config-file to get the delayed-console-startup.
>> This way developers are not annoyed by long startup-times, but
>> karaf-based products could provide the user with proper feedback.
>>
>> And about the uptime vs startup time: I agree with Christian here. But
>> we have a customer who develops his own external systems that interact
>> with our karaf-based application. Their developers complained, they
>> can't tell when karaf is started, and they need to start and stop it
>> more often during development, but don't really want to get into karaf
>> to deeply because it's just an external system.
>>
>> I could also try to implement something like that myself. The solution
>> with the "StartupIndicator"-services makes it easier to maintain because
>> I can describe the conditions to be met in the corresponding bundle
>> (which I reuse in several assemblies).
>> I could create an additional bundle querying those services and delay
>> the console with the right use of start-levels.
>>
>> But at some points a tighter integration into karaf would be nice (like
>> the FeatureService).
>>
>> kind regards,
>> christoph
>>
>>
>> On 09/08/12 13:59, Christian Schneider wrote:
>>
>>> This is almost like the current solution.
>>>
>>> The only difference is that the shell currently only starts when the
>>> startlevel is reached or when the user presses enter.
>>>
>>> I also thought about printing a message when karaf finished loading. The
>>> problem is that the user might just be typing at that moment so the
>>> message would scramble his input. This
>>> is why the current solution waits. When the user presses enter the
>>> progress bar is stopped and no further messages are printed. So we do
>>> not interfere with the user input.
>>>
>>> So I really like what we have right now and think we should not add a
>>> further listener to the startup. Like proposed before.
>>>
>>> The case of monitoring is completely different and I think the new
>>> BundleService in karaf 3 can help with that case a lot like mentioned in
>>> my other mail.
>>>
>>> About the startup time vs run time in production Achim mentioned. This
>>> is definately true for the long run. We should remember though that the
>>> startup of karaf is the first thing a users sees when starting karaf for
>>> the first time. So I think it is worth putting some effort into the
>>> startup to make the first experience with karaf a pleasant one for the
>>> user. For many people these first moments may decide if they are willing
>>> to put more effort into understanding and using karaf or try the next
>>> product.
>>>
>>> Christian
>>>
>>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>>
>>>> Just my 2 cents CAD...
>>>>
>>>> I think that this effort may be leading to diminishing returns ..
>>>> there are many edge cases we may hit here, and i don't want to see
>>>> Karaf's console take minutes to become available. So here is my
>>>> alternative suggestion:
>>>>
>>>> Allow Karaf console to come up as per start level as we've been doing
>>>> for a long time now, but include two new messages that will be printed
>>>> to the console screen:
>>>>
>>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>>> 2: All bundles started, happy hacking!
>>>>
>>>> The message content can be changed to suit our needs - the main thing
>>>> is that the console will be available to users right away.
>>>>
>>>> Cheers,
>>>> Jamie
>>>>
>>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]>
>>>> wrote:
>>>>
>>>>> Remember extenders can start bundles asynchronously, so the
>>>>> ReadyService
>>>>> should be registered by the extender from an activator.
>>>>> I'd think aries quiesce api could be a good location for that as it
>>>>> could
>>>>> be included in blueprint.
>>>>> However, failures should be taken into account in the api, as a failed
>>>>> bundle state won't change anymore.
>>>>>
>>>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>>>
>>>>>  Hey JB,
>>>>>>
>>>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>>>> <[hidden email]<javascript:;>**>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Andreas,
>>>>>>>
>>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>>> perspective, the bundle is started.
>>>>>>>
>>>>>> I think there are various lvls here (and thats the reason why I
>>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>>> they will be available once the bundle is active; once all framework
>>>>>> bundles are active the feature service can state once he had installed
>>>>>> all features, the deployer can state once all bundles from the deploy
>>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>>> specific url could be reached and so on; This could finally provide a
>>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>>> interested what you think about this once you've given it a little bit
>>>>>> more time for consideration :-)
>>>>>>
>>>>>>  However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>>>>
>>>>>> that).
>>>>>>
>>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>>>>
>>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>>> the hell are you :-)
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>>  Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>>
>>>>>>>> Hey guys,
>>>>>>>>
>>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>>> master
>>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>>> Christoph
>>>>>>>> pointed out:
>>>>>>>>
>>>>>>>> "There is a short delay between the point where all
>>>>>>>> karaf-base-bundles
>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>> almost always happens"
>>>>>>>>
>>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>>
>>>>>>>> a) StartupListener.java
>>>>>>>> b) DelayedStarted.java
>>>>>>>>
>>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>>> the
>>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's basically
>>>>>>>> fine, but
>>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>>>> In
>>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>>> webapps,
>>>>>>>> deployer, ...) starting up async. While most of those components
>>>>>>>> know
>>>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>>>> it
>>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>>> the other hand you wont know when all bundles are active. In
>>>>>>>> addition
>>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>>> higher than "org.osgi.framework.**startlevel.beginning" are still
>>>>>>>> starting.
>>>>>>>>
>>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>>
>>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>>> and wait till all of them either return finished or failed
>>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>>> (possibly new bundles) are active
>>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>>> is up and running
>>>>>>>>
>>>>>>>> Do I miss anything? WDYT?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>>> <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Christoph,
>>>>>>>>>
>>>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>>>> have a
>>>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>>>> arrives only
>>>>>>>>> when
>>>>>>>>> the startup is complete.
>>>>>>>>>
>>>>>>>>> I invite you to take a look on that.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>>>> can I
>>>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>>>>>>>>
>>>>>>>>> karaf-based
>>>>>>
>>>>>>> product)
>>>>>>>>>>
>>>>>>>>>> So I had a look at several alternatives how I could accomplish
>>>>>>>>>> this
>>>>>>>>>>
>>>>>>>>> and
>>>>>>
>>>>>>> had an idea I wanted to discuss.
>>>>>>>>>>
>>>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>>>>>>>>
>>>>>>>>> don't
>>>>>>
>>>>>>> think that's enough.
>>>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>>>>>>>>
>>>>>>>>> startup
>>>>>>
>>>>>>> of the shell until all bundles are active. I think that's a good
>>>>>>>>>>
>>>>>>>>> start,
>>>>>>
>>>>>>> but does not solve the problem completely for me. I encountered
>>>>>>>>>>
>>>>>>>>> several
>>>>>>
>>>>>>> issues with the approach:
>>>>>>>>>>
>>>>>>>>>> 1. There is a short delay between the point where all
>>>>>>>>>>
>>>>>>>>> karaf-base-bundles
>>>>>>
>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>> almost always happens
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>            [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>>>            [  46] [
>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>>>>
>>>>
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



--
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Achim Nierbeck
@Charles, JB

I fully agree with you, where is the line to be drawn here?

Well anyone who is developing with Karaf should know it's a totally
different way of working instead of using a bloated JEE-Container.
This discussion somehow reminds me of a thread I once read on the
felix-ml "I don't want to develop OSGi I just want to use it".

As far as I'm concerned you shouldn't "Develop" OSGi but you have to
get used to some constraints and projecting those to Karaf it's like
this, if the container is running you have a shell but it doesn't say
you application is running.
The bad thing about it is, all those people are used to live without,
neither JBoss nor Tomcat provide a shell.
Oh wait they do, it's just the std. plain HTML stuff and guess what
sometimes the std. wars are already up and running but your own isn't.
Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
no content unless all wars are up an running?
People just got used to slow running Web-applications that they don't
feel comfortable when beeing able to work faster it seems ...

again just my 2 cents

regards, Achim

2012/8/9 Charles Moulliard <[hidden email]>:

> Well said JB. This is exactly what I have explained this morning.
>
> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <[hidden email]>wrote:
>
>> Hi,
>>
>> I'm not fully agree.
>>
>> Karaf is a container, with the purpose to be fast, lightweight.
>> So what does it mean "Karaf started" ?
>>
>> For instance, I gonna compare with JEE application server. When do you
>> consider that an application server is started:
>> - when the application server itself is up and running ?
>> - when the resources in the application server are up (datasource, JMS
>> server, etc) ?
>> - when the applications are started ?
>>
>> All is question of perspective.
>>
>> Regards
>> JB
>>
>>
>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>
>>> I understand that when using karaf as a developer one would want the
>>> shell as fast as possible and don't wait for a minute or something.
>>> That's why Christian implemented the "Press Enter to start it
>>> anyway"-thing I think.
>>> Maybe it's a better option to make it optional after all and disable it
>>> in the karaf-distributions, but allowing users to modify some
>>> config-file to get the delayed-console-startup.
>>> This way developers are not annoyed by long startup-times, but
>>> karaf-based products could provide the user with proper feedback.
>>>
>>> And about the uptime vs startup time: I agree with Christian here. But
>>> we have a customer who develops his own external systems that interact
>>> with our karaf-based application. Their developers complained, they
>>> can't tell when karaf is started, and they need to start and stop it
>>> more often during development, but don't really want to get into karaf
>>> to deeply because it's just an external system.
>>>
>>> I could also try to implement something like that myself. The solution
>>> with the "StartupIndicator"-services makes it easier to maintain because
>>> I can describe the conditions to be met in the corresponding bundle
>>> (which I reuse in several assemblies).
>>> I could create an additional bundle querying those services and delay
>>> the console with the right use of start-levels.
>>>
>>> But at some points a tighter integration into karaf would be nice (like
>>> the FeatureService).
>>>
>>> kind regards,
>>> christoph
>>>
>>>
>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>
>>>> This is almost like the current solution.
>>>>
>>>> The only difference is that the shell currently only starts when the
>>>> startlevel is reached or when the user presses enter.
>>>>
>>>> I also thought about printing a message when karaf finished loading. The
>>>> problem is that the user might just be typing at that moment so the
>>>> message would scramble his input. This
>>>> is why the current solution waits. When the user presses enter the
>>>> progress bar is stopped and no further messages are printed. So we do
>>>> not interfere with the user input.
>>>>
>>>> So I really like what we have right now and think we should not add a
>>>> further listener to the startup. Like proposed before.
>>>>
>>>> The case of monitoring is completely different and I think the new
>>>> BundleService in karaf 3 can help with that case a lot like mentioned in
>>>> my other mail.
>>>>
>>>> About the startup time vs run time in production Achim mentioned. This
>>>> is definately true for the long run. We should remember though that the
>>>> startup of karaf is the first thing a users sees when starting karaf for
>>>> the first time. So I think it is worth putting some effort into the
>>>> startup to make the first experience with karaf a pleasant one for the
>>>> user. For many people these first moments may decide if they are willing
>>>> to put more effort into understanding and using karaf or try the next
>>>> product.
>>>>
>>>> Christian
>>>>
>>>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>>>
>>>>> Just my 2 cents CAD...
>>>>>
>>>>> I think that this effort may be leading to diminishing returns ..
>>>>> there are many edge cases we may hit here, and i don't want to see
>>>>> Karaf's console take minutes to become available. So here is my
>>>>> alternative suggestion:
>>>>>
>>>>> Allow Karaf console to come up as per start level as we've been doing
>>>>> for a long time now, but include two new messages that will be printed
>>>>> to the console screen:
>>>>>
>>>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>>>> 2: All bundles started, happy hacking!
>>>>>
>>>>> The message content can be changed to suit our needs - the main thing
>>>>> is that the console will be available to users right away.
>>>>>
>>>>> Cheers,
>>>>> Jamie
>>>>>
>>>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Remember extenders can start bundles asynchronously, so the
>>>>>> ReadyService
>>>>>> should be registered by the extender from an activator.
>>>>>> I'd think aries quiesce api could be a good location for that as it
>>>>>> could
>>>>>> be included in blueprint.
>>>>>> However, failures should be taken into account in the api, as a failed
>>>>>> bundle state won't change anymore.
>>>>>>
>>>>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>>>>
>>>>>>  Hey JB,
>>>>>>>
>>>>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>>>>> <[hidden email]<javascript:;>**>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Andreas,
>>>>>>>>
>>>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>>>> perspective, the bundle is started.
>>>>>>>>
>>>>>>> I think there are various lvls here (and thats the reason why I
>>>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>>>> they will be available once the bundle is active; once all framework
>>>>>>> bundles are active the feature service can state once he had installed
>>>>>>> all features, the deployer can state once all bundles from the deploy
>>>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>>>> specific url could be reached and so on; This could finally provide a
>>>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>>>> interested what you think about this once you've given it a little bit
>>>>>>> more time for consideration :-)
>>>>>>>
>>>>>>>  However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>>>>>
>>>>>>> that).
>>>>>>>
>>>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>>>>>
>>>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>>>> the hell are you :-)
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Andreas
>>>>>>>
>>>>>>>  Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>>>
>>>>>>>>> Hey guys,
>>>>>>>>>
>>>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>>>> master
>>>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>>>> Christoph
>>>>>>>>> pointed out:
>>>>>>>>>
>>>>>>>>> "There is a short delay between the point where all
>>>>>>>>> karaf-base-bundles
>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>> almost always happens"
>>>>>>>>>
>>>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>>>
>>>>>>>>> a) StartupListener.java
>>>>>>>>> b) DelayedStarted.java
>>>>>>>>>
>>>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>>>> the
>>>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's basically
>>>>>>>>> fine, but
>>>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>>>>> In
>>>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>>>> webapps,
>>>>>>>>> deployer, ...) starting up async. While most of those components
>>>>>>>>> know
>>>>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>>>>> it
>>>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>>>> the other hand you wont know when all bundles are active. In
>>>>>>>>> addition
>>>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>>>> higher than "org.osgi.framework.**startlevel.beginning" are still
>>>>>>>>> starting.
>>>>>>>>>
>>>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>>>
>>>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>>>> and wait till all of them either return finished or failed
>>>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>>>> (possibly new bundles) are active
>>>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>>>> is up and running
>>>>>>>>>
>>>>>>>>> Do I miss anything? WDYT?
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Andreas
>>>>>>>>>
>>>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>>>> <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Christoph,
>>>>>>>>>>
>>>>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>>>>> have a
>>>>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>>>>> arrives only
>>>>>>>>>> when
>>>>>>>>>> the startup is complete.
>>>>>>>>>>
>>>>>>>>>> I invite you to take a look on that.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>>>>> can I
>>>>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>>>>>>>>>
>>>>>>>>>> karaf-based
>>>>>>>
>>>>>>>> product)
>>>>>>>>>>>
>>>>>>>>>>> So I had a look at several alternatives how I could accomplish
>>>>>>>>>>> this
>>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>
>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>>>>
>>>>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>>>>>>>>>
>>>>>>>>>> don't
>>>>>>>
>>>>>>>> think that's enough.
>>>>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>>>>>>>>>
>>>>>>>>>> startup
>>>>>>>
>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>>>>>>>>>
>>>>>>>>>> start,
>>>>>>>
>>>>>>>> but does not solve the problem completely for me. I encountered
>>>>>>>>>>>
>>>>>>>>>> several
>>>>>>>
>>>>>>>> issues with the approach:
>>>>>>>>>>>
>>>>>>>>>>> 1. There is a short delay between the point where all
>>>>>>>>>>>
>>>>>>>>>> karaf-base-bundles
>>>>>>>
>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>>> almost always happens
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>            [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>>>>            [  46] [
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>>>
>>>>>
>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com



--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Andreas Pieber
After reading the entire thread again I think we've got our wires
crossed. The entire point is NOT (!) to make Karaf waiting for
anything to start up per default; I second Christoph at this point: I
think it's best if the default Karaf download works exactly as it does
in the 2.2.x branch: getting the console up as fast as possible.
Independently, most of us had been confronted by one or the other
customer/partner, ... "When can I access my services"; typically I
just want to stand up in such situations, punch their faces and tell
them "once they work, they're ready"... Well, since those are my/our
customers this might not be the best solution. And this is where
Christians approach comes in handy: hide the console by default till
everything "is ready". As mentioned now by various ppl already: when
is the system ready; well, as JB said, Karaf as a small and neat
container does not have to find out; this is (IMHO) nothing we can
solve usefully at a central place for all and everything, BUT we can
solve it for our customers and their/our custom distributions by e.g.
placing a bundle doing all the logic and simply saying when Karaf is
ready.

So, back to the requirements; what do we need

a) per default nothing than we have now
b) if we deliver a distribution it would be nice if we can switch a
flag and the karaf console wont appear till my bundle says that its
ready

Basically Christians/Guillaume algorithms are almost enough for this:
once all bundles are active they had the chance to register a
"ReadService" via the activator. Waiting that those also get active
should be almost enough: why? Because my typical customer/project
partner has no real chance to find any errors in those phases on
himself anyhow --> he'll send me the log if the Shell isn't up in
10min --> we don't need to care if those services hang forever.
NOTHING of this is Karaf business; it would just be nice having some
extension point to extend the console wait time till I as a
distribution adapter say that it's ready.

And just to make it clear another time: I DON'T want to handle camel
routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
about:

"- when the application server itself is up and running ?
- when the resources in the application server are up (datasource, JMS
server, etc) ?
- when the applications are started ?"

For Karaf it's not relevant which of those things hide behind the
"ReadyServices"; we don't implement them! We just wait till all
registered "ReadyServices" say go and start the shell then; nothing
more and nothing less, just give distribution adapters a tool to
satisfy their customers :-)

I hope I was able to clear up things a little bit,
Kind regards,
Andreas

On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <[hidden email]> wrote:

> @Charles, JB
>
> I fully agree with you, where is the line to be drawn here?
>
> Well anyone who is developing with Karaf should know it's a totally
> different way of working instead of using a bloated JEE-Container.
> This discussion somehow reminds me of a thread I once read on the
> felix-ml "I don't want to develop OSGi I just want to use it".
>
> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
> get used to some constraints and projecting those to Karaf it's like
> this, if the container is running you have a shell but it doesn't say
> you application is running.
> The bad thing about it is, all those people are used to live without,
> neither JBoss nor Tomcat provide a shell.
> Oh wait they do, it's just the std. plain HTML stuff and guess what
> sometimes the std. wars are already up and running but your own isn't.
> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
> no content unless all wars are up an running?
> People just got used to slow running Web-applications that they don't
> feel comfortable when beeing able to work faster it seems ...
>
> again just my 2 cents
>
> regards, Achim
>
> 2012/8/9 Charles Moulliard <[hidden email]>:
>> Well said JB. This is exactly what I have explained this morning.
>>
>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <[hidden email]>wrote:
>>
>>> Hi,
>>>
>>> I'm not fully agree.
>>>
>>> Karaf is a container, with the purpose to be fast, lightweight.
>>> So what does it mean "Karaf started" ?
>>>
>>> For instance, I gonna compare with JEE application server. When do you
>>> consider that an application server is started:
>>> - when the application server itself is up and running ?
>>> - when the resources in the application server are up (datasource, JMS
>>> server, etc) ?
>>> - when the applications are started ?
>>>
>>> All is question of perspective.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>
>>>> I understand that when using karaf as a developer one would want the
>>>> shell as fast as possible and don't wait for a minute or something.
>>>> That's why Christian implemented the "Press Enter to start it
>>>> anyway"-thing I think.
>>>> Maybe it's a better option to make it optional after all and disable it
>>>> in the karaf-distributions, but allowing users to modify some
>>>> config-file to get the delayed-console-startup.
>>>> This way developers are not annoyed by long startup-times, but
>>>> karaf-based products could provide the user with proper feedback.
>>>>
>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>> we have a customer who develops his own external systems that interact
>>>> with our karaf-based application. Their developers complained, they
>>>> can't tell when karaf is started, and they need to start and stop it
>>>> more often during development, but don't really want to get into karaf
>>>> to deeply because it's just an external system.
>>>>
>>>> I could also try to implement something like that myself. The solution
>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>> I can describe the conditions to be met in the corresponding bundle
>>>> (which I reuse in several assemblies).
>>>> I could create an additional bundle querying those services and delay
>>>> the console with the right use of start-levels.
>>>>
>>>> But at some points a tighter integration into karaf would be nice (like
>>>> the FeatureService).
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>>
>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>
>>>>> This is almost like the current solution.
>>>>>
>>>>> The only difference is that the shell currently only starts when the
>>>>> startlevel is reached or when the user presses enter.
>>>>>
>>>>> I also thought about printing a message when karaf finished loading. The
>>>>> problem is that the user might just be typing at that moment so the
>>>>> message would scramble his input. This
>>>>> is why the current solution waits. When the user presses enter the
>>>>> progress bar is stopped and no further messages are printed. So we do
>>>>> not interfere with the user input.
>>>>>
>>>>> So I really like what we have right now and think we should not add a
>>>>> further listener to the startup. Like proposed before.
>>>>>
>>>>> The case of monitoring is completely different and I think the new
>>>>> BundleService in karaf 3 can help with that case a lot like mentioned in
>>>>> my other mail.
>>>>>
>>>>> About the startup time vs run time in production Achim mentioned. This
>>>>> is definately true for the long run. We should remember though that the
>>>>> startup of karaf is the first thing a users sees when starting karaf for
>>>>> the first time. So I think it is worth putting some effort into the
>>>>> startup to make the first experience with karaf a pleasant one for the
>>>>> user. For many people these first moments may decide if they are willing
>>>>> to put more effort into understanding and using karaf or try the next
>>>>> product.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>>>>
>>>>>> Just my 2 cents CAD...
>>>>>>
>>>>>> I think that this effort may be leading to diminishing returns ..
>>>>>> there are many edge cases we may hit here, and i don't want to see
>>>>>> Karaf's console take minutes to become available. So here is my
>>>>>> alternative suggestion:
>>>>>>
>>>>>> Allow Karaf console to come up as per start level as we've been doing
>>>>>> for a long time now, but include two new messages that will be printed
>>>>>> to the console screen:
>>>>>>
>>>>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>>>>> 2: All bundles started, happy hacking!
>>>>>>
>>>>>> The message content can be changed to suit our needs - the main thing
>>>>>> is that the console will be available to users right away.
>>>>>>
>>>>>> Cheers,
>>>>>> Jamie
>>>>>>
>>>>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Remember extenders can start bundles asynchronously, so the
>>>>>>> ReadyService
>>>>>>> should be registered by the extender from an activator.
>>>>>>> I'd think aries quiesce api could be a good location for that as it
>>>>>>> could
>>>>>>> be included in blueprint.
>>>>>>> However, failures should be taken into account in the api, as a failed
>>>>>>> bundle state won't change anymore.
>>>>>>>
>>>>>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>>>>>
>>>>>>>  Hey JB,
>>>>>>>>
>>>>>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>>>>>> <[hidden email]<javascript:;>**>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Andreas,
>>>>>>>>>
>>>>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>>>>> perspective, the bundle is started.
>>>>>>>>>
>>>>>>>> I think there are various lvls here (and thats the reason why I
>>>>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>>>>> they will be available once the bundle is active; once all framework
>>>>>>>> bundles are active the feature service can state once he had installed
>>>>>>>> all features, the deployer can state once all bundles from the deploy
>>>>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>>>>> specific url could be reached and so on; This could finally provide a
>>>>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>>>>> interested what you think about this once you've given it a little bit
>>>>>>>> more time for consideration :-)
>>>>>>>>
>>>>>>>>  However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>>>>>>
>>>>>>>> that).
>>>>>>>>
>>>>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>>>>>>
>>>>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>>>>> the hell are you :-)
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>>  Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>>>>
>>>>>>>>>> Hey guys,
>>>>>>>>>>
>>>>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>>>>> master
>>>>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>>>>> Christoph
>>>>>>>>>> pointed out:
>>>>>>>>>>
>>>>>>>>>> "There is a short delay between the point where all
>>>>>>>>>> karaf-base-bundles
>>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>> almost always happens"
>>>>>>>>>>
>>>>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>>>>
>>>>>>>>>> a) StartupListener.java
>>>>>>>>>> b) DelayedStarted.java
>>>>>>>>>>
>>>>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>>>>> the
>>>>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's basically
>>>>>>>>>> fine, but
>>>>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>>>>>> In
>>>>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>>>>> webapps,
>>>>>>>>>> deployer, ...) starting up async. While most of those components
>>>>>>>>>> know
>>>>>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>>>>>> it
>>>>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>>>>> the other hand you wont know when all bundles are active. In
>>>>>>>>>> addition
>>>>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>>>>> higher than "org.osgi.framework.**startlevel.beginning" are still
>>>>>>>>>> starting.
>>>>>>>>>>
>>>>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>>>>
>>>>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>>>>> and wait till all of them either return finished or failed
>>>>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>>>>> (possibly new bundles) are active
>>>>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>>>>> is up and running
>>>>>>>>>>
>>>>>>>>>> Do I miss anything? WDYT?
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Andreas
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>>>>> <[hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Christoph,
>>>>>>>>>>>
>>>>>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>>>>>> have a
>>>>>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>>>>>> arrives only
>>>>>>>>>>> when
>>>>>>>>>>> the startup is complete.
>>>>>>>>>>>
>>>>>>>>>>> I invite you to take a look on that.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>>>>>> can I
>>>>>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>>>>>>>>>>
>>>>>>>>>>> karaf-based
>>>>>>>>
>>>>>>>>> product)
>>>>>>>>>>>>
>>>>>>>>>>>> So I had a look at several alternatives how I could accomplish
>>>>>>>>>>>> this
>>>>>>>>>>>>
>>>>>>>>>>> and
>>>>>>>>
>>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>>>>>
>>>>>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>>>>>>>>>>
>>>>>>>>>>> don't
>>>>>>>>
>>>>>>>>> think that's enough.
>>>>>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>>>>>>>>>>
>>>>>>>>>>> startup
>>>>>>>>
>>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>>>>>>>>>>
>>>>>>>>>>> start,
>>>>>>>>
>>>>>>>>> but does not solve the problem completely for me. I encountered
>>>>>>>>>>>>
>>>>>>>>>>> several
>>>>>>>>
>>>>>>>>> issues with the approach:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. There is a short delay between the point where all
>>>>>>>>>>>>
>>>>>>>>>>> karaf-base-bundles
>>>>>>>>
>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>>>> almost always happens
>>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>>            [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>>>>>            [  46] [
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywhere
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> Charles Moulliard
>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>> Twitter : @cmoulliard
>> Blog : http://cmoulliard.blogspot.com
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

seijoed
What about logging?
Sorry :)
On Aug 9, 2012, at 10:43 AM, Andreas Pieber wrote:

> After reading the entire thread again I think we've got our wires
> crossed. The entire point is NOT (!) to make Karaf waiting for
> anything to start up per default; I second Christoph at this point: I
> think it's best if the default Karaf download works exactly as it does
> in the 2.2.x branch: getting the console up as fast as possible.
> Independently, most of us had been confronted by one or the other
> customer/partner, ... "When can I access my services"; typically I
> just want to stand up in such situations, punch their faces and tell
> them "once they work, they're ready"... Well, since those are my/our
> customers this might not be the best solution. And this is where
> Christians approach comes in handy: hide the console by default till
> everything "is ready". As mentioned now by various ppl already: when
> is the system ready; well, as JB said, Karaf as a small and neat
> container does not have to find out; this is (IMHO) nothing we can
> solve usefully at a central place for all and everything, BUT we can
> solve it for our customers and their/our custom distributions by e.g.
> placing a bundle doing all the logic and simply saying when Karaf is
> ready.
>
> So, back to the requirements; what do we need
>
> a) per default nothing than we have now
> b) if we deliver a distribution it would be nice if we can switch a
> flag and the karaf console wont appear till my bundle says that its
> ready
>
> Basically Christians/Guillaume algorithms are almost enough for this:
> once all bundles are active they had the chance to register a
> "ReadService" via the activator. Waiting that those also get active
> should be almost enough: why? Because my typical customer/project
> partner has no real chance to find any errors in those phases on
> himself anyhow --> he'll send me the log if the Shell isn't up in
> 10min --> we don't need to care if those services hang forever.
> NOTHING of this is Karaf business; it would just be nice having some
> extension point to extend the console wait time till I as a
> distribution adapter say that it's ready.
>
> And just to make it clear another time: I DON'T want to handle camel
> routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
> about:
>
> "- when the application server itself is up and running ?
> - when the resources in the application server are up (datasource, JMS
> server, etc) ?
> - when the applications are started ?"
>
> For Karaf it's not relevant which of those things hide behind the
> "ReadyServices"; we don't implement them! We just wait till all
> registered "ReadyServices" say go and start the shell then; nothing
> more and nothing less, just give distribution adapters a tool to
> satisfy their customers :-)
>
> I hope I was able to clear up things a little bit,
> Kind regards,
> Andreas
>
> On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <[hidden email]> wrote:
>> @Charles, JB
>>
>> I fully agree with you, where is the line to be drawn here?
>>
>> Well anyone who is developing with Karaf should know it's a totally
>> different way of working instead of using a bloated JEE-Container.
>> This discussion somehow reminds me of a thread I once read on the
>> felix-ml "I don't want to develop OSGi I just want to use it".
>>
>> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
>> get used to some constraints and projecting those to Karaf it's like
>> this, if the container is running you have a shell but it doesn't say
>> you application is running.
>> The bad thing about it is, all those people are used to live without,
>> neither JBoss nor Tomcat provide a shell.
>> Oh wait they do, it's just the std. plain HTML stuff and guess what
>> sometimes the std. wars are already up and running but your own isn't.
>> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
>> no content unless all wars are up an running?
>> People just got used to slow running Web-applications that they don't
>> feel comfortable when beeing able to work faster it seems ...
>>
>> again just my 2 cents
>>
>> regards, Achim
>>
>> 2012/8/9 Charles Moulliard <[hidden email]>:
>>> Well said JB. This is exactly what I have explained this morning.
>>>
>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <[hidden email]>wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm not fully agree.
>>>>
>>>> Karaf is a container, with the purpose to be fast, lightweight.
>>>> So what does it mean "Karaf started" ?
>>>>
>>>> For instance, I gonna compare with JEE application server. When do you
>>>> consider that an application server is started:
>>>> - when the application server itself is up and running ?
>>>> - when the resources in the application server are up (datasource, JMS
>>>> server, etc) ?
>>>> - when the applications are started ?
>>>>
>>>> All is question of perspective.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>>
>>>>> I understand that when using karaf as a developer one would want the
>>>>> shell as fast as possible and don't wait for a minute or something.
>>>>> That's why Christian implemented the "Press Enter to start it
>>>>> anyway"-thing I think.
>>>>> Maybe it's a better option to make it optional after all and disable it
>>>>> in the karaf-distributions, but allowing users to modify some
>>>>> config-file to get the delayed-console-startup.
>>>>> This way developers are not annoyed by long startup-times, but
>>>>> karaf-based products could provide the user with proper feedback.
>>>>>
>>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>>> we have a customer who develops his own external systems that interact
>>>>> with our karaf-based application. Their developers complained, they
>>>>> can't tell when karaf is started, and they need to start and stop it
>>>>> more often during development, but don't really want to get into karaf
>>>>> to deeply because it's just an external system.
>>>>>
>>>>> I could also try to implement something like that myself. The solution
>>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>>> I can describe the conditions to be met in the corresponding bundle
>>>>> (which I reuse in several assemblies).
>>>>> I could create an additional bundle querying those services and delay
>>>>> the console with the right use of start-levels.
>>>>>
>>>>> But at some points a tighter integration into karaf would be nice (like
>>>>> the FeatureService).
>>>>>
>>>>> kind regards,
>>>>> christoph
>>>>>
>>>>>
>>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>>
>>>>>> This is almost like the current solution.
>>>>>>
>>>>>> The only difference is that the shell currently only starts when the
>>>>>> startlevel is reached or when the user presses enter.
>>>>>>
>>>>>> I also thought about printing a message when karaf finished loading. The
>>>>>> problem is that the user might just be typing at that moment so the
>>>>>> message would scramble his input. This
>>>>>> is why the current solution waits. When the user presses enter the
>>>>>> progress bar is stopped and no further messages are printed. So we do
>>>>>> not interfere with the user input.
>>>>>>
>>>>>> So I really like what we have right now and think we should not add a
>>>>>> further listener to the startup. Like proposed before.
>>>>>>
>>>>>> The case of monitoring is completely different and I think the new
>>>>>> BundleService in karaf 3 can help with that case a lot like mentioned in
>>>>>> my other mail.
>>>>>>
>>>>>> About the startup time vs run time in production Achim mentioned. This
>>>>>> is definately true for the long run. We should remember though that the
>>>>>> startup of karaf is the first thing a users sees when starting karaf for
>>>>>> the first time. So I think it is worth putting some effort into the
>>>>>> startup to make the first experience with karaf a pleasant one for the
>>>>>> user. For many people these first moments may decide if they are willing
>>>>>> to put more effort into understanding and using karaf or try the next
>>>>>> product.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>>>>>
>>>>>>> Just my 2 cents CAD...
>>>>>>>
>>>>>>> I think that this effort may be leading to diminishing returns ..
>>>>>>> there are many edge cases we may hit here, and i don't want to see
>>>>>>> Karaf's console take minutes to become available. So here is my
>>>>>>> alternative suggestion:
>>>>>>>
>>>>>>> Allow Karaf console to come up as per start level as we've been doing
>>>>>>> for a long time now, but include two new messages that will be printed
>>>>>>> to the console screen:
>>>>>>>
>>>>>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>>>>>> 2: All bundles started, happy hacking!
>>>>>>>
>>>>>>> The message content can be changed to suit our needs - the main thing
>>>>>>> is that the console will be available to users right away.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jamie
>>>>>>>
>>>>>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Remember extenders can start bundles asynchronously, so the
>>>>>>>> ReadyService
>>>>>>>> should be registered by the extender from an activator.
>>>>>>>> I'd think aries quiesce api could be a good location for that as it
>>>>>>>> could
>>>>>>>> be included in blueprint.
>>>>>>>> However, failures should be taken into account in the api, as a failed
>>>>>>>> bundle state won't change anymore.
>>>>>>>>
>>>>>>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>>>>>>
>>>>>>>> Hey JB,
>>>>>>>>>
>>>>>>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>>>>>>> <[hidden email]<javascript:;>**>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Andreas,
>>>>>>>>>>
>>>>>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>>>>>> perspective, the bundle is started.
>>>>>>>>>>
>>>>>>>>> I think there are various lvls here (and thats the reason why I
>>>>>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>>>>>> they will be available once the bundle is active; once all framework
>>>>>>>>> bundles are active the feature service can state once he had installed
>>>>>>>>> all features, the deployer can state once all bundles from the deploy
>>>>>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>>>>>> specific url could be reached and so on; This could finally provide a
>>>>>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>>>>>> interested what you think about this once you've given it a little bit
>>>>>>>>> more time for consideration :-)
>>>>>>>>>
>>>>>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>>>>>>>
>>>>>>>>> that).
>>>>>>>>>
>>>>>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>>>>>>>
>>>>>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>>>>>> the hell are you :-)
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Andreas
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey guys,
>>>>>>>>>>>
>>>>>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>>>>>> master
>>>>>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>>>>>> Christoph
>>>>>>>>>>> pointed out:
>>>>>>>>>>>
>>>>>>>>>>> "There is a short delay between the point where all
>>>>>>>>>>> karaf-base-bundles
>>>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>>> almost always happens"
>>>>>>>>>>>
>>>>>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>>>>>
>>>>>>>>>>> a) StartupListener.java
>>>>>>>>>>> b) DelayedStarted.java
>>>>>>>>>>>
>>>>>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>>>>>> the
>>>>>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's basically
>>>>>>>>>>> fine, but
>>>>>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>>>>>>> In
>>>>>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>>>>>> webapps,
>>>>>>>>>>> deployer, ...) starting up async. While most of those components
>>>>>>>>>>> know
>>>>>>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>>>>>>> it
>>>>>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>>>>>> the other hand you wont know when all bundles are active. In
>>>>>>>>>>> addition
>>>>>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>>>>>> higher than "org.osgi.framework.**startlevel.beginning" are still
>>>>>>>>>>> starting.
>>>>>>>>>>>
>>>>>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>>>>>
>>>>>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>>>>>> and wait till all of them either return finished or failed
>>>>>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>>>>>> (possibly new bundles) are active
>>>>>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>>>>>> is up and running
>>>>>>>>>>>
>>>>>>>>>>> Do I miss anything? WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Andreas
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>>>>>> <[hidden email]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Christoph,
>>>>>>>>>>>>
>>>>>>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>>>>>>> have a
>>>>>>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>>>>>>> arrives only
>>>>>>>>>>>> when
>>>>>>>>>>>> the startup is complete.
>>>>>>>>>>>>
>>>>>>>>>>>> I invite you to take a look on that.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>> JB
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>>>>>>> can I
>>>>>>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>>>>>>>>>>>
>>>>>>>>>>>> karaf-based
>>>>>>>>>
>>>>>>>>>> product)
>>>>>>>>>>>>>
>>>>>>>>>>>>> So I had a look at several alternatives how I could accomplish
>>>>>>>>>>>>> this
>>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>
>>>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>>>>>>>>>>>
>>>>>>>>>>>> don't
>>>>>>>>>
>>>>>>>>>> think that's enough.
>>>>>>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>>>>>>>>>>>
>>>>>>>>>>>> startup
>>>>>>>>>
>>>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>>>>>>>>>>>
>>>>>>>>>>>> start,
>>>>>>>>>
>>>>>>>>>> but does not solve the problem completely for me. I encountered
>>>>>>>>>>>>>
>>>>>>>>>>>> several
>>>>>>>>>
>>>>>>>>>> issues with the approach:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. There is a short delay between the point where all
>>>>>>>>>>>>>
>>>>>>>>>>>> karaf-base-bundles
>>>>>>>>>
>>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>>>>> almost always happens
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>           [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>>>>>>           [  46] [
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> FuseSource, Integration everywhere
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> [hidden email]
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>> Twitter : @cmoulliard
>>> Blog : http://cmoulliard.blogspot.com
>>
>>
>>
>> --
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>> OPS4J Pax for Vaadin
>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>> Lead
>> blog <http://notizblog.nierbeck.de/>

Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

Andreas Pieber
what do you mean?

Kind regards,
Andreas

On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom <[hidden email]> wrote:

> What about logging?
> Sorry :)
> On Aug 9, 2012, at 10:43 AM, Andreas Pieber wrote:
>
>> After reading the entire thread again I think we've got our wires
>> crossed. The entire point is NOT (!) to make Karaf waiting for
>> anything to start up per default; I second Christoph at this point: I
>> think it's best if the default Karaf download works exactly as it does
>> in the 2.2.x branch: getting the console up as fast as possible.
>> Independently, most of us had been confronted by one or the other
>> customer/partner, ... "When can I access my services"; typically I
>> just want to stand up in such situations, punch their faces and tell
>> them "once they work, they're ready"... Well, since those are my/our
>> customers this might not be the best solution. And this is where
>> Christians approach comes in handy: hide the console by default till
>> everything "is ready". As mentioned now by various ppl already: when
>> is the system ready; well, as JB said, Karaf as a small and neat
>> container does not have to find out; this is (IMHO) nothing we can
>> solve usefully at a central place for all and everything, BUT we can
>> solve it for our customers and their/our custom distributions by e.g.
>> placing a bundle doing all the logic and simply saying when Karaf is
>> ready.
>>
>> So, back to the requirements; what do we need
>>
>> a) per default nothing than we have now
>> b) if we deliver a distribution it would be nice if we can switch a
>> flag and the karaf console wont appear till my bundle says that its
>> ready
>>
>> Basically Christians/Guillaume algorithms are almost enough for this:
>> once all bundles are active they had the chance to register a
>> "ReadService" via the activator. Waiting that those also get active
>> should be almost enough: why? Because my typical customer/project
>> partner has no real chance to find any errors in those phases on
>> himself anyhow --> he'll send me the log if the Shell isn't up in
>> 10min --> we don't need to care if those services hang forever.
>> NOTHING of this is Karaf business; it would just be nice having some
>> extension point to extend the console wait time till I as a
>> distribution adapter say that it's ready.
>>
>> And just to make it clear another time: I DON'T want to handle camel
>> routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
>> about:
>>
>> "- when the application server itself is up and running ?
>> - when the resources in the application server are up (datasource, JMS
>> server, etc) ?
>> - when the applications are started ?"
>>
>> For Karaf it's not relevant which of those things hide behind the
>> "ReadyServices"; we don't implement them! We just wait till all
>> registered "ReadyServices" say go and start the shell then; nothing
>> more and nothing less, just give distribution adapters a tool to
>> satisfy their customers :-)
>>
>> I hope I was able to clear up things a little bit,
>> Kind regards,
>> Andreas
>>
>> On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <[hidden email]> wrote:
>>> @Charles, JB
>>>
>>> I fully agree with you, where is the line to be drawn here?
>>>
>>> Well anyone who is developing with Karaf should know it's a totally
>>> different way of working instead of using a bloated JEE-Container.
>>> This discussion somehow reminds me of a thread I once read on the
>>> felix-ml "I don't want to develop OSGi I just want to use it".
>>>
>>> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
>>> get used to some constraints and projecting those to Karaf it's like
>>> this, if the container is running you have a shell but it doesn't say
>>> you application is running.
>>> The bad thing about it is, all those people are used to live without,
>>> neither JBoss nor Tomcat provide a shell.
>>> Oh wait they do, it's just the std. plain HTML stuff and guess what
>>> sometimes the std. wars are already up and running but your own isn't.
>>> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
>>> no content unless all wars are up an running?
>>> People just got used to slow running Web-applications that they don't
>>> feel comfortable when beeing able to work faster it seems ...
>>>
>>> again just my 2 cents
>>>
>>> regards, Achim
>>>
>>> 2012/8/9 Charles Moulliard <[hidden email]>:
>>>> Well said JB. This is exactly what I have explained this morning.
>>>>
>>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <[hidden email]>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm not fully agree.
>>>>>
>>>>> Karaf is a container, with the purpose to be fast, lightweight.
>>>>> So what does it mean "Karaf started" ?
>>>>>
>>>>> For instance, I gonna compare with JEE application server. When do you
>>>>> consider that an application server is started:
>>>>> - when the application server itself is up and running ?
>>>>> - when the resources in the application server are up (datasource, JMS
>>>>> server, etc) ?
>>>>> - when the applications are started ?
>>>>>
>>>>> All is question of perspective.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>>>
>>>>>> I understand that when using karaf as a developer one would want the
>>>>>> shell as fast as possible and don't wait for a minute or something.
>>>>>> That's why Christian implemented the "Press Enter to start it
>>>>>> anyway"-thing I think.
>>>>>> Maybe it's a better option to make it optional after all and disable it
>>>>>> in the karaf-distributions, but allowing users to modify some
>>>>>> config-file to get the delayed-console-startup.
>>>>>> This way developers are not annoyed by long startup-times, but
>>>>>> karaf-based products could provide the user with proper feedback.
>>>>>>
>>>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>>>> we have a customer who develops his own external systems that interact
>>>>>> with our karaf-based application. Their developers complained, they
>>>>>> can't tell when karaf is started, and they need to start and stop it
>>>>>> more often during development, but don't really want to get into karaf
>>>>>> to deeply because it's just an external system.
>>>>>>
>>>>>> I could also try to implement something like that myself. The solution
>>>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>>>> I can describe the conditions to be met in the corresponding bundle
>>>>>> (which I reuse in several assemblies).
>>>>>> I could create an additional bundle querying those services and delay
>>>>>> the console with the right use of start-levels.
>>>>>>
>>>>>> But at some points a tighter integration into karaf would be nice (like
>>>>>> the FeatureService).
>>>>>>
>>>>>> kind regards,
>>>>>> christoph
>>>>>>
>>>>>>
>>>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>>>
>>>>>>> This is almost like the current solution.
>>>>>>>
>>>>>>> The only difference is that the shell currently only starts when the
>>>>>>> startlevel is reached or when the user presses enter.
>>>>>>>
>>>>>>> I also thought about printing a message when karaf finished loading. The
>>>>>>> problem is that the user might just be typing at that moment so the
>>>>>>> message would scramble his input. This
>>>>>>> is why the current solution waits. When the user presses enter the
>>>>>>> progress bar is stopped and no further messages are printed. So we do
>>>>>>> not interfere with the user input.
>>>>>>>
>>>>>>> So I really like what we have right now and think we should not add a
>>>>>>> further listener to the startup. Like proposed before.
>>>>>>>
>>>>>>> The case of monitoring is completely different and I think the new
>>>>>>> BundleService in karaf 3 can help with that case a lot like mentioned in
>>>>>>> my other mail.
>>>>>>>
>>>>>>> About the startup time vs run time in production Achim mentioned. This
>>>>>>> is definately true for the long run. We should remember though that the
>>>>>>> startup of karaf is the first thing a users sees when starting karaf for
>>>>>>> the first time. So I think it is worth putting some effort into the
>>>>>>> startup to make the first experience with karaf a pleasant one for the
>>>>>>> user. For many people these first moments may decide if they are willing
>>>>>>> to put more effort into understanding and using karaf or try the next
>>>>>>> product.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>>>>>>
>>>>>>>> Just my 2 cents CAD...
>>>>>>>>
>>>>>>>> I think that this effort may be leading to diminishing returns ..
>>>>>>>> there are many edge cases we may hit here, and i don't want to see
>>>>>>>> Karaf's console take minutes to become available. So here is my
>>>>>>>> alternative suggestion:
>>>>>>>>
>>>>>>>> Allow Karaf console to come up as per start level as we've been doing
>>>>>>>> for a long time now, but include two new messages that will be printed
>>>>>>>> to the console screen:
>>>>>>>>
>>>>>>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>>>>>>> 2: All bundles started, happy hacking!
>>>>>>>>
>>>>>>>> The message content can be changed to suit our needs - the main thing
>>>>>>>> is that the console will be available to users right away.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Jamie
>>>>>>>>
>>>>>>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Remember extenders can start bundles asynchronously, so the
>>>>>>>>> ReadyService
>>>>>>>>> should be registered by the extender from an activator.
>>>>>>>>> I'd think aries quiesce api could be a good location for that as it
>>>>>>>>> could
>>>>>>>>> be included in blueprint.
>>>>>>>>> However, failures should be taken into account in the api, as a failed
>>>>>>>>> bundle state won't change anymore.
>>>>>>>>>
>>>>>>>>> On Thursday, August 9, 2012, Andreas Pieber wrote:
>>>>>>>>>
>>>>>>>>> Hey JB,
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
>>>>>>>>>> <[hidden email]<javascript:;>**>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Andreas,
>>>>>>>>>>>
>>>>>>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>>>>>>> perspective, the bundle is started.
>>>>>>>>>>>
>>>>>>>>>> I think there are various lvls here (and thats the reason why I
>>>>>>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>>>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>>>>>>> they will be available once the bundle is active; once all framework
>>>>>>>>>> bundles are active the feature service can state once he had installed
>>>>>>>>>> all features, the deployer can state once all bundles from the deploy
>>>>>>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>>>>>>> specific url could be reached and so on; This could finally provide a
>>>>>>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>>>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>>>>>>> interested what you think about this once you've given it a little bit
>>>>>>>>>> more time for consideration :-)
>>>>>>>>>>
>>>>>>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>>>>>>>>
>>>>>>>>>> that).
>>>>>>>>>>
>>>>>>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>>>>>>>>
>>>>>>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>>>>>>> the hell are you :-)
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Andreas
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey guys,
>>>>>>>>>>>>
>>>>>>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>>>>>>> master
>>>>>>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>>>>>>> Christoph
>>>>>>>>>>>> pointed out:
>>>>>>>>>>>>
>>>>>>>>>>>> "There is a short delay between the point where all
>>>>>>>>>>>> karaf-base-bundles
>>>>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>>>> almost always happens"
>>>>>>>>>>>>
>>>>>>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>>>>>>
>>>>>>>>>>>> a) StartupListener.java
>>>>>>>>>>>> b) DelayedStarted.java
>>>>>>>>>>>>
>>>>>>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>>>>>>> the
>>>>>>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's basically
>>>>>>>>>>>> fine, but
>>>>>>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>>>>>>>> In
>>>>>>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>>>>>>> webapps,
>>>>>>>>>>>> deployer, ...) starting up async. While most of those components
>>>>>>>>>>>> know
>>>>>>>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>>>>>>>> it
>>>>>>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>>>>>>> the other hand you wont know when all bundles are active. In
>>>>>>>>>>>> addition
>>>>>>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>>>>>>> higher than "org.osgi.framework.**startlevel.beginning" are still
>>>>>>>>>>>> starting.
>>>>>>>>>>>>
>>>>>>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>>>>>>
>>>>>>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>>>>>>> and wait till all of them either return finished or failed
>>>>>>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>>>>>>> (possibly new bundles) are active
>>>>>>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>>>>>>> is up and running
>>>>>>>>>>>>
>>>>>>>>>>>> Do I miss anything? WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>> Andreas
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>>>>>>> <[hidden email]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Christoph,
>>>>>>>>>>>>>
>>>>>>>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>>>>>>>> have a
>>>>>>>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>>>>>>>> arrives only
>>>>>>>>>>>>> when
>>>>>>>>>>>>> the startup is complete.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I invite you to take a look on that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> JB
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>>>>>>>> can I
>>>>>>>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>>>>>>>>>>>>
>>>>>>>>>>>>> karaf-based
>>>>>>>>>>
>>>>>>>>>>> product)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So I had a look at several alternatives how I could accomplish
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>
>>>>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>>>>>>>>>>>>
>>>>>>>>>>>>> don't
>>>>>>>>>>
>>>>>>>>>>> think that's enough.
>>>>>>>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> startup
>>>>>>>>>>
>>>>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>>>>>>>>>>>>
>>>>>>>>>>>>> start,
>>>>>>>>>>
>>>>>>>>>>> but does not solve the problem completely for me. I encountered
>>>>>>>>>>>>>>
>>>>>>>>>>>>> several
>>>>>>>>>>
>>>>>>>>>>> issues with the approach:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. There is a short delay between the point where all
>>>>>>>>>>>>>>
>>>>>>>>>>>>> karaf-base-bundles
>>>>>>>>>>
>>>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>>>>>> almost always happens
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>           [  45] [    Active] [    5] OPS4J Base - Lang (1.3.0)
>>>>>>>>>>>>>>           [  46] [
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ------------------------
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> FuseSource, Integration everywhere
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> [hidden email]
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Charles Moulliard
>>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>>> Twitter : @cmoulliard
>>>> Blog : http://cmoulliard.blogspot.com
>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> Committer & Project Lead
>>> OPS4J Pax for Vaadin
>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>>> Lead
>>> blog <http://notizblog.nierbeck.de/>
>
Reply | Threaded
Open this post in threaded view
|

Re: Telling whether startup is really complete

iocanel
I've read a lot of interesting opinions and I'd like to share mine:

i) The Karaf shell should start asap, unless explicitly configured. The
enter thing is nice but should be optional imho.
ii) Determining when Karaf is started is one thing, determining when an
application is started is another.
iii) A log entry that says Karaf has started sounds enough, we can
optionally provide that info through the info command.
iv) Different users have different needs on what started means. To cover
all cases we could allow the user to use a configuration file that will
contain requirements (package, service etc) and have everyone configure it
however he wishes.

--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Ioannis Canellos
http://iocanel.blogspot.com
123