[JBoss JIRA] (WFLY-1017) Filesystem deployment scanner for a managed domain
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1017?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1017:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1078889
> Filesystem deployment scanner for a managed domain
> --------------------------------------------------
>
> Key: WFLY-1017
> URL: https://issues.jboss.org/browse/WFLY-1017
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final
> Reporter: hitesh yadav
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node.
> For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group .....
> Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group .............
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3561) mod_proxy incompatible with logout mechanism
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-3561?page=com.atlassian.jira.plugin.... ]
Heiko Braun moved HAL-20 to WFLY-3561:
--------------------------------------
Project: WildFly (was: HAL)
Key: WFLY-3561 (was: HAL-20)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Domain Management
(was: Authentication)
Security: Public
> mod_proxy incompatible with logout mechanism
> --------------------------------------------
>
> Key: WFLY-3561
> URL: https://issues.jboss.org/browse/WFLY-3561
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Jason Greene
> Assignee: Jason Greene
> Attachments: apache_mod_proxy_mgmt.conf, Screenshot_proxy_logs.png
>
>
> We need to either outlaw proxies, or to make sure the console works with them.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (JASSIST-226) automatical modification of class and method Annotation
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-226?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-226:
---------------------------------------
It seems that the usage of the API is wrong.
The argument to new Annotation() is the type name of the annotation.
The member of the annotation must be given by addMemberValue().
Please see the javadoc.
> automatical modification of class and method Annotation
> -------------------------------------------------------
>
> Key: JASSIST-226
> URL: https://issues.jboss.org/browse/JASSIST-226
> Project: Javassist
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.0-GA
> Environment: JavaSE-1.7, Eclipse Kepler
> Reporter: Paolo Paolo
> Assignee: Shigeru Chiba
> Labels: annotations
>
> I'm using Javassist to create .class file at runtime. Every method of the created class must have a Java Annotation ("@annotation example") with an URI. The problem is that the Annotation class modifies automatically the URI by substituting slashes with dots.
> //the Annotation String that I need
> @RDFBean('http://www.semanticweb.org/pi/2014/5/test#Test')
> //the resulting String
> @RDFBean('http:..www.semanticweb.org.pi.2014.5.test#Test')
> Is there a way to prevent this String modification?
> I suppose it's related to the different notation between a file path and a Java package.
> This is the code:
> ClassPool pool = ClassPool.getDefault();
> CtClass cc = pool.makeClass(className);
>
> ClassFile ccFile = cc.getClassFile();
> ConstPool constpool = ccFile.getConstPool();
> // create the annotation
> AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
> // classLocalName contains: http://www.semanticweb.org/pi/2014/5/test#Test
> Annotation annot = new Annotation("RDFBean('" + classLocalName + "')", constpool);
> attr.addAnnotation(annot);
> ccFile.addAttribute(attr);
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3560:
------------------------------
Component/s: Web (Undertow)
Forum Reference: https://community.jboss.org/message/879772
> 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
> Security Level: Public(Everyone can see)
> 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.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3560:
------------------------------
Affects Version/s: 8.1.0.Final
8.0.0.Final
> 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
> Security Level: Public(Everyone can see)
> 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.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3560:
------------------------------
Description:
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}
was:
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:
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]
If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
Here is a test code using Apache HTTP client
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);
}
> 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
> Security Level: Public(Everyone can see)
> 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.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Gary Yang (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Gary Yang updated WFLY-3560:
----------------------------
Description:
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:
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]
If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
Here is a test code using Apache HTTP client
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);
}
> 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
> Security Level: Public(Everyone can see)
> 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:
> 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]
>
> If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
> Here is a test code using Apache HTTP client
> 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);
> }
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months