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. Version-Release 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
The CLI is only reflecting what happened in the domain management.
Upstream PR : https://github.com/kabir/wildfly/pull/28 PR : https://github.com/jbossas/jboss-eap/pull/1121
Upstream PR : https://github.com/wildfly/wildfly/pull/6091 PR : https://github.com/jbossas/jboss-eap/pull/1121
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?
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.
@James 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. Thanks.
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.
@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: https://github.com/jbossas/jboss-eap/pull/1121/files 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.
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.
Based on the comments above, closing this as verified. Verified on EAP 6.3.0.ER1