[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4196:
--------------------------------------
This sounds like a bug in the filter, if you are modifying the length of the response (e.g. by compressing content) then you need to make sure you clear the content length header if it has been set.
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Nicolas Cazottes (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Nicolas Cazottes updated WFLY-4196:
-----------------------------------
Attachment: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war
fiddler_protocol_violation.jpg
War to reproduce the problem
Screenshot of fiddler
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Nicolas Cazottes (JIRA)
Nicolas Cazottes created WFLY-4196:
--------------------------------------
Summary: HTTP protocol violation
Key: WFLY-4196
URL: https://issues.jboss.org/browse/WFLY-4196
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final, 8.1.0.Final
Reporter: Nicolas Cazottes
Assignee: Stuart Douglas
Priority: Blocker
If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
The explanation is that the web application uses a filter to compress the content in gzip format.
For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-3895) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
by Karthick Jaganathan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3895?page=com.atlassian.jira.plugin.... ]
Karthick Jaganathan commented on WFLY-3895:
-------------------------------------------
Is this fixed in undertow? I'm directly using undertow as an embedded server. I tried using the latest version and it does not seem to have fixed in it.
> Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
> -----------------------------------------------------------------
>
> Key: WFLY-3895
> URL: https://issues.jboss.org/browse/WFLY-3895
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> This happens with an Http POST request for a Jolokia MBean operation.
> Attribute reads seem to work.
> {code}
> 10:28:10,823 ERROR [io.undertow.request] (default task-3) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}: 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.2.Final.jar:3.2.2.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1952)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:146)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:588)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1404)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:193)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFCORE-161) JMX monitoring is extremely memory inefficient
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-161:
------------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1154868|https://bugzilla.redhat.com/show_bug.cgi?id=1154868] from POST to MODIFIED
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFCORE-161
> URL: https://issues.jboss.org/browse/WFCORE-161
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Koen Janssens
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha11
>
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFCORE-455) Include additional sun.jdk dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-455?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-455:
------------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1172681|https://bugzilla.redhat.com/show_bug.cgi?id=1172681] from POST to MODIFIED
> Include additional sun.jdk dependencies
> ----------------------------------------
>
> Key: WFCORE-455
> URL: https://issues.jboss.org/browse/WFCORE-455
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Affects Versions: 1.0.0.Alpha14
> Reporter: Mustafa Musaji
> Assignee: David Lloyd
>
> Include the following out of the box for sun.jdk module
> - for working with javax.sql.rowset.RowSetProvider
> <path name="com/sun/rowset"/>
> <path name="com/sun/rowset/providers"/>
> - for working with java.lang.invoke.MethodHandleProxies
> <path name="sun/invoke"/>
> This affects EAP customers using CP releases when overlays override changes made in the original module.xml. For sun.jdk classes, the above packages should be included out of the box.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4194) Deprecate default-stack JGroups subsystem attribute
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4194?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-4194:
-------------------------------
Description:
The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
1. The JChannelFactory of the default stack.
2. The ForkChannelFactory of the default channel.
#2 is the better option - and is what Infinispan transports use by default.
This would require that the stack attribute of a channel is required (currently, it is optional and defaults to the default-stack).
was:
The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
1. The JChannelFactory of the default stack.
2. The ForkChannelFactory of the default channel.
#2 is the better option - and is what Infinispan transports use by default.
> Deprecate default-stack JGroups subsystem attribute
> ---------------------------------------------------
>
> Key: WFLY-4194
> URL: https://issues.jboss.org/browse/WFLY-4194
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
> 1. The JChannelFactory of the default stack.
> 2. The ForkChannelFactory of the default channel.
> #2 is the better option - and is what Infinispan transports use by default.
> This would require that the stack attribute of a channel is required (currently, it is optional and defaults to the default-stack).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4194) Deprecate default-stack JGroups subsystem attribute
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-4194:
----------------------------------
Summary: Deprecate default-stack JGroups subsystem attribute
Key: WFLY-4194
URL: https://issues.jboss.org/browse/WFLY-4194
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 9.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
1. The JChannelFactory of the default stack.
2. The ForkChannelFactory of the default channel.
#2 is the better option - and is what Infinispan transports use by default.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs
by Peter Major (JIRA)
[ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.... ]
Peter Major edited comment on WFLY-4113 at 12/19/14 12:38 PM:
--------------------------------------------------------------
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT my build finally finished, only thing to note is that org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase test case can take around 386.621 seconds to finish.
was (Author: aldaris):
This is what I had done:
{noformat}
# Build byteman 2.0.0, since it is not available in any of the repositories defined by jboss-remoting's POM
git clone https://github.com/bytemanproject/byteman.git
cd byteman
git checkout 2.0.0
mvn clean install
# We can build jboss-remoting now
git clone https://github.com/jboss-remoting/jboss-remoting.git
cd jboss-remoting
git checkout 4.0
# Need to build jboss-remoting with english locale, because "Connection refused" is hardcoded in org.jboss.remoting3.test.RemoteChannelTest
LC_ALL=en_US.UTF-8 mvn clean install
{noformat}
After modifying the WildFly pom to include 4.0.7.Final-SNASHOT my build finaly finished, only thing to note is that org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase test case can take around 386.621 seconds to finish.
> 8.2.0.Final build hangs
> -----------------------
>
> Key: WFLY-4113
> URL: https://issues.jboss.org/browse/WFLY-4113
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Peter Major
> Assignee: David Lloyd
> Attachments: jstack.txt
>
>
> When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module:
> {noformat}
> Running org.jboss.as.controller.ModelControllerClientTestCase
> {noformat}
> Running jstack against the build suggests that there is a deadlock between
> {noformat}
> - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
> - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232)
> {noformat}
> and
> {noformat}
> - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:160)
> {noformat}
> Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4113:
--------------------------------------
@Peter, I've also end up doing that, and ran into the same local issue with JBoss Remoting build [https://issues.jboss.org/browse/REM3-202]. I've pushed a PR to fix that [https://github.com/jboss-remoting/jboss-remoting/pull/33]
> 8.2.0.Final build hangs
> -----------------------
>
> Key: WFLY-4113
> URL: https://issues.jboss.org/browse/WFLY-4113
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 8.2.0.Final
> Reporter: Peter Major
> Assignee: David Lloyd
> Attachments: jstack.txt
>
>
> When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module:
> {noformat}
> Running org.jboss.as.controller.ModelControllerClientTestCase
> {noformat}
> Running jstack against the build suggests that there is a deadlock between
> {noformat}
> - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423)
> - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232)
> {noformat}
> and
> {noformat}
> - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque)
> at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283)
> - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:160)
> {noformat}
> Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
