[JBoss JIRA] (WFCORE-2282) Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2282?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2282:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.Beta2)
> Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-2282
> URL: https://issues.jboss.org/browse/WFCORE-2282
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 5.0.0.Alpha1
>
>
> AbstractModelControllerOperationHandlerFactoryService creates a thread pool for handling management requests, with the goal being to limit the number of concurrently executing requests to 4, with tasks for other requests being queued.
> There are other ways to do this kind of limitation that do not involve a new thread pool. See Undertow's RequestLimitHandler and related RequestLimit class for the template.
> This task is to implement the equivalent in org.jboss.as.controller.remote (not as public API) and then switch the execution to the ServerService Thread Pool (on a server) or the HostControllerService Thread Pool (on an HC).
> It is *not* a request to move execution to the XNIO worker task thread. That should not be done without a very clear discussion.
> Part of this task is to account for the thinking that went into a fix for WFCORE-1529. IOW moving work to ServerService Thread Pool / HostControllerService Thread Pool will likely affect the optimum core sizes of those pools. This AbstractModelControllerOperationHandlerFactoryService.clientRequestExecutor is what is referred to in the PR for WFCORE-1529 in its discussion of "management-handler-thread".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3000) Allow turning the security manager on on a per jvm basis
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3000?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3000:
-------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
> Allow turning the security manager on on a per jvm basis
> --------------------------------------------------------
>
> Key: WFCORE-3000
> URL: https://issues.jboss.org/browse/WFCORE-3000
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> Turning on the security manager in a WildFly process is done by adding the -secmgr arg to org.jboss.modules.Main. But the jvm config settings in domain mode provide no mechanism for configuring args to Main; they only provide options for args to java. So there is no way to turn on the security manager for an individual jvm config (i.e. one or more servers) or if it is on for the HC there is no way to turn it off for a particular jvm config.
> The jvm config needs an attribute for this; default is undefined which should be documented as meaning the setting is derived from the HC's settings (i.e. the way it is now.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2093) A 'start' operation only is available for a domain server resource when it is started
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2093?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2093:
-------------------------------------
Fix Version/s: (was: 4.0.0.Beta2)
> A 'start' operation only is available for a domain server resource when it is started
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2093
> URL: https://issues.jboss.org/browse/WFCORE-2093
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Labels: domain-mode
>
> The server lifecycle ops are registered with the domain server resource by a call to ServerConfigResourceDefintion.registerServerLifecycleOperations. DomainModelControllerService registers that when the server registers with the HC.
> This is odd in the case of 'start' as it means that op is only registered when the server is started.
> Perhaps it should be registered with StoppedServerResource, although I haven't dug into what happens with that resource when the server is registered. If it is simply ignored that would be great.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months