[jboss-jira] [JBoss JIRA] (WFCORE-1953) Elytron allow-resource-service-restart=true handling

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-1953.
--------------------------------------
    Resolution: Won't Do


I'm rejecting this. See comments in https://issues.jboss.org/browse/JBEAP-10168.

I oppose supporting allow-resource-service-restart=true in the elytron subsystem. Restarting a service that is close to the root of the service dependency graph is going to have a practical effect little different from a reload.

I don't think we should expend energy adding support for it anywhere at all. It's a power user thing without enough practical benefit to justify the cost to implement and the fragility that results.

Also, in a cloud world, config changes are made as part of the image build and then the updated image is rolled out to the pods. Trying to make a reload go away means we are spending our energy on non-cloud use cases. (And even in bare metal uses cases people are often unwilling to live update a production server.)

Note that the UnsupportedOperationException has been fixed in a different issue.

> 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 at 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)