I've been working in the startup code for over a month, and the Admin
Service is started in PE and EE, rain or shine. So there is
definitely a misunderstanding, but I don't see how it could be mine.
I definitely do NOT agree that deferring startup of most services is
a good idea.
Doing so optimizes to sluggish response; start the server does a fake
"I'm ready", then any attempt to use it immediately stops while the
server starts something.
This already happens with the GUI, and is really annoying. That's
not an improvement, especially since 75% of the CPU time goes
*unused* on my quad-core machine, and 50% on my dual-core (during
startup). Even on single core machines there is I/O that idles the
CPU for a time.
Lloyd Chambers
On Dec 8, 2006, at 6:18 PM, Sanjeeb Kumar Sahoo wrote:
> I do think admin service is currently started on demand. Binod's
> earlier response kind of confirmed it.
> About reduction in start up time: even if you see a 40% reduction
> in start up time, I am assuming we shall continue to start some
> subsystems on demand only so that resource usage is optimized.
>
> Thanks,
> Sahoo
>
> Lloyd L Chambers wrote:
>> That is not correct. The AdminService is started in
>> ApplicationServer as the very first ServerLifecycle module. It
>> most defininitely is not started on demand.
>>
>> Much of what the AdminService does is required by other parts of
>> the server. Disabling it would cause many other pieces to fail.
>>
>> I am working on threaded server startup, which includes the admin
>> service. I am seeing a 40% reduction in startup time (real time)
>> for a full startup (not quickstart).
>>
>> Lloyd Chambers.
>>
>> On Dec 8, 2006, at 1:54 AM, Sanjeeb Kumar Sahoo wrote:
>>
>>> We seem to be initializing the admin service only on demand.
>>> Would it be better to initialize it in the back ground as soon as
>>> the server starts? How often will there be a server running where
>>> there will be no administration activity? By not initializing
>>> admin service, who are we optimizing it for?
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>