[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 commented on WFLY-4196:
----------------------------------------
Hi, I confirm after adding this configuration that the default gzip filter in undertow works correctly without any problem.
Neverless, my need is to handle it in the application and not globally in the server.
For the different ideas, as it works correctly in previous versions of Jboss (EAP 6, EAP 5 and EAP 4) with the same WAR, I think, you should perhaps look at how it is managed in these versions (I suppose in tomcat) to set a similar strategy.
I think for example, a strategy could be to detect that under a defined content size (for example 64kb), undertow bufferize and set the content-length after the filter processing. If more than 64kb content is detected, switch to chunked encoding which is justified.
To complete my case, my application serves small files like in the given sample war but also big text files of 25Mb which compress in a few Mb transparently through this gzip filter.
This problem seems not to be specific to gzip compression. Imagine a filter that does pre or post processing of files (js or css server side includes for example), the problem would be the same. From what I have seen with my application, for jquery.js file, if the browser does not have the correct Content-Length size, the file is not correctly interpreted.
> 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)
9 years, 5 months
[JBoss JIRA] (WFCORE-486) cli echo command should not output the result in columns
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-486?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFCORE-486:
------------------------------------------
Just a note, the commit in the PR is using CLIExpressionResolver class introduced by the changes in WFCORE-453.
> cli echo command should not output the result in columns
> --------------------------------------------------------
>
> Key: WFCORE-486
> URL: https://issues.jboss.org/browse/WFCORE-486
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 1.0.0.Alpha15
>
>
> Current implementation of echo command displays the results in columns. Originally its arguments where limited to variables only. Now it also accepts arbitrary text mixed with expressions. So, the logical and expected output would be now the string with the expressions resolved.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (WFLY-4164) New JTS record types are not showing up in the CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4164?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4164:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1168973|https://bugzilla.redhat.com/show_bug.cgi?id=1168973] from ASSIGNED to POST
> New JTS record types are not showing up in the CLI
> --------------------------------------------------
>
> Key: WFLY-4164
> URL: https://issues.jboss.org/browse/WFLY-4164
> Project: WildFly
> Issue Type: Enhancement
> Components: CLI, Transactions
> Reporter: Tom Jenkinson
> Assignee: Michael Musgrove
>
> We need to expose the new JTS record types in the tooling:
> {code}
> AssumedCompleteHeuristicTransaction
> AssumedCompleteHeuristicServerTransaction
> AssumedCompleteTransaction
> AssumedCompleteServerTransaction
> {code}
> We need these because if a transaction ends up in a heuristic state we can't actually view this using the CLI even though the records are in the object store. This has the consequence that a transaction can remain in the object store indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Dimitris Keramidas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Dimitris Keramidas commented on WFLY-3718:
------------------------------------------
I would also like to see this backported/patched/etc on 8.2. Or at least, some kind of a workaround, a better explanation regarding how/when it happens...
Thank you.
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (WFLY-4173) Server side EJB Handler not compression response
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4173?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4173:
-----------------------------------------------
Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 1172856|https://bugzilla.redhat.com/show_bug.cgi?id=1172856] from ASSIGNED to POST
> Server side EJB Handler not compression response
> ------------------------------------------------
>
> Key: WFLY-4173
> URL: https://issues.jboss.org/browse/WFLY-4173
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Tomas Hofman
>
> When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response.
> On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request
> TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream
> Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b
> TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
by Sergiy Barlabanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ]
Sergiy Barlabanov commented on WFLY-4198:
-----------------------------------------
Did some investigation:
The problem has nothing to do with slf4j & logback. When calling an async EJB there is only jboss logging in play. And AbstractMdcLoggerProvider#getMdcMap returns null, which causes LogDiagnosticContextRecoveryInterceptor#processInvocation to fail.
> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4198
> URL: https://issues.jboss.org/browse/WFLY-4198
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Sergiy Barlabanov
> Assignee: David Lloyd
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 5 months
