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 17:19:49 GMT
what do you mean?

Kind regards,
Andreas

On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom <seijoed@gmail.com> 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 <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.
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 <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
>>>>>>>>>>>> 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é
>>>>>>>>>>>> <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
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é
>>>>> 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/>
>

Mime
View raw message