Description of problem: Firstly there are different behaviours between CLI and Console when adding a connection-properties to a data-source. In CLI, the server becomes "reload-required" after the addition. But in Console, the server is not forced to reload after the addition. It seems CLI is right because it's more basic tool than Console. But on the second thought, the entire server status shouldn't be affected by such a subsystem change. Actually data-source operations in CLI have strange behaviours as follows. It seems a thorough review is required. Steps to Reproduce: At first, prepare an EAP 6.1.1 standalone instance and add a dummy connection property like this in CLI. -- /subsystem=datasources/data-source=ExampleDS/connection-properties=hoge:add(value=foo) :reload -- 1. Try to remove the dummy property. It fails at the first but succeeds at the second try. -- [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=hoge:remove { "outcome" => "failed", "failure-description" => "JBAS014762: Removing services has lead to unsatisfied dependencies: Service jboss.data-source-config.ExampleDS.connection-properties.hoge was depended upon by service jboss.data-source-config.ExampleDS", "rolled-back" => true } [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=hoge:remove {"outcome" => "success"} -- 2. Disabling a data-source results in the server to be "reload-required". But removing it doesn't require the reload. This is strange because the latter implicates the former semantically. -- [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:disable { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9999 /] :reload {"outcome" => "success"} [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:enable {"outcome" => "success"} [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:remove {"outcome" => "success"} [standalone@localhost:9999 /] :read-attribute(name=server-state) { "outcome" => "success", "result" => "running" } -- Additional info: The same behaviour in all EAP 6.x.x versions.
There is a similar complaint from JON side. [Datasource configuration changes SHOULD NOT require a complete reload/restart of EAP] https://bugzilla.redhat.com/show_bug.cgi?id=1004977
Please use the subsystem component for problems with the management behavior of a subsystem. Use the CLI component for client-side issues. Thanks!
General consideration: in CLI you have to explicit enable service restart to don't need a restart for certain operations (like :enable and :disable on DS), and its exactly what webconsole is doing under the hood: /subsystem=datasources/data-source=ExampleDS:disable{allow-resource-service-restart=true} regarding point 1: You have to disable the DS before add/remove subresources, exaclty because it will restart resource service using those properties (most likely vendor specific configurations for DB connection) Point 2: already said in my general considetarion you need {allow-resource-service-restart=true}. :remove doesn't need it because is not changing state of related services, but just remove them all. IOW :remove doesn't imply a :disable, it's just a remove of the resource and related services
Thank you for the clarification. I'm not aware of {allow-resource-service-restart=true}, it works as expected. -- [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:disable{allow-resource-service-restart=true} {"outcome" => "success"} [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:enable {"outcome" => "success"} -- Though how about the inconsistant result of successive :remove of a connection property?
I would like to confirm that this will also address the invalid state after an :disable + restart. /profile=full/subsystem=datasources/data-source=Test1:disable /server-group=main-server-group:restart-servers() # check status /profile=full/subsystem=datasources/data-source=Test1:read-resource(recursive=true) -> correctly shown as disabled /host=master/server=server-one/subsystem=datasources/data-source=Test1:read-resource(recursive=true) -> Incorrectly shown as enabled
Regarding comment #5: Yes, it should address this too
Can someone clarify if it is a bug that after disable without using {allow-resource-service-restart=true} it is not possible to re-enable a resource? Or is it the case that this just needs to be explicitly specified? Were we planning to alter the behavior when using CLI to automatically include this even if not specified explicitly when disabling a data source? It was not clear to me what fix or fixes were planned for this issue. Also, my customer is asking about when this will be fixed. There does not appear to be any target release at present?
Same question as Stephen. Can someone clarify if it is a bug? My opinion 1. first try to remove property fails, second try succeeds => bug 2. disable => restart-required reload enable or disable{allow-resource-service-restart=true} enable => not a bug
I think the same with Martin, 1. is a bug, 2. is not.
Yup 1 is a bug, 2 is not. 1 Affect also current WildFly, opened a jira
https://github.com/jbossas/jboss-eap/pull/1881
verified on EAP 6.4.0.DR9