[JBoss JIRA] (WFLY-9890) Timed out waiting for responses for request X from node Y immediately after node Y rejoins the cluster (failover)
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-9890?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-9890:
---------------------------------
Summary: Timed out waiting for responses for request X from node Y immediately after node Y rejoins the cluster (failover) (was: Timed out waiting for responses for request X from node Y immediately after node Y rejoins the cluster (failover with fine granularity))
> Timed out waiting for responses for request X from node Y immediately after node Y rejoins the cluster (failover)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9890
> URL: https://issues.jboss.org/browse/WFLY-9890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
>
> Seen in SF failover tests - scenario: failover-http-granular-shutdown-repl-sync
> (replication granularity is set to ATTRIBUTE level)
> Description: In the failover test, each server is shut down and after some time it rejoins the cluster. After joining the cluster again, the load is distributed to this node. It seems that first request for some session handled by that node produces ERROR in the log of some other server until the time another cluster topology change occurs.
> Stacktrace of the error:
> {code}
> [JBossINF] [0m[31m10:18:00,256 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionCreationMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAccessMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAttributeKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9[1])]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 30250 from perf18
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {code}
> Client gets the stale data:
> {code}
> 2018/02/21 10:18:00:272 EST [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Example - timeline:
> {code}
> 4 servers are running, 2000 clients, no issue in the beggining
> 2018/02/21 10:16:43:234 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 0 (perf18) is down.
> - still no issues
> 2018/02/21 10:17:43:234 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Bringing back node 0 (perf18)
> 2018/02/21 10:17:55:611 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 0 (perf18) is up.
> 2018/02/21 10:18:00:272 EST [WARN ][Runner - 16] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 60, received 59, Runner: 16>
> {code}
> perf20 started logging the errors meanwhile and stopped only after perf19 was shut down:
> {code}
> [JBossINF] [0m[0m10:17:50,227 INFO [org.infinispan.CLUSTER] (thread-19,ejb,perf20) ISPN000094: Received new cluster view for channel ejb: [perf19|5] (4) [perf19, perf20, perf21, perf18]
> [JBossINF] [0m[0m10:17:50,228 INFO [org.infinispan.CLUSTER] (thread-19,ejb,perf20) ISPN100000: Node perf18 joined the cluster
> [JBossINF] [0m[31m10:18:00,256 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionCreationMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAccessMetaDataKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9), SessionAttributeKey(f25_wwXXpvtNC9QTHZUtSwhmEUmg-wI77RL_17b9[1])]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 30250 from perf18
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> There were no issues in this scenario in EAP 7.1.0.GA.
> Links:
> Clients: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf18: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf20: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas reopened WFLY-9892:
--------------------------------
[~dmlloyd] This issue is not about "Remoting is not able to parse invalid ASCII symbol", but about regression in PicketLinkSTS. Whole point is about PicketLinkSTS produces invalid base64 content (which cannot be accepted by {{PlainSaslClient}}). Fix that string in test in WildFly 12 is just masking the regression => reopened. Moreover please realize that this scenario works correctly with WildFly 11 and stop to work with WildFly 12.
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9888) Server log messages does not reflect the use of "distinct" naming for EJB's
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9888?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9888:
-------------------------------
Assignee: Chao Wang
> Server log messages does not reflect the use of "distinct" naming for EJB's
> ---------------------------------------------------------------------------
>
> Key: WFLY-9888
> URL: https://issues.jboss.org/browse/WFLY-9888
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Chao Wang
> Priority: Minor
>
> If an application (jboss-ejb3.xml) or server configuration is marked with the distinct flag
> <jboss:ejb-jar .... version="3.1" impl-version="2.0">
> <distinct-name>WOLF</distinct-name>
> </jboss:ejb-jar>
> The client need to use the the correct lookup with distinct name
> "ejb:MyEAR/MyEjbJar/WOLF/MyBean!MyInterface
> to get the bean proxy.
> Unfortunately there is no hint whether an application is marked with this distinct flag.
> The server log still show the same output as without like this:
> INFO WFLYEJB0473: JNDI bindings for session bean named 'SimpleBean' in deployment unit 'subdeployment "ejb.jar" of deployment "EAP71-PLAYGROUND-server.ear"' are as follows:
> java:global/EAP71-PLAYGROUND-server/ejb/SimpleBean!org.jboss.wfink.eap71.playground.Simple
> It would be good if the log message show the correct JNDI name or a hint that the EJB has a distinct name applied.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9869.
----------------------------------
Fix Version/s: 12.0.0.CR1
Resolution: Done
> 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, 12.0.0.Beta1
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> Assignee: Stuart Douglas
> Labels: ejb, pure_http
> Fix For: 12.0.0.CR1
>
> 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 detail 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)
6 years, 7 months
[JBoss JIRA] (WFLY-9903) Cannot remove modcluster subsystem for the first time
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9903?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9903:
--------------------------------------
Thanks for the report.
This looks like a regression introduced with https://github.com/wildfly/wildfly/commit/ca46ebe7820c34818d175079385a83d...
Note that we have a test but that only operates on the model with no runtime, here is a patch to expand the test case to actually fail and reproduce this issue.
{noformat}
diff --git a/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java b/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java
index 6d7ce63dc3..e2a996c9ef 100644
--- a/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java
+++ b/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/mod_cluster/ModClusterSubsystemAddTestCase.java
@@ -32,6 +32,7 @@ import org.jboss.as.cli.CommandContext;
import org.jboss.as.cli.batch.Batch;
import org.jboss.as.controller.client.ModelControllerClient;
import org.jboss.as.test.integration.management.util.CLITestUtil;
+import org.jboss.as.test.shared.ServerReload;
import org.jboss.dmr.ModelNode;
import org.junit.Assert;
import org.junit.Test;
@@ -77,6 +78,8 @@ public class ModClusterSubsystemAddTestCase {
outcome = response.get("outcome").asString();
Assert.assertEquals("Adding mod_cluster subsystem failed! " + request.toJSONString(false), SUCCESS, outcome);
+ ServerReload.executeReloadAndWaitForCompletion(controllerClient);
+
// Test subsystem remove
request = ctx.buildRequest("/subsystem=modcluster:remove");
response = controllerClient.execute(request);
{noformat}
> Cannot remove modcluster subsystem for the first time
> -----------------------------------------------------
>
> Key: WFLY-9903
> URL: https://issues.jboss.org/browse/WFLY-9903
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 12.0.0.Beta1
> Environment: Debian stable, openjdk 8
> Reporter: Marcel Šebek
> Assignee: Radoslav Husar
>
> Removal of modcluster subsystem first produces an error, and succeeds for the second time:
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> ",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=modcluster:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Error in the wildfly output is
> 18:35:11,316 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 78) MODCLUSTER000002: Initiating mod_cluster shutdown
> 18:35:11,319 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("remove") failed - address: ([("subsystem" => "modcluster")]) - failure description: "WFLYCTL0441: Operation has resulted in failed or missing services
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> "
> 18:35:11,321 INFO [org.jboss.as.controller] (management-handler-thread - 2) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service org.wildfly.mod_cluster.undertow (unavailable) dependents: [service org.wildfly.undertow.http-invoker.host.default-host.http-invoker]
> For the second time, it succeeds.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem model descriptions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9744?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9744:
---------------------------------
Description:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{code}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{code}
Upon completion, we can remove the sections from documentation and link.
was:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{quote}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{quote}
Upon completion, we can remove the sections from documentation and link.
> Improve Infinispan subsystem model descriptions
> ------------------------------------------------
>
> Key: WFLY-9744
> URL: https://issues.jboss.org/browse/WFLY-9744
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
> * should describe behavior
> * should avoid using domain model terminology (e.g. attributes, child)
> * take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
> * remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
> {code}
> "deprecated" => {
> "since" => "5.0.0",
> "reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
> },
> {code}
> Upon completion, we can remove the sections from documentation and link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem model descriptions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9744?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9744:
---------------------------------
Description:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{noformat}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{noformat}
Upon completion, we can remove the sections from documentation and link.
was:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
Upon completion, we can remove the sections from documentation and link.
> Improve Infinispan subsystem model descriptions
> ------------------------------------------------
>
> Key: WFLY-9744
> URL: https://issues.jboss.org/browse/WFLY-9744
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
> * should describe behavior
> * should avoid using domain model terminology (e.g. attributes, child)
> * take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
> * remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
> {noformat}
> "deprecated" => {
> "since" => "5.0.0",
> "reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
> },
> {noformat}
> Upon completion, we can remove the sections from documentation and link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem model descriptions
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9744?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9744:
---------------------------------
Description:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{quote}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{quote}
Upon completion, we can remove the sections from documentation and link.
was:
In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
* should describe behavior
* should avoid using domain model terminology (e.g. attributes, child)
* take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
* remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
{noformat}
"deprecated" => {
"since" => "5.0.0",
"reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
},
{noformat}
Upon completion, we can remove the sections from documentation and link.
> Improve Infinispan subsystem model descriptions
> ------------------------------------------------
>
> Key: WFLY-9744
> URL: https://issues.jboss.org/browse/WFLY-9744
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
>
> In order to not duplicate documentation in docs/ and wildscribe, we will link from documentation to wildscribe. This requires descriptions to be improved. The descriptions:
> * should describe behavior
> * should avoid using domain model terminology (e.g. attributes, child)
> * take out the redundant verb such as 'configures' (unless appropriate, e.g. in operation desc.)
> * remove unnecessary "Deprecated." notices, the information is already in the model, e.g.:
> {quote}
> "deprecated" => {
> "since" => "5.0.0",
> "reason" => "Deprecated. Consider using a shared store instead, where writes are only performed by primary owners."
> },
> {quote}
> Upon completion, we can remove the sections from documentation and link.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months