Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (athena.apache.org: domain of bcanhome@googlemail.com
 designates 209.85.160.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ9DK3wG=rB056RumrY2wVaiBOJkKg8jAnk947U=AR7myRJhJw@mail.gmail.com>
References: <5022B36D.1010000@gmail.com>
	<5022C447.9090805@nanthrax.net>
	<CAK--DP-iw_VrYOUnDco510pY=NU4OwjdsxrUzgve=y7_mb+BUQ@mail.gmail.com>
	<50232B74.3010005@nanthrax.net>
	<CAK--DP_v-ov-N_4oHx_OyX3eNOQKDbN2oOEB_N4AG2ZFXuWGCA@mail.gmail.com>
	<CAEQV+EFuYD-ALGEy2Ko=B--CuhNZT5c=P5FHfCdyEXF7k8-FPw@mail.gmail.com>
	<CAJ9DK3wG=rB056RumrY2wVaiBOJkKg8jAnk947U=AR7myRJhJw@mail.gmail.com>
Date: Thu, 9 Aug 2012 13:26:58 +0200
Message-ID: 
 <CAD0r13dT4zEtFqJbVqcUK3oqTxo8C5=p+A5EcM9Om9HaM0sSYg@mail.gmail.com>
Subject: Re: Telling whether startup is really complete
From: Achim Nierbeck <bcanhome@googlemail.com>
To: dev@karaf.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 =3D 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. <jamie.goodyear@gmail.com>:
> 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 <gnodet@gmail.com> 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 coul=
d
>> 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=E9 <jb@nanthrax.net=
<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 mast=
er
>>> >> I'm not convinced that it will solve Christoph's problem. As Christo=
ph
>>> >> pointed out:
>>> >>
>>> >> "There is a short delay between the point where all karaf-base-bundl=
es
>>> >> 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 t=
he
>>> >> moment a bundle is added with a start lvl higher than
>>> >> "org.osgi.framework.startlevel.beginning". That's basically fine, bu=
t
>>> >> this will still not fix the problem with the feature service adding
>>> >> bundles (with even higher start lvls) AFTER the framework startup. I=
n
>>> >> addition we've the "old" problem of various parts (blueprint, webapp=
s,
>>> >> deployer, ...) starting up async. While most of those components kno=
w
>>> >> when they're finished (a) cannot know. This has the advantage that i=
t
>>> >> 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 additio=
n
>>> >> 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=E9 <jb@nanthrax.=
net>
>>> >> wrote:
>>> >>>
>>> >>> Hi Christoph,
>>> >>>
>>> >>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you hav=
e 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 thi=
s
>>> 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


--=20

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/>