[JBoss JIRA] (WFLY-9531) Deadlock in model controller encountered in basic test suite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9531?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-9531 at 2/20/18 5:41 PM:
-----------------------------------------------------------------
The problem:
Two different services in the same deployment manipulate the deployment=* MRR tree in order to register custom resource types that expose service-specific mgmt information (e.g. stats that a particular resource adapter provides.)
As part of undeploy, in Service.stop() each is trying delete the items in the tree. Both are trying to delete the same general purpose nodes; they aren't focused on the service-specific nodes they added in start.
*Thread MSC 1-1*
Trying to remove the MRR for /deployment=*/subsystem=resource-adapters
Has the write lock on /deployment=*, wants the read lock on child subsystem=resource-adapters
*Thread MSC 1-2*
Trying to remove the MRR for /deployment=*/subsystem=resource-adapters/ironjacamar=ironjacamar
Has the write lock on /deployment=*/subsystem=resource-adapters
Wants the read lock on /deployment=*.
*Result*: deadlock.
The "DeploymentScanner-threads - 2" in the description doesn't seem relevant; it's just being impeded by the deadlock.
There's a basic problem in MRR that needs to be fixed. So I cloned this to WFCORE-3410. But, there are things the resource-adapters subsystem is doing wrong that contribute to this, and fixing those will work around the problem. Hence I left WFLY-9531 open and cloned this into WFCORE instead of just moving WFLY-9531.
The simplest workaround is dealing with the fact that IronJacamarActivationResourceService.stop first removes{code} /deployment=*/subsystem=resource-adapters/ironjacamar=ironjacamar{code} and then removes {code}/deployment=*/subsystem=resource-adapters{code}. The two MSC threads described above are in different points in that logic. But the first step is not necessary because the 2nd step would remove the child anyway. Just dropping the /deployment=*/subsystem=resource-adapters/ironjacamar=ironjacamar:remove will prevent the deadlock.
was (Author: brian.stansberry):
The problem:
Two different services in the same deployment manipulate the deployment=* MRR tree in order to register custom resource types that expose service-specific mgmt information (e.g. stats that a particular resource adapter provides.)
As part of undeploy, in Service.stop() each is trying delete the items in the tree. Both are trying to delete the same general purpose nodes; they aren't focused on the service-specific nodes they added in start.
*Thread MSC 1-1*
Trying to remove the MRR for /deployment=*/subsystem=resource-adapters
Has the write lock on /deployment=*, wants the read lock on child subsystem=resource-adapters
*Thread MSC 1-2*
Trying to remove the MRR for /deployment=*/subsystem=resource-adapters/ironjacamar=ironjacamar
Has the write lock on /deployment=*/subsystem=resource-adapters
Wants the read lock on /deployment=*.
*Result*: deadlock.
The "DeploymentScanner-threads - 2" in the description doesn't seem relevant; it's just being impeded by the deadlock.
There's a basic problem in MRR that needs to be fixed. So I cloned this to WFCROE-3410. But, there are things the resource-adapters subsystem is doing wrong that contribute to this, and fixing those will work around the problem. Hence I left WFLY-9531 open and cloned this into WFCORE instead of just moving WFLY-9531.
The simplest workaround is dealing with the fact that IronJacamarActivationResourceService.stop first removes{code} /deployment=*/subsystem=resource-adapters/ironjacamar=ironjacamar{code} and then removes {code}/deployment=*/subsystem=resource-adapters{code}. The two MSC threads described above are in different points in that logic. But the first step is not necessary because the 2nd step would remove the child anyway. Just dropping the /deployment=*/subsystem=resource-adapters/ironjacamar=ironjacamar:remove will prevent the deadlock.
> Deadlock in model controller encountered in basic test suite
> ------------------------------------------------------------
>
> Key: WFLY-9531
> URL: https://issues.jboss.org/browse/WFLY-9531
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA, Test Suite
> Reporter: David Lloyd
> Assignee: Brian Stansberry
> Priority: Critical
> Attachments: stack.txt
>
>
> A Java-level deadlock was encountered while running {{org.jboss.as.test.integration.jca.workmanager.LongRunningThreadsCheckTestCase}}. The thread dump is attached.
> This occurred during testing of the new thread pool (WFLY-5332 and related), but it seems unlikely to be caused by this change, unless the new pool's scheduling behavior differed enough from the default that it exposed an already-existing race condition. The deadlock was hit just once in more than 10 runs.
> This is the deadlock:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "DeploymentScanner-threads - 2":
> waiting for ownable synchronizer 0x000000075357cef0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "MSC service thread 1-1"
> "MSC service thread 1-1":
> waiting for ownable synchronizer 0x000000071dff9b08, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "MSC service thread 1-2"
> "MSC service thread 1-2":
> waiting for ownable synchronizer 0x000000075357cef0, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "MSC service thread 1-1"
> {noformat}
> Here is the specific deadlock info (also in the attachment), showing that it has something to do with the model controller:
> {noformat}
> Java stack information for the threads listed above:
> ===================================================
> "DeploymentScanner-threads - 2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000075357cef0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 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.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getOperationEntry(ConcreteResourceRegistration.java:304)
> at org.jboss.as.controller.registry.NodeSubregistry.getOperationEntry(NodeSubregistry.java:186)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getOperationEntry(ConcreteResourceRegistration.java:300)
> at org.jboss.as.controller.registry.NodeSubregistry.getOperationEntry(NodeSubregistry.java:186)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getOperationEntry(ConcreteResourceRegistration.java:300)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getOperationEntry(AbstractResourceRegistration.java:180)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getOperationEntry(AbstractResourceRegistration.java:175)
> at org.jboss.as.controller.OperationContextImpl.getAuthorizationAction(OperationContextImpl.java:1890)
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1832)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1756)
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1306)
> at org.jboss.as.controller.operations.global.ReadResourceHandler.doExecuteInternal(ReadResourceHandler.java:316)
> at org.jboss.as.controller.operations.global.ReadResourceHandler.doExecute(ReadResourceHandler.java:171)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$656/1109010279.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$657/2059677950.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$LocalClient.executeOperation(ModelControllerClientFactoryImpl.java:131)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$1$$Lambda$654/385827253.apply(Unknown Source)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl.lambda$executeInVm$0(ModelControllerClientFactoryImpl.java:296)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$$Lambda$655/955046503.run(Unknown Source)
> at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:85)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl.executeInVm(ModelControllerClientFactoryImpl.java:296)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl.access$000(ModelControllerClientFactoryImpl.java:54)
> at org.jboss.as.controller.ModelControllerClientFactoryImpl$1.executeOperation(ModelControllerClientFactoryImpl.java:77)
> at org.jboss.as.controller.LocalModelControllerClient.execute(LocalModelControllerClient.java:54)
> at org.jboss.as.controller.LocalModelControllerClient.execute(LocalModelControllerClient.java:39)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$$Lambda$652/737892850.apply(Unknown Source)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$Execution$1.execute(DefaultDeploymentOperations.java:135)
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:80)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1687)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1636)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:589)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:493)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:255)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:484)
> "MSC service thread 1-1":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000071dff9b08> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 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.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getCapabilities(ConcreteResourceRegistration.java:607)
> at org.jboss.as.controller.registry.NodeSubregistry.unregisterSubModel(NodeSubregistry.java:172)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:273)
> at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.stop(IronJacamarActivationResourceService.java:283)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1734)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1964)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1467)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1346)
> at java.lang.Thread.run(Thread.java:748)
> "MSC service thread 1-2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000075357cef0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 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.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getSubregistry(ConcreteResourceRegistration.java:571)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getChildAddresses(ConcreteResourceRegistration.java:829)
> at org.jboss.as.controller.registry.NodeSubregistry.getChildAddresses(NodeSubregistry.java:349)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getChildAddresses(ConcreteResourceRegistration.java:833)
> at org.jboss.as.controller.registry.NodeSubregistry.getChildAddresses(NodeSubregistry.java:349)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.getChildAddresses(ConcreteResourceRegistration.java:833)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getChildAddresses(AbstractResourceRegistration.java:326)
> at org.jboss.as.controller.registry.AbstractResourceRegistration.getChildAddresses(AbstractResourceRegistration.java:323)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.unregisterSubModel(ConcreteResourceRegistration.java:264)
> at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.stop(IronJacamarActivationResourceService.java:281)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1761)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1734)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1521)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1964)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1467)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1346)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by Andre Izu (JIRA)
Andre Izu created WFLY-9869:
-------------------------------
Summary: Pure HTTP EJB invocation not working
Key: WFLY-9869
URL: https://issues.jboss.org/browse/WFLY-9869
Project: WildFly
Issue Type: Quality Risk
Components: EJB
Affects Versions: 11.0.0.Final
Environment: Debian 9 - 64-bit
Reporter: Andre Izu
Attachments: ejb-http-client.zip
I have been trying to make the "pure" http EJB invocation from a remote server instance, without success.
The client module was built inside a war file, while the server artifact was build in an ear file.
When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080" or "http://localhost:8080/wildfly-services", the remote invocation works fine via main() method.
When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080", the remote invocation works fine via http://localhost:8080/web/index.jsp (client application calling server application)
Now when I set the Context.PROVIDER_URL to "http://localhost:8080/wildfly-services", the remote invocation via http://localhost:8080/web/index.jsp (client application calling server application) returns:
{panel:title=Client application calling server application}
2018-01-05 15:30:07,346 INFO [stdout] (default task-44) jndiName: ejb:wejb/wejb/CalculatorEJB!br.com.server.Calculator
2018-01-05 15:30:07,351 INFO [stdout] (default task-44) Proxy for remote EJB StatelessEJBLocator for "wejb/wejb/CalculatorEJB", view is interface br.com.server.Calculator, affinity is None
2018-01-05 15:30:07,352 ERROR [io.undertow.request] (default task-44) UT005023: Exception handling request to /web/: org.apache.jasper.JasperException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$852/801580157.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
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)
Caused by: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
at org.jboss.ejb.client.EJBReceiverInvocationContext$ResultProducer$Failed.getResult(EJBReceiverInvocationContext.java:151)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:118)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:907)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:165)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
at com.sun.proxy.$Proxy61.calculateInterest(Unknown Source)
at br.com.client.RemoteEJBClient.main(RemoteEJBClient.java:20)
at br.com.client.RemoteEJBClient.func(RemoteEJBClient.java:14)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
... 47 more
Suppressed: javax.ejb.NoSuchEJBException: EJBCLIENT000024: No EJB receiver available for handling destination "http://localhost:8080/wildfly-services"
at org.jboss.ejb.client.EJBClientContext.resolveReceiver(EJBClientContext.java:571)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:438)
at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:79)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:90)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:66)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
at org.jboss.ejb.client.EJBClientInvocationContext$$Lambda$915/72354668.accept(Unknown Source)
at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:302)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:161)
... 55 more
{panel}
This behaviour is reproduceable with the attached project. One details not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9868) Add Elytron module dependency to wsprovide wscomsume
by R Searls (JIRA)
R Searls created WFLY-9868:
------------------------------
Summary: Add Elytron module dependency to wsprovide wscomsume
Key: WFLY-9868
URL: https://issues.jboss.org/browse/WFLY-9868
Project: WildFly
Issue Type: Task
Components: Web Services
Affects Versions: 12.0.0.Final
Reporter: R Searls
Assignee: R Searls
Priority: Minor
Add module dependency to Elytron security manager
<module name="org.wildfly.security.elytron-private" services="import"/>
in modules
./modules/resources/src/main/resources/modules/wildfly1200/org/jboss/ws/tools/wsprovide/main/module.xml
./modules/resources/src/main/resources/modules/wildfly1200/org/jboss/ws/tools/wsconsume/main/module.xml
This is related to changes make in jboss-modules in wfly12.
This is relation to https://issues.jboss.org/browse/WFLY-9801
but is not a direct fix for it.
David Lloyd recommends we add this dependency to the modules.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9850) wsprovide fails on HPUX machines
by R Searls (JIRA)
[ https://issues.jboss.org/browse/WFLY-9850?page=com.atlassian.jira.plugin.... ]
R Searls commented on WFLY-9850:
--------------------------------
Switched to used SED to edit JAVA_OPTS.
> wsprovide fails on HPUX machines
> --------------------------------
>
> Key: WFLY-9850
> URL: https://issues.jboss.org/browse/WFLY-9850
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Affects Versions: 12.0.0.Beta1
> Reporter: Marek Kopecký
> Assignee: R Searls
> Priority: Blocker
>
> wsprovide.sh script fails on HPUX machines
> This issue is caused by WFLY-9538
> *Actual results:*
> {noformat}
> hudson@eap-perf-hpux-02.mw.lab.eng.bos.redhat.com:/mnt/hudson_workspace/workspace/mkopecky/wildfly/bin>./wsprovide.sh
> ./wsprovide.sh[86]: JAVA_OPTS=${JAVA_OPTS/-secmgr/}: bad substitution
> hudson@eap-perf-hpux-02.mw.lab.eng.bos.redhat.com:/mnt/hudson_workspace/workspace/mkopecky/wildfly/bin>
> {noformat}
> *Expected results:*
> {noformat}
> [mkopecky@dhcp-10-40-5-4 bin]$ ./wsprovide.sh
> Error: endpoint implementation was not specified!
> WSProvideTask generates portable JAX-WS artifacts for an endpoint implementation.
> usage: wsprovide.sh [options] <endpoint class name>
> options:
> -h, --help Show this help message
> -k, --keep Keep/Generate Java source
> -w, --wsdl Enable WSDL file generation
> -a, --address=<address> The generated port soap:address in wsdl
> -c, --classpath=<path> The classpath that contains the endpoint
> -o, --output=<directory> The directory to put generated artifacts
> -r, --resource=<directory> The directory to put resource artifacts
> -s, --source=<directory> The directory to put Java source
> -e, --extension Enable SOAP 1.2 binding extension
> -q, --quiet Be somewhat more quiet
> -t, --show-traces Show full exception stack traces
> -v, --verbose Show full exception stack traces
> -l, --load-provider Load the provider and exit (debug utility)
> [mkopecky@dhcp-10-40-5-4 bin]$
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3579) ERROR log occurs during CLI reload operation on server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3579?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3579:
------------------------------------------
[~mkopecky] Does the change at https://github.com/wildfly/wildfly-core/pull/3124 fix the problem for you? Even without that change when I run your script locally it doesn't fail, so I can't tell if this fixes the problem.
> ERROR log occurs during CLI reload operation on server
> ------------------------------------------------------
>
> Key: WFCORE-3579
> URL: https://issues.jboss.org/browse/WFCORE-3579
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 4.0.0.Alpha9
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 4.0.0.Beta2
>
> Attachments: cli.script.txt
>
>
> *Description of the issue:*
> ERROR log occurs during CLI reload operation on server:
> {{ERROR \[org.jboss.as.controller.management-operation\] (pool-3-thread-2) WFLYCTL0013: Operation ("read-attribute") failed - address: (\[("host" => "master")\]) - failure description: "WFLYCTL0201: Unknown attribute 'host-state'"}}
> This issue is regression against WF11
> Reload handler and its "host-state" code is [here|https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/jav...], but this issue is probably caused by some "debug -> error" logging change ...
> I'm able to reproduce this only on embedded server. Non-embedded server is probably too slow to hit this issue
> *How reproducible:*
> I see this intermittently on fast virtual machines
> *Steps to Reproduce:*
> # ./jboss-cli.sh --file=cli.script.txt
> *Content of cli.script.txt file*
> This file is attached to this jira, beginning of this file:
> {noformat}
> embed-host-controller --std-out=echo
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> {noformat}
> *Actual results:*
> Standard output:
> {noformat}
> ...
> [0m[0m01:36:06,021 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Alpha9) starting
> [0m[31m01:36:06,061 ERROR [org.jboss.as.controller.management-operation] (CLI command executor) WFLYCTL0013: Operation ("read-attribute") failed - address: ([("host" => "master")]) - failure description: "WFLYCTL0201: Unknown attribute 'host-state'"
> [0m[0m01:36:06,072 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=native-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,073 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,097 INFO [org.jboss.as.patching] (MSC service thread 1-3) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
> [0m[33m01:36:06,102 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /home/hudson/hudson_workspace/workspace/early-testing-cli-embedded-manual/4b767fc2/wildfly/domain/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> [0m[0m01:36:06,185 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=default/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,196 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=ha/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,204 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=full/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,217 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=full-ha/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,287 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Alpha9) (Host Controller) started in 266ms - Started 54 of 59 services (18 services are lazy, passive or on-demand)
> ...
> {noformat}
> *Expected results:*
> No errors in logs
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3625) Elytron subsystem template does not match what we persist
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3625?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3625:
----------------------------------------
Assignee: Jan Kalina
Resolution: Done
> Elytron subsystem template does not match what we persist
> ---------------------------------------------------------
>
> Key: WFCORE-3625
> URL: https://issues.jboss.org/browse/WFCORE-3625
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Brian Stansberry
> Assignee: Jan Kalina
> Fix For: 4.0.0.Beta2
>
>
> When we persist domain.xml in full, the elytron subsystem ends up being reordered vs what we shipped in the standard config. I assume this occurs with all the config files.
> The element and attribute order in the standard config, the persistence and the xsd should be the same.
> Specifically:
> audit-logging moves from after providers to before
> http moves from before sasl to after
> The xsd agrees with what's in the standard config so this looks to be a marshalling problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months