[
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)