[
https://issues.jboss.org/browse/WFLY-5205?page=com.atlassian.jira.plugin....
] 
Stuart Douglas commented on WFLY-5205:
--------------------------------------
This is basically expected, unless you suspend the server before you perform the undeploy.
Basically if you undeploy while requests are active the requests are going to fail in
random ways as they will expect services to be up that are not there anymore. 
 Intermittent ServletException when handling request - Deployment has
stopped
 ----------------------------------------------------------------------------
                 Key: WFLY-5205
                 URL: 
https://issues.jboss.org/browse/WFLY-5205
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.0.0.Beta1
            Reporter: Michal Vinkler
            Assignee: Stuart Douglas
            Priority: Minor
 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:
 {code}
 [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)
 {code}
 Other nodes in the cluster did not get the error.
 Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)