I think that what Gustav is trying to say is that if a service is not
mandatory to the normal execution of the application server but is
only necessary when a particular user use a feature then and only
then it is a good idea to lazily initialize it. For instance, admin
layer may be necessary, admin app no.
I happen to completely agree with him.
Initialization time is only the tip of the iceberg, memory footprint
(and its impact on gc), thread consumption, and more importantly,
loaded class memory consumption (we can only load a X number of
classes before we run out of that memory space) also need to be taken
into account.
Jerome
On Dec 11, 2006, at 1:34 PM, Lloyd L Chambers wrote:
> Until time and memory are measured, terms like "bloating" ought not
> to be used; it's best to measure and state facts rather than use
> subjective FUD terms.
> Gustav, have you any hard numbers? I'm not sure how that would be
> possible, since it's not currently feasible to start the server
> without the admin service.
>
> Deferring initialization of the AdminService (this is far, far more
> than the admin port) is not currently possible for a variety of
> dependencies.
>
> The GUI won't function without it. The CLI won't function without
> it. Various internal code paths need an MBeanServer, not the least
> of which is cluster support (I'm fixing the MBeanServer part
> soon). Various other internal code relies on various MBeans loaded
> by the MBean Server.
>
> Lloyd Chambers
>
> On Dec 11, 2006, at 3:55 AM, Gustav Trede wrote:
>
>> Sahoo ,
>> Permanently wasting memory / bloating the VM just to save an
>> eventual admin logon 2 sec. of waiting ?.
>> No thanks, its very reasonable to not init the admin service
>> until its actually needed.
>>
>> It would be a nice idea to let the admin service be able to
>> "unload" itself after x idle time from last admin logout ?.
>> regards
>> gustav
>>
>> Binod wrote:
>>> Sure. I will...
>>>
>>> Before you checkin the threaded startup, please make sure that
>>> all tests in the
>>> appserv-tests/lazyInit passes when quickstartup is on and when
>>> quickstartup is off.
>>>
>>> thanks,
>>> Binod.
>>>
>>>> Binod,
>>>>
>>>> Keep me in the loop on this. I have been working on threaded
>>>> server startup. I am seeing a drop of 40% in startup time
>>>> (real time).
>>>>
>>>> Lloyd
>>>>
>>>> On Dec 8, 2006, at 2:21 AM, Binod wrote:
>>>>
>>>>> I will be checking in a change next week or so to start
>>>>> webcontainer background.
>>>>>
>>>>> - Binod.
>>>>>
>>>>>> 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
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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
>