Bug 976228 - Operation which require server reload should check if something was changed
Summary: Operation which require server reload should check if something was changed
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.1.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER1
: EAP 6.3.0
Assignee: Emmanuel Hugonnet (ehsavoie)
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-20 07:28 UTC by Petr Kremensky
Modified: 2014-06-28 15:37 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
In earlier versions of JBoss EAP 6, some operations which did not effectively change the status of the server would put it in reload-required mode. The was because the system did not check if the operation would effectively change the configuration. In this release, if checks confirm that the configuration of the server was not changed by the operation, a reload is not required. This change does not cover every possible case.
Clone Of:
Last Closed: 2014-06-28 15:37:41 UTC
Type: Bug

Attachments (Terms of Use)
web console after second CLI operation (23.16 KB, image/png)
2013-06-20 07:28 UTC, Petr Kremensky
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-3154 0 Major Closed Operation which require server reload should check if something was changed 2018-08-27 19:49:25 UTC

Description Petr Kremensky 2013-06-20 07:28:26 UTC
Created attachment 763295 [details]
web console after second CLI operation

Description of problem:
Server reload is required even if nothing was actually changed. This could have negative impact on usability of EAP.

EAP 6.1.1 ER1

Steps to Reproduce:
 - start standalone
 - connect to cli
 - run: /subsystem=web/virtual-server=default-host:write-attribute(name=enable-welcome-root, value=false
 - reload server
 - run: /subsystem=web/virtual-server=default-host:write-attribute(name=enable-welcome-root, value=false

Actual results:
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
Expected results:
 - reload is not required

Comment 1 Alexey Loubyansky 2013-06-20 08:38:28 UTC
The CLI is only reflecting what happened in the domain management.

Comment 5 Emmanuel Hugonnet (ehsavoie) 2014-03-25 09:05:53 UTC
Upstream PR : https://github.com/kabir/wildfly/pull/28
PR : https://github.com/jbossas/jboss-eap/pull/1121

Comment 6 Emmanuel Hugonnet (ehsavoie) 2014-03-28 08:40:21 UTC
Upstream PR : https://github.com/wildfly/wildfly/pull/6091 
PR : https://github.com/jbossas/jboss-eap/pull/1121

Comment 7 Petr Kremensky 2014-04-14 11:42:43 UTC
I found a case, where the reload is still required:
[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=append)
    "outcome" => "success",
    "result" => true
[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=append, value=true)
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
[standalone@localhost:9999 /] reload
[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=append, value=true)
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"

Is this some kind of exception we can ignore?

Comment 8 Emmanuel Hugonnet (ehsavoie) 2014-04-14 13:25:26 UTC
The logging module uses its own logic with Propery to define the state instead of relying on the ReloadRequiredWriteAttributeHandler. As it is some 'generic' process for lgger configuration switches I don't know if we should change this.

Comment 9 Petr Kremensky 2014-04-15 05:26:07 UTC
Can you please look into this? Is there anything that can be done in logging module regarding this issue, or shall I close it as verified leaving logging module as it is. 

Comment 11 James Perkins 2014-04-15 15:54:55 UTC
Is the idea that if the value defined in the model is the same as the value being written that we just leave it? If that's the case then it should be fine and likely a simple fix.

In this particular case for append the default value is true. If the current value is UNDEFINED, e.g. the default, then it should still require a reload IMO.

Comment 12 Brian Stansberry 2014-04-15 16:10:58 UTC
@James -- the basic issue is to not trigger reload-required if the runtime value isn't actually going to change. See Emmanuel's ReloadRequiredWriteAttributeHandler fix which has some good code comments:


It's important to be careful about thinking about whether the value may have changed and to make a conservative decision (i.e. set reload-required if you aren't 100% certain the value is unchanged.) Emmanuel's code comment on that patch gets into that.

Comment 13 James Perkins 2014-04-15 17:10:37 UTC
Fair enough. In this case I would be inclined to leave it as it is. This is one of the few attributes in the logging subsystem that actually requires a reload. Maybe it shouldn't even require it as it doesn't really do anything unless logging is being initialized anyway. What I mean is setting append to true doesn't mean anything at runtime as the stream is already open. That is the only reason I added the reload flag.

I'd also say it's probably rare when that flag would be changed anyway. It's probably set/changed once and left. So I say we leave it as is for now.

Comment 14 Petr Kremensky 2014-04-16 05:35:01 UTC
Based on the comments above, closing this as verified.

Verified on EAP 6.3.0.ER1

Note You need to log in before you can comment on or make changes to this bug.