Bug 1024239 - Strange behaviour of connection-properties=hoge:remove, :disable and :remove of a datasource
Strange behaviour of connection-properties=hoge:remove, :disable and :remove ...
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JCA (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: DR9
: EAP 6.4.0
Assigned To: Stefano Maestri
Martin Simka
Depends On:
  Show dependency treegraph
Reported: 2013-10-29 04:03 EDT by Osamu Nagano
Modified: 2017-10-09 20:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-3841 Critical Resolved double :remove of connection-property from a DS leave it in wrong state 2017-08-11 00:46 EDT

  None (edit)
Description Osamu Nagano 2013-10-29 04:03:29 EDT
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.

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.
Comment 1 Osamu Nagano 2013-10-31 20:35:20 EDT
There is a similar complaint from JON side.

[Datasource configuration changes SHOULD NOT require a complete reload/restart of EAP]
Comment 2 Brian Stansberry 2013-11-04 10:35:32 EST
Please use the subsystem component for problems with the management behavior of a subsystem. Use the CLI component for client-side issues. Thanks!
Comment 3 Stefano Maestri 2013-11-07 08:23:40 EST
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:

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
Comment 4 Osamu Nagano 2013-11-07 20:56:16 EST
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?
Comment 5 jolee 2013-11-12 10:18:13 EST
I would like to confirm that this will also address the invalid state after an :disable + restart.


# 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
Comment 6 Stefano Maestri 2013-11-14 08:21:07 EST
Regarding comment #5: Yes, it should address this too
Comment 7 Stephen Fikes 2014-06-06 11:45:04 EDT
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?
Comment 8 Martin Simka 2014-08-01 09:11:33 EDT
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

disable => restart-required



=> not a bug
Comment 9 Osamu Nagano 2014-08-03 20:30:48 EDT
I think the same with Martin, 1. is a bug, 2. is not.
Comment 10 Stefano Maestri 2014-09-10 10:22:38 EDT
Yup 1 is a bug, 2 is not. 1 Affect also current WildFly, opened a jira
Comment 11 Stefano Maestri 2014-11-05 05:27:08 EST
Comment 12 Martin Simka 2014-11-13 12:27:19 EST
verified on EAP 6.4.0.DR9

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