Sahoo,
The module itself determines whether it can effect changes to its
configure. We cannot assume that all modules can dynamically accept
any and all configuration changes at runtime, nor can we assume that
it's reasonable to restart said module.
Lloyd
On Jul 24, 2008, at 4:52 PM, Sahoo wrote:
> I still don't get why we need a new JVM for these issues. Are these
> operations not allowed in the same VM or the same OS process? Yes, I
> agree such changes affect clients connected to the server, but
> nothing can be worse than requiring a server restart.
>
> Thanks,
> Sahoo
>
> Lloyd Chambers wrote:
>> Sahoo,
>>
>> Some modules might not be able to reconfigure....suppose a port
>> number is changed. The module might not be able to dynamically
>> switch ports for example, or change SSL certificates on an existing
>> port, or whatever.
>>
>> Lloyd
>>
>>
>>
>> On Jul 24, 2008, at 4:40 PM, Sahoo wrote:
>>
>>> I am trying to understand when and why we need server restart. By
>>> server restart, I mean starting in a new JVM. I am particularly
>>> interested in addition, updation and removal of modules. OSGi
>>> framework provides us the necessary facilities to do all these
>>> things without server restart, so it must be something to do with
>>> our implementation. I am aware one such implementation bottle-
>>> neck, which is the way we do application class loading. Let's say
>>> we address that. Actually, I know one more such bottle-neck, which
>>> is our naming manager implementation which relies on some
>>> singleton object in JRE. What are the other places? I will
>>> appreciate if each module owner takes some time and tells us why
>>> they think server needs to be restarted when their module is
>>> added, updated or removed. At least identifying those issues
>>> during development of modules will go a long way in being able to
>>> overcome them in future.
>>>
>>> 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
>