[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 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)
10 years, 1 month
[JBoss JIRA] (WFLY-3696) Security domain configuration doesn't allow empty or missing login-module-stack
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3696?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3696:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 901075|https://bugzilla.redhat.com/show_bug.cgi?id=901075] from ON_QA to VERIFIED
> Security domain configuration doesn't allow empty or missing login-module-stack
> -------------------------------------------------------------------------------
>
> Key: WFLY-3696
> URL: https://issues.jboss.org/browse/WFLY-3696
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> https://bugzilla.redhat.com/show_bug.cgi?id=901075 description:
> project_key: JBPAPP6
> Adding a security domain with JASPI authentication fails if there is no (or is empty) login-module-stack. It should be possible to add custom ServerAuthModule, which doesn't use JAAS login modules.
> {code:xml}
> <security-domain name="jmx-console" cache-type="default">
> <authentication-jaspi>
> <!-- FIXME: the not empty login-module-stack must be provided even it's not used -->
> <login-module-stack name="lm-stack">
> <login-module code="UsersRoles" flag="required"/>
> </login-module-stack>
> <auth-module code="org.jboss.example.CustomServerAuthModule" flag="required">
> <module-option name="option1" value="value1" />
> </auth-module>
> </authentication-jaspi>
> </security-domain>
> {code}
> It should be possible to remove here the login-module-stack element.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[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 commented on WFLY-3560:
-----------------------------------
You can try with 9.0.0.Alpha1 which was released last week and should have this fixed.
> 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)
10 years, 1 month
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by bene.net (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
bene.net edited comment on WFLY-3560 at 9/22/14 7:58 AM:
---------------------------------------------------------
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduced like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information helps to fix the issue.
Thanks a lot!
was (Author: bene.net):
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduced like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
> 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)
10 years, 1 month
[JBoss JIRA] (JBJCA-1219) Fungal 0.11.0.Final
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1219:
--------------------------------------
Summary: Fungal 0.11.0.Final
Key: JBJCA-1219
URL: https://issues.jboss.org/browse/JBJCA-1219
Project: IronJacamar
Issue Type: Component Upgrade Subtask
Components: Build
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.0.CR1
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by bene.net (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
bene.net edited comment on WFLY-3560 at 9/22/14 7:55 AM:
---------------------------------------------------------
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduced like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
was (Author: bene.net):
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduces like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
> 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)
10 years, 1 month
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by bene.net (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
bene.net edited comment on WFLY-3560 at 9/22/14 7:52 AM:
---------------------------------------------------------
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduces like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
was (Author: bene.net):
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{/code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduces like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{/code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
> 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)
10 years, 1 month
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by bene.net (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
bene.net commented on WFLY-3560:
--------------------------------
We got the same exception on a HTTP PUT:
{code}
Blocking request failed HttpServerExchange{ PUT /veto-ifc/ifcv1/definitions/resource-versions/3083}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
...
{/code}
In our case we use a .NET client to connect to a REST service deployed in WildFly 8.1.0.Final "Kenny".
The problem can be reproduces like this:
1. The .NET client does not send user credentials, but sends header "Expect: 100-continue" and HTTP content
2. Wildfly immediately returns HTTP/1.1 401 Unauthorized
3. Client sends content and ignores 401 Unauthorized
{code}
PUT /veto-ifc/ifcv1/definitions/resource-versions/3083 HTTP/1.1
Accept: application/xml
Content-Type: application/xml
Host: bchlap-11.head.de:8080
Content-Length: 112994
Expect: 100-continue
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Basic realm="VETO Interface"
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/xml; charset=UTF-8
Content-Length: 409
Date: Mon, 22 Sep 2014 09:45:03 GMT
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" base-uri="http://bchlap-11.head.de:8080/veto-ifc/" xsi:noNamespaceSchemaLocation="response.xsd">
<status>
<message key="ERROR_ACCESS_DENIED">
<param key="details" value="Authentication credentials are required"/>
</message>
</status>
</response>
<resource xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="resource.xsd">
<database-meta-data>
<meta-data group="VERSION" key="00-Basis" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="01-Activity" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="02-Activity_WithV1" value="3.0.0-SNAPSHOT" />
<meta-data group="VERSION" key="UpgradeDbTool" value="3.0.0-SNAPSHOT (n/a)" />
<meta-data group="VERSION" key="ImportExportTool" value="3.0.0-SNAPSHOT (2014-09-22 11:10:22.692+0200)" />
</database-meta-data>
... more content ...
{/code}
Our workaround is to use HttpWebRequest.PreAuthenticate Property in the client to avoid 401 Unauthorized.
http://msdn.microsoft.com/de-de/library/system.net.httpwebrequest.preauth...
I hope this information help to fix the issue.
Thanks a lot!
> 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)
10 years, 1 month
[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1883:
--------------------------------
Richard, have you pinged Tristan ? I don't want this to be another JIRA corpse lying around forever... :-)
> Extend SASL protocol to handle Quality of Protection
> -----------------------------------------------------
>
> Key: JGRP-1883
> URL: https://issues.jboss.org/browse/JGRP-1883
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.5
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.6
>
>
> SASL implementations generally provide authentication and encryption services to communication protocols.
> At present, the JGroups SASL protocol layer handles only authentication of a client joining a group; it does not support encryption of messages (unicast and multicast) passing through the SASL layer. This is presently handled by the separate ENCRYPT layer.
> It would be nice to provide an integrated and complete solution for authentication and encryption for JGroups based on SASL. This could be achieved by adding functionality from ENCRYPT to the SASL layer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-117) Typo in add-user help text
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-117?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-117:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1145036
> Typo in add-user help text
> --------------------------
>
> Key: WFCORE-117
> URL: https://issues.jboss.org/browse/WFCORE-117
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 1.0.0.Alpha8
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha9
>
>
> There is a typo in help message of add-user tool.
> Version-Release number of selected component (if applicable):
> EAP 6.4.0.DR1.1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. ./add-user.sh --help
> Actual results:
> ...
> -sc <value> Define the location the server config
> directory.
> ...
> Expected results:
> ...
> -sc <value> Define the location of the server config
> directory.
> ...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month