Jerome,
I'm not sure there is a disagreement, once we all use the same
terminology. :)
I do think there should be an explicit discussion of the goals--which
might vary for production vs developer scenarios.
Lloyd
On Dec 12, 2006, at 11:04 AM, Jerome Dochez wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>