[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-6200:
--------------------------
Labels: downstream_dependency (was: )
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-7015) connection-url is required even when not used
by Lin Gao (JIRA)
Lin Gao created WFLY-7015:
-----------------------------
Summary: connection-url is required even when not used
Key: WFLY-7015
URL: https://issues.jboss.org/browse/WFLY-7015
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.Final
Reporter: Lin Gao
Assignee: Lin Gao
Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
{noformat}
09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "GamingPortalDS")
]) - failure description: "WFLYCTL0155: connection-url may not be null"
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1715) HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1715?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1715:
------------------------------------------
{code}
It seems that the RestartMode has already a default value, created in the constructor of HostRunningModeControl. It's initialized to RestartMode.SERVERS in a single point: HostControllerEnvironment L298.
{code}
Ah, good, I missed that the field is set in the constructor method. Some test fixtures set it to HC_ONLY, but the production code sets SERVERS.
{code}
Whit the change in this issue, reverting RestartMode to its default after a HC reload, the sequence of actions of shutdown operation after a reload (with restart-servers true or false) will be the same and will be the sequences on case 2.
{code}
That's good. The case 2 sequence is better.
Thanks for the investigation.
> HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1715
> URL: https://issues.jboss.org/browse/WFCORE-1715
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Yeray Santana Borges
> Assignee: Yeray Santana Borges
> Fix For: 3.0.0.Alpha6
>
>
> The ReloadContext created by HostProcessReloadHandler sets the HostRunningModeControl's restartMode but then it never gets restored to the default value. The doReload() method of the ReloadContext should restore it. This ensures the ServerInventoryService.stop() only uses the value set by HostProcessReloadHandler once, for that one reload.
> A concern here is that ServerInventoryService only goes into its "shutdownServers" logic if the restartMode == RestartMode.SERVERS. Which, due to this bug, it will be following any HC reload. But if we restore the default value of restartMode, that is null, and null != RestartMode.SERVERS. So the ""shutdownServers" logic will no longer kick in. But should it? Should the default value of restartMode be "null"? Or should it be RestartMode.SERVERS? If we change the default from null, then the behavior when no reload has happened will change.
> Basically we need to decide whether the "shutdownServers" logic should happen by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1715) HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1715?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges commented on WFCORE-1715:
----------------------------------------------
I have arrived to these conclusions after taking a look to the code around this issue:
# It seems that the RestartMode has already a default value, created in the constructor of HostRunningModeControl. It's initialized to RestartMode.SERVERS in a single point: HostControllerEnvironment L298. Its setter is only invoked in HostProcessReloadHandler#reloadInitiated L145 so it seems that currently the default value used is RestartMode.SERVERS.
# The possible "problem" could be if the user executes a reload(restartServers=false), this operation will let the HostRunningModeControl.RestartMode equals to RestartMode.HC_ONLY because it's never reverted to its default RestartMode.SERVERS after reloading the HC. The consequence I has been able to see is a minor different order when shutdown operation is executed after HC reload:
Case 1:
/host=master:reload(restart-servers=false)
/host=master:shutdown(restart=true)
Case 2:
/host=master:reload(restart-servers=true)
/host=master:shutdown(restart=true)
Shutdown op on case 1, servers are unregistered from the HC, the HC is stopped and at the end the server are stopped.
Shutdown op on case 2, servers are unregistered from HC, servers are stopped and at the end the HC is stopped.
Whit the change in this issue, reverting RestartMode to its default after a HC reload, the sequence of actions of shutdown operation after a reload (with restart-servers true or false) will be the same and will be the sequences on case 2.
[~brian.stansberry] About the default timeout, yes, I can confirm that it will be by default is 0 (code about timeout is in WFCORE-1427)
> HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1715
> URL: https://issues.jboss.org/browse/WFCORE-1715
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Yeray Santana Borges
> Assignee: Yeray Santana Borges
> Fix For: 3.0.0.Alpha6
>
>
> The ReloadContext created by HostProcessReloadHandler sets the HostRunningModeControl's restartMode but then it never gets restored to the default value. The doReload() method of the ReloadContext should restore it. This ensures the ServerInventoryService.stop() only uses the value set by HostProcessReloadHandler once, for that one reload.
> A concern here is that ServerInventoryService only goes into its "shutdownServers" logic if the restartMode == RestartMode.SERVERS. Which, due to this bug, it will be following any HC reload. But if we restore the default value of restartMode, that is null, and null != RestartMode.SERVERS. So the ""shutdownServers" logic will no longer kick in. But should it? Should the default value of restartMode be "null"? Or should it be RestartMode.SERVERS? If we change the default from null, then the behavior when no reload has happened will change.
> Basically we need to decide whether the "shutdownServers" logic should happen by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1715) HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1715?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges reassigned WFCORE-1715:
--------------------------------------------
Assignee: Yeray Santana Borges
> HostProcessReloadHandler does not reset the HostRunningModeControl's restartMode
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1715
> URL: https://issues.jboss.org/browse/WFCORE-1715
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Yeray Santana Borges
> Assignee: Yeray Santana Borges
> Fix For: 3.0.0.Alpha6
>
>
> The ReloadContext created by HostProcessReloadHandler sets the HostRunningModeControl's restartMode but then it never gets restored to the default value. The doReload() method of the ReloadContext should restore it. This ensures the ServerInventoryService.stop() only uses the value set by HostProcessReloadHandler once, for that one reload.
> A concern here is that ServerInventoryService only goes into its "shutdownServers" logic if the restartMode == RestartMode.SERVERS. Which, due to this bug, it will be following any HC reload. But if we restore the default value of restartMode, that is null, and null != RestartMode.SERVERS. So the ""shutdownServers" logic will no longer kick in. But should it? Should the default value of restartMode be "null"? Or should it be RestartMode.SERVERS? If we change the default from null, then the behavior when no reload has happened will change.
> Basically we need to decide whether the "shutdownServers" logic should happen by default.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1737) rrd on data-source=*/statistics=pool throws NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1737?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1737:
------------------------------------------
I moved this to core, as the NPE is definitely in kernel logic and poking around in how the DS subsystem responds to requests there's nothing that seems amiss there.
> rrd on data-source=*/statistics=pool throws NPE
> -----------------------------------------------
>
> Key: WFCORE-1737
> URL: https://issues.jboss.org/browse/WFCORE-1737
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
>
> Run the following command in CLI it throws a NullPointerException
> As it is a rrd it should not require a resolved wildcard
> {code}
> /subsystem=datasources/data-source=*/statistics=pool:read-resource-description
> {code}
> Results
> {code}
> {
> "outcome" => "failed",
> "result" => [],
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> The exception throws at server.log
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:422)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeMultiTargetChildren(GlobalOperationHandlers.java:895)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:440)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:337)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This op works
> {code}
> /subsystem=datasources/data-source=*:read-resource-description
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1737) rrd on data-source=*/statistics=pool throws NPE
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1737?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7013 to WFCORE-1737:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1737 (was: WFLY-7013)
Component/s: Domain Management
(was: Domain Management)
> rrd on data-source=*/statistics=pool throws NPE
> -----------------------------------------------
>
> Key: WFCORE-1737
> URL: https://issues.jboss.org/browse/WFCORE-1737
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
>
> Run the following command in CLI it throws a NullPointerException
> As it is a rrd it should not require a resolved wildcard
> {code}
> /subsystem=datasources/data-source=*/statistics=pool:read-resource-description
> {code}
> Results
> {code}
> {
> "outcome" => "failed",
> "result" => [],
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> The exception throws at server.log
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:422)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeMultiTargetChildren(GlobalOperationHandlers.java:895)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:440)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$RegistrationAddressResolver.executeSingleTargetChild(GlobalOperationHandlers.java:903)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:442)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractAddressResolver.execute(GlobalOperationHandlers.java:337)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This op works
> {code}
> /subsystem=datasources/data-source=*:read-resource-description
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months