11:52 a.m.
Hi all,
Just like to get the general feeling about this.
In the Management Console and via the Detyped API you can in some cases
modify configuration that requires a restart in order to become
effective. I'd like to find out what the general feeling is about this:
Option 1: make it editable via the Console and display a message that
changing this configuration requires a restart.
Option 2: make it viewable only.
So option 2 is clearly the safest option, but has a drawback that people
can't use the console to specify this configuration, they'd have to
crack open the .xml and edit that.
Option 1 gives people a fancy editor over standalone.xml / domain.xml
but does have the disadvantage that the specified values don't get
applied until the restart is done.
How do we generally handle this? Obviously, the best thing to do is
change the behaviour so that the restart isn't needed by sometimes this
isn't the highest priority within the realm of time constraints...
Cheers,
David
7:04 p.m.
New subject: Management Console: changing values that require a restart
----- Original Message -----
From: "David Bosschaert" <david(a)redhat.com>
To: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Monday, August 22, 2011 3:52:11 AM
Subject: [jboss-as7-dev] Management Console: changing values that
require a restart
Hi all,
Just like to get the general feeling about this.
In the Management Console and via the Detyped API you can in some
cases
modify configuration that requires a restart in order to become
effective. I'd like to find out what the general feeling is about
this:
Option 1: make it editable via the Console and display a message
that
changing this configuration requires a restart.
Anything that should be able to be changed should be able to be changed through the UI, so
Option 1 is the way to go. Certainly, a message that says it won't take affect until
you restart the server is good. We could also consider adding a step to the process that
allows them to do the restart at that point, schedule a restart at a latter time, or just
have the message.
Option 2: make it viewable only.
So option 2 is clearly the safest option, but has a drawback that
people
can't use the console to specify this configuration, they'd have to
crack open the .xml and edit that.
Option 1 gives people a fancy editor over standalone.xml /
domain.xml
but does have the disadvantage that the specified values don't get
applied until the restart is done.
How do we generally handle this? Obviously, the best thing to do is
change the behaviour so that the restart isn't needed by sometimes
this
isn't the highest priority within the realm of time constraints...
If we can change the behavior to not require a restart that would be preferable. If we
could come up with a list of changes that do require a restart, we could do two things
with it. We could document it in the administration guide, but we could also track it via
Andiamo, and make determinations on which things would be the most beneficial to invest in
making it that we don't have to do a restart, and change things over time (release to
release).
Andy
Cheers,
David
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:07 p.m.
New subject: Management Console: changing values that require a restart
On 8/22/11 12:04 PM, Andrig Miller wrote:
------------------------------------------------------------------------
*From: *"David Bosschaert" <david(a)redhat.com>
*To: *"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
*Sent: *Monday, August 22, 2011 3:52:11 AM
*Subject: *[jboss-as7-dev] Management Console: changing values that
require a restart
Hi all,
Just like to get the general feeling about this.
In the Management Console and via the Detyped API you can in some cases
modify configuration that requires a restart in order to become
effective. I'd like to find out what the general feeling is about this:
Option 1: make it editable via the Console and display a message that
changing this configuration requires a restart.
Anything that should be able to be changed should be able to be changed
through the UI, so Option 1 is the way to go.
Yes. The OperationContext that is passed into an OperationStepHandler
allows the handler to tell the controller that a reload or restart[1] is
required. (The base classes subclassed by many of the handler take care
of this for you.) Any operation that puts the controller in a
reload/restart required state will result in extra response headers
being included with the response indicating this, and if the controller
is already in that state a response header will also indicate that.
What's missing is standard metadata that should be part of the
description of any writable attribute or of any operation that may
trigger a restart-required. This metadata allows a console to tell the
client in advance that they are about to trigger a restart-required
situation. Now's the time to settle that metadata.
But I'm going to try and do that on this thread, as it affects the
metadata and needs a response:
http://lists.jboss.org/pipermail/jboss-as7-dev/2011-August/003414.html
[1] A "reload" is a restart of the processes root service, a "restart"
is a full process restart. A reload is much faster (say 200-300 ms) and
almost always serves the purpose, but at this point isn't available for
a domain managed server.
Certainly, a message that
says it won't take affect until you restart the server is good. We could
also consider adding a step to the process that allows them to do the
restart at that point, schedule a restart at a latter time, or just have
the message.
Option 2: make it viewable only.
So option 2 is clearly the safest option, but has a drawback that
people
can't use the console to specify this configuration, they'd have to
crack open the .xml and edit that.
Option 1 gives people a fancy editor over standalone.xml / domain.xml
but does have the disadvantage that the specified values don't get
applied until the restart is done.
How do we generally handle this? Obviously, the best thing to do is
change the behaviour so that the restart isn't needed by sometimes this
isn't the highest priority within the realm of time constraints...
If we can change the behavior to not require a restart that would be
preferable. If we could come up with a list of changes that do require a
restart, we could do two things with it. We could document it in the
administration guide, but we could also track it via Andiamo, and make
determinations on which things would be the most beneficial to invest in
making it that we don't have to do a restart, and change things over
time (release to release).
Sounds good.
Andy
Cheers,
David
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4631
days inactive
4631
days old
2 comments
3 participants
participants (3)
-
Andrig Miller -
Brian Stansberry -
David Bosschaert