[JBoss JIRA] (WFLY-10007) Module org.infinispan.cachestore.remote was dropped
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10007?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10007:
-----------------------------------------
[~luck3y] [~pferraro] FYI. We can perhaps come up with something better or maybe this doesn't even work (Ken's testing on OpenShift shows it does at least somewhat), but I wanted to get at least an interim solution up.
Same problem may apply to the cachestore.jbdc module for some other LP, but we haven't hit such a case.
> Module org.infinispan.cachestore.remote was dropped
> ---------------------------------------------------
>
> Key: WFLY-10007
> URL: https://issues.jboss.org/browse/WFLY-10007
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 13.0.0.Beta1
>
>
> The org.infinispan.cachestore.remote module was renamed to org.infinispan.persistence.remote as part of WFLY-8207 but the Keycloak adapters that integrate into WF depend on that module. So, proposal is to add an alias module.
> The module was private but projects/products that layer on top of WF/EAP legitimately use private modules. Also, this isn't really a layer, it's an adapter to allow us to integrate with an external server, so we somewhat broke ourselves.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10007) Module org.infinispan.cachestore.remote was dropped
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-10007:
---------------------------------------
Summary: Module org.infinispan.cachestore.remote was dropped
Key: WFLY-10007
URL: https://issues.jboss.org/browse/WFLY-10007
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 12.0.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 13.0.0.Beta1
The org.infinispan.cachestore.remote module was renamed to org.infinispan.persistence.remote as part of WFLY-8207 but the Keycloak adapters that integrate into WF depend on that module. So, proposal is to add an alias module.
The module was private but projects/products that layer on top of WF/EAP legitimately use private modules. Also, this isn't really a layer, it's an adapter to allow us to integrate with an external server, so we somewhat broke ourselves.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-1953) Elytron allow-resource-service-restart=true handling
by Brian Stansberry (JIRA)
[ 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)
8 years, 3 months
[JBoss JIRA] (WFLY-9982) Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9982?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9982:
----------------------------------------
This is the same thread dump pattern as WFCORE-3590, which is marked as resolved for WF Core 4.0.0.Beta2, i.e. it should be fixed in WF 12.0.0.Final. [~ropalka] FYI. [~mnovak], please confirm this was seen with 12.0.0.Final and not some previous build from late in the 12 dev cycle. Thanks!
> Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown
> ------------------------------------------------------------------------------
>
> Key: WFLY-9982
> URL: https://issues.jboss.org/browse/WFLY-9982
> Project: WildFly
> Issue Type: Bug
> Components: MSC, Server
> Affects Versions: 12.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jason Greene
> Attachments: node-1-thread-dump-when-killed-shutdown-sequence.txt
>
>
> There is intermittent failure where server does not stop and hangs during clean shutdown.
> Investigation:
> In attached thread dump there is shutdown of WF/EAP JVM thread waiting for finishing org.jboss.as.server.BootstrapImpl$ShutdownHook:
> {code}
> "Management Triggered Shutdown" #262 prio=5 os_prio=0 tid=0x00007f931c03b800 nid=0x3900 in Object.wait() [0x00007f9296423000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> at java.lang.Thread.join(Thread.java:1252)
> - locked <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> at java.lang.Thread.join(Thread.java:1326)
> at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
> at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
> at java.lang.Shutdown.runHooks(Shutdown.java:123)
> at java.lang.Shutdown.sequence(Shutdown.java:167)
> at java.lang.Shutdown.exit(Shutdown.java:212)
> - locked <0x00000000cedfac08> (a java.lang.Class for java.lang.Shutdown)
> at java.lang.Runtime.exit(Runtime.java:109)
> at java.lang.System.exit(System.java:971)
> at org.jboss.as.server.SystemExiter$DefaultExiter.exit(SystemExiter.java:117)
> at org.jboss.as.server.SystemExiter.logAndExit(SystemExiter.java:98)
> at org.jboss.as.server.operations.ServerShutdownHandler$ShutdownAction$1.run(ServerShutdownHandler.java:184)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> which hangs in:
> {code}
> "Thread-3" #12 prio=5 os_prio=0 tid=0x00007f92d01dc800 nid=0x3902 waiting on condition [0x00007f9296221000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fc2531d8> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.shutdown(BootstrapImpl.java:276)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.run(BootstrapImpl.java:240)
> {code}
> where ShutdownHook.shutdown(BootstrapImpl.java:276) is waiting for latch to count down however this does not happen. It seems like that not all services shut down.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months