12:58 p.m.
[
https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-1953:
------------------------------------------
[~mchoma] Sorry for the delay; I've been traveling. Using
"allow-resource-service-restart=true" is essentially a "custom service
restart". The handler for the op sees that header and therefore is willing to
stop/start a service. It's custom because each handler separately decides whether to
have this behavior.
There's no way to restart just one service and not affect others, i.e. have custom
behavior for service start/stop itself. It's fundamental to MSC that a service is
either up or it is down, and it can't be up unless all its dependencies are up.
Therefore stopping service X means all dependencies must be stopped first. I don't
see that changing.
It's perfectly valid for a service to change its internal state without
stopping/starting. That of course isn't always easy, or correct. I haven't dug
into the details of this key-manager issue; I assume the folks looking into the issue have
considered that.
Elytron allow-resource-service-restart=true handling
----------------------------------------------------
Key: WFCORE-1953
URL: https://issues.jboss.org/browse/WFCORE-1953
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha11
Reporter: Martin Choma
Elytron can not handle {{allow-resource-service-restart=true}} header properly on many
places.
For example if I try to update http-authentication-factory with
{{allow-resource-service-restart=true}} header, I get
{code}
[standalone@localhost:9990 /]
/subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory,
value=global){allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed:
java.lang.UnsupportedOperationException",
"rolled-back" => true
}
{code}
And exception in server log
{code:title=server.log}
11:22:20,312 ERROR [org.jboss.as.controller.management-operation]
(management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute")
failed - address: ([
("subsystem" => "elytron"),
("http-authentication-factory" =>
"application-http-authentication")
]): java.lang.UnsupportedOperationException
at
org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145)
at
org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126)
at
org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72)
at
org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at
org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at
org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
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}
Similar behaviour can be seen in:
* {{kerberos-security-factory}}
* {{filesystem-realm}}
* {{constant-principal-decoder}}
On the other hand I don't see this issue in {{security-domain}}
Possible solutions:
* restart services
** possibility of reload big part of server anyway; either management part or application
part
* live updates
** if resource would accept runtime updates resource won't need to reload
** most user friendly, most work
** tracked as own issue JBEAP-6961
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)