[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
8:21 a.m.
[
https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin....
]
Gary Yang commented on WFLY-3560:
---------------------------------
Unfortunately the problem has not been fixed in 9.0.0.Alpha1:
09:17:49,002 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51)
WFLYUT0014: Creating file handler for path
/Users/gyang/Downloads/wildfly-9.0.0.Alpha1/welcome-content
09:17:49,039 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012:
Started server default-server.
09:17:49,059 INFO [org.wildfly.extension.undertow] (MSC service thread 1-11) WFLYUT0018:
Host default-host starting
09:17:49,128 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006:
Undertow HTTP listener default listening on /127.0.0.1:8082
09:17:49,274 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-10)
WFLYDS0013: Started FileSystemDeploymentService for directory
/Users/gyang/Downloads/wildfly-9.0.0.Alpha1/standalone/deployments
09:17:49,280 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread
1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
09:17:49,445 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052:
Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta1
09:17:49,536 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management
interface listening on http://127.0.0.1:9990/management
09:17:49,537 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console
listening on http://127.0.0.1:9990
09:17:49,537 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full
9.0.0.Alpha1 (WildFly Core 1.0.0.Alpha8) started in 2471ms - Started 193 of 295 services
(135 services are lazy, passive or on-demand)
09:17:55,980 ERROR [stderr] (default task-1) Exception in thread "default
task-1" java.lang.IllegalStateException: UT000004: getResponseChannel() has already
been called
09:17:55,981 ERROR [stderr] (default task-1) at
io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:96)
09:17:55,981 ERROR [stderr] (default task-1) at
io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.transferTo(HttpContinueReadHandler.java:84)
09:17:55,981 ERROR [stderr] (default task-1) at
org.xnio.conduits.ConduitStreamSourceChannel.transferTo(ConduitStreamSourceChannel.java:83)
09:17:55,981 ERROR [stderr] (default task-1) at
io.undertow.channels.DetachableStreamSourceChannel.transferTo(DetachableStreamSourceChannel.java:68)
09:17:55,982 ERROR [stderr] (default task-1) at
io.undertow.server.HttpServerExchange$ReadDispatchChannel.transferTo(HttpServerExchange.java:1850)
09:17:55,982 ERROR [stderr] (default task-1) at
org.xnio.channels.Channels.drain(Channels.java:807)
09:17:55,982 ERROR [stderr] (default task-1) at
io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1441)
09:17:55,982 ERROR [stderr] (default task-1) at
io.undertow.io.DefaultIoCallback$1.onComplete(DefaultIoCallback.java:44)
09:17:55,983 ERROR [stderr] (default task-1) at
io.undertow.io.AsyncSenderImpl.close(AsyncSenderImpl.java:347)
09:17:55,983 ERROR [stderr] (default task-1) at
io.undertow.io.DefaultIoCallback.onComplete(DefaultIoCallback.java:41)
09:17:55,983 ERROR [stderr] (default task-1) at
io.undertow.server.handlers.resource.FileResource$1ServerTask.run(FileResource.java:155)
09:17:55,983 ERROR [stderr] (default task-1) at
io.undertow.server.handlers.resource.FileResource$1ServerTask.onComplete(FileResource.java:172)
09:17:55,984 ERROR [stderr] (default task-1) at
io.undertow.io.AsyncSenderImpl.invokeOnComplete(AsyncSenderImpl.java:380)
09:17:55,984 ERROR [stderr] (default task-1) at
io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:175)
09:17:55,984 ERROR [stderr] (default task-1) at
io.undertow.server.handlers.resource.FileResource$1ServerTask.run(FileResource.java:159)
09:17:55,984 ERROR [stderr] (default task-1) at
io.undertow.server.handlers.resource.FileResource.serve(FileResource.java:224)
09:17:55,985 ERROR [stderr] (default task-1) at
io.undertow.server.handlers.resource.ResourceHandler$1.run(ResourceHandler.java:256)
09:17:55,985 ERROR [stderr] (default task-1) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
09:17:55,985 ERROR [stderr] (default task-1) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
09:17:55,985 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745)
Combination of HTTP Request Header "Connection:keep-alive"
and "Expect:100-conitnue" causes Wildfly undeploy apps
-----------------------------------------------------------------------------------------------------------------
Key: WFLY-3560
URL: https://issues.jboss.org/browse/WFLY-3560
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.0.0.Final, 8.1.0.Final
Reporter: Gary Yang
Assignee: Jason Greene
Issue is described in https://community.jboss.org/thread/242415
If client uses "Connection:keep-alive" and "Expect:100-continue" in
HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws
following exception:
{noformat}
2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request
failed HttpServerExchange{ POST /enterprise/composite/postAndSend}:
java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at
io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
at
io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
at
org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
[xnio-api-3.2.0.Final.jar:3.2.0.Final]
at
io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
at
io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
at org.xnio.channels.Channels.readBlocking(Channels.java:294)
[xnio-api-3.2.0.Final.jar:3.2.0.Final]
at
io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
at
io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
at
io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
at
io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
at
io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_55]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
{noformat}
If there are multiple users sending this kind of requests, Wildfly eventually undeploy
all applications.
Here is a test code using Apache HTTP client
{code:java}
HttpPost request = new HttpPost(serverURL);
for (int i=0; i<200; i++) {
StringEntity input = new StringEntity (payLoad);
input.setContentType("application/json");
request.setHeader("Connection", "keep-alive");
request.setHeader("Expect", "100-continue");
request.setEntity(input);
HttpResponse response = httpclient.execute(request);
HttpEntity entity = response.getEntity();
if (entity != null) {
System.out.println("Response content length: " +
entity.getContentLength());
}
EntityUtils.consume(entity);
if (entity != null) {
System.out.println("Response content length: " +
entity.getContentLength());
}
EntityUtils.consume(entity);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
3705
days inactive
3705
days old
0 comments
1 participants
participants (1)
-
Gary Yang (JIRA)