karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Edstrom <seij...@gmail.com>
Subject Re: Telling whether startup is really complete
Date Thu, 09 Aug 2012 11:40:09 GMT
+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. <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 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é <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 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
>>>>>> moment a bundle is added with a start lvl higher than
>>>>>> "org.osgi.framework.startlevel.beginning". That's basically fine,
>>>>>> this will still not fix the problem with the feature service adding
>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>> addition we've the "old" problem of various parts (blueprint, webapps,
>>>>>> deployer, ...) starting up async. While most of those components
>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but
>>>>>> the other hand you wont know when all bundles are active. In addition
>>>>>> it will show the framework ready although bundles with a startup
>>>>>> 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é <jb@nanthrax.net>
>>>>>> 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
>>>>>>> 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
>>>> 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
>>>> 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,
>>>>>>>> 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/>

View raw message