karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: Telling whether startup is really complete
Date Thu, 09 Aug 2012 16:43:40 GMT
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

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

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

"- 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,

On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <bcanhome@googlemail.com> 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 <ch007m@gmail.com>:
>> Well said JB. This is exactly what I have explained this morning.
>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb@nanthrax.net>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.
>>>>> 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
>>>>> 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
>>>>> 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 <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
>>>>>>>> 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
>>>>>>>> start-point (even if it requires some manual adaption). I'm
>>>>>>>> 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;
>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> bundles/available bundles till (b) set a constant
which will occur
>>>>>>>>>> the
>>>>>>>>>> moment a bundle is added with a start lvl higher
>>>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's
>>>>>>>>>> fine, but
>>>>>>>>>> this will still not fix the problem with the feature
service adding
>>>>>>>>>> bundles (with even higher start lvls) AFTER the framework
>>>>>>>>>> In
>>>>>>>>>> addition we've the "old" problem of various parts
>>>>>>>>>> webapps,
>>>>>>>>>> deployer, ...) starting up async. While most of those
>>>>>>>>>> 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
>>>>>>>>>> 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 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
>>>>>>>>>>>> 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
>>>>>>>>>>>> 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é
>>> jbonofre@apache.org
>>> 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/>

View raw message