[JBoss JIRA] (WFCORE-1917) Deprecate "reload", "suspend" and "resume" ops on the server-config resource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1917?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1917:
-------------------------------------
Labels: domain-mode (was: )
> Deprecate "reload", "suspend" and "resume" ops on the server-config resource
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1917
> URL: https://issues.jboss.org/browse/WFCORE-1917
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> The /host=x/server-config=y resource is a configuration chunk meant to describe how the HC should set up a server, not an actual runtime resource that represents the server. The runtime resource is /host=x/server=y. But in the early days of AS7 we hadn't worked out how to have a resource for /host=x/server=y when y wasn't actually started, so as a workaround we stuck 'runtime' ops like start/stop/restart on server-config. But that was never conceptually right; it was just a workaround.
> But then we mistakenly expanded on that by sticking ops like 'reload', 'resume' and 'suspend' on the server-config resource as well. We should deprecate these so we can get rid of them in a future release (EAP 8).
> Right now they don't work very well; e.g. you can reload, suspend or resume a 'server-config' that isn't even started and the op will succeed. But that's not something this JIRA is meant to address; I'm just pointing it out as evidence of why having these ops on this resource type is conceptually a mess.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1781) DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1781?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1781:
-------------------------------------
Labels: domain-mode (was: )
> DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1781
> URL: https://issues.jboss.org/browse/WFCORE-1781
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now.
> It also shouldn't be added if the DC is running admin-only.
> OTOH in all cases where it is not added, a different service should be added that will reject any slave registration requests that come in with the correct error codes that the slave knows how to parse. Currently that rejection is only happening for admin-only masters or slaves that are using cached-dc, which is not correct.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Labels: domain-mode (was: )
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 3.0.0.Beta8
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1703) JVM resource handling of jvm-options should detect -D options and integrate with system-property logic
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1703?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1703:
-------------------------------------
Labels: domain-mode (was: )
> JVM resource handling of jvm-options should detect -D options and integrate with system-property logic
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1703
> URL: https://issues.jboss.org/browse/WFCORE-1703
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final
> Reporter: Bogdan Ilchyshyn
> Priority: Minor
> Labels: domain-mode
>
> It is not possible to set {{jboss.modules.system.pkgs}} property per server / server group in domain configuration. Even when the following configuration is added to {{host.xml}}:
> {code:xml}
> <server name="server-one" group="main-server-group">
> <jvm name="default">
> <jvm-options>
> <option value="-Djboss.modules.system.pkgs=my.package"/>
> ...
> {code}
> It is overridden by configuration in {{domain.conf}}:
> {noformat}
> JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> {noformat}
> This is an issue for configuring third-party java agents per-server. A problem described in WFLY-895 adds to this. One should either add a whole bunch of things to _all_ jvms in domain in order to make agent work, or remove config from {{domain.conf}} to avoid overrides.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1248) Make working directory for server processes configurable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1248?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1248:
-------------------------------------
Labels: domain-mode (was: )
> Make working directory for server processes configurable
> --------------------------------------------------------
>
> Key: WFCORE-1248
> URL: https://issues.jboss.org/browse/WFCORE-1248
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Environment: all
> Reporter: Rico Neubauer
> Labels: domain-mode
>
> Currently there is no configuration option to set the working directory of the server-process(es).
> Host- and domain-controller both use system-property "user.dir", but for the server-process in org.jboss.as.host.controller.ManagedServer.ProcessAddTask#execute() the following is used to initiate the new process:
>
> processControllerClient.addProcess(serverProcessName, authKey, command.toArray(new String[command.size()]), environment.getHomeDir().getAbsolutePath(), env);
> where environment.getHomeDir().getAbsolutePath() donates the working directory for the new process.
> I tested JBoss with changed working directory and this seems not to introduce any issue, so I would request this becomming a configuration option.
> A simple approach is to use system-property "user.dir" also for the server-processes. A more advanced soltion is to make this a configuration element/attribute beneath the server-configuration.
> See the forum discussion for more references.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1220:
-------------------------------------
Labels: domain-mode (was: )
> Try closing the channel if java.lang.Error prevents sending error responses to the client
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1220
> URL: https://issues.jboss.org/browse/WFCORE-1220
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue.
> Options:
> 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process.
> If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process.
> 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1005) HostControllerConnectionService does not let in flight requests clear before stopping
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1005?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1005:
-------------------------------------
Labels: domain-mode (was: )
> HostControllerConnectionService does not let in flight requests clear before stopping
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1005
> URL: https://issues.jboss.org/browse/WFCORE-1005
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR4
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> HostControllerConnectionService sets up a remoting channel that receives management requests. But unlike the services that receive end user mgmt requests, it makes no effort to ensure in flight requests have cleared before shutting down.
> I haven't looked but I wouldn't be surprised if there's a similar problem with the channel a slave HC opens for communication with the master.
> I don't think this is a critical problem; when the service stop ends up closing the channel the remote end will be notified and the in flight request should report a failure. That failure may be unnecessary though.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-1148) Non runtime-only operation can be invoked in domain servers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1148?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1148:
-------------------------------------
Labels: domain-mode (was: )
> Non runtime-only operation can be invoked in domain servers
> -----------------------------------------------------------
>
> Key: WFCORE-1148
> URL: https://issues.jboss.org/browse/WFCORE-1148
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.2.Final
> Reporter: Jeff Mesnil
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: domain-mode
>
> While working on WFLY-5418, I noticed that non runtime-only operations can be invoked on domain servers under /host=X/server=Y/...
> The operation is not listed in read-operation-names, read-resource-description, etc. but invoking it is still possible.
> Brian confirmed that this is a bug and the operation should not be executed.
> Steps to reproduce:
> * remove the runtimeOnly flag in org.jboss.as.ejb3.subsystem.deployment.MessageDrivenBeanResourceDefinition#registerOperations
> * deploy the quickstart helloworld-mdb
> * the start-delivery (and stop-delivery) operations are not listed in /host=master/server=server-one/deployment=wildfly-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldQueueMDB:read-operation-names
> * But the method can be invoked by executing:
> {noformat}
> [domain@localhost:9990 /] /host=master/server=server-one/deployment=wildfly-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldQueueMDB:start-delivery ain@localhost:9990 /]
> {
> "outcome" => "success",
> "result" => undefined
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month