outside of a philosophical debate on whether a server restart is
acceptable or now, I think that what really matters to people is the
loss of service, which would occur whether you restart the VM or you
end up shutdown all existing modules and restart them. In fact,
shutting down modules in an orderly fashion and restarting them might
take more time than a good old server restart.
The viral effect of stopping random modules to be able to reload a
newer version works well for extension points, or applications where
modules lifecyles are well defined. However, stopping random modules
which are part of the internal network of modules interacting can be
at best very tricky. Also the service based architecture, the dynamic
binding, makes it harder to know who is really using a module at
runtime and some class casting exception could potentially arise when
switching modules.
Overall I think it may look very doable using some services from the
underlying module management, in practice, if the lifecycle of these
modules is not understood/maintain by the application server, this
will be tricky.
Jerome
On Jul 24, 2008, at 4:55 PM, Sahoo wrote:
> That's understandable. Thanks for pointing them out. As I said, I am
> more interested in module addition, updation and removal. May be I
> did not make myself very clear. By updation, I mean the updation of
> the module's jar file (for patching or upgrading).
>
> Thanks,
> Sahoo
>
> Byron Nevins wrote:
>> Changing a JVM option can require a restart. E.g. you change the
>> memory heap size. Or switch to server-VM from client-VM.
>>
>>
>>
>> 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
>