-
Bug
-
Resolution: Won't Do
-
Minor
-
7.0.0.DR8
-
None
Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
This error was seen during clustering failover testing in the following scenario:
ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache)
After undeploying application on perf19 (second node in the cluster), this error message was logged 17 times in the server log:
[JBossINF] [0m[31m20:01:42,682 ERROR [io.undertow.request] (default task-107) UT005023: Exception handling request to /clusterbench/ejbservlet: javax.servlet.ServletException: UT010051: Deployment clusterbench-ee7.ear.clusterbench-ee7-web-default.war has stopped [JBossINF] at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:165) [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778) [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [JBossINF] at java.lang.Thread.run(Thread.java:745)
Other nodes in the cluster did not get the error.
We also see the very same error in the scenario where the nodes shutdown instead of undeploying application - right after the server shutdown has been requested (we do not use graceful shutdown yet).
May be relevant to https://issues.jboss.org/browse/JBEAP-864 as both errors come together, under the same conditions.
- is cloned by
-
-
- Closed
-