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
>