[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3560.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> 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, 9.0.0.Alpha1
> Reporter: Gary Yang
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> 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
[JBoss JIRA] (WFLY-3467) Wildfly URI encoding (again..)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3467?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3467.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Wildfly URI encoding (again..)
> ------------------------------
>
> Key: WFLY-3467
> URL: https://issues.jboss.org/browse/WFLY-3467
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Linux CentOS
> Reporter: Bob Slydell
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have a very simple Servlet
> @WebServlet("/HelloServlet")
> public class HelloServlet extends HttpServlet
> with a doGet method that prints and returns the "foo" parameter:
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> PrintWriter out = response.getWriter();
> String foo = request.getParameter("foo");
> out.println("Hello " + foo);
> System.out.println("Hello " + foo);
> out.close();
> }
> When running jboss 7.1.1.Final this works fine. I can test with a simple curl script:
> curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
> where $'\xc3\xa5' is "aring" or "a with a ring", (å). I know the console can handle this, because echo $'\xc3\xa5' gives:
> [slydell@localhost hello]$ echo $'\xc3\xa5'
> å
> [slydell@localhost hello]$
> If I run the curl script on jboss 7.1.1.Final I get:
> [slydell@localhost hello]$ curl http://127.0.0.1:8080/hello-1/HelloServlet?foo=b$'\xc3\xa5'r
> Hello bår
> [slydell@localhost hello]$
> and the jboss console output says:
> 09:18:19,483 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
> I can change this output by adding
> JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.connector.URI_ENCODING=UTF-8"
> to the standalone.conf. With that flag I get:
> 09:20:57,780 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
> But when I run the curl script on wildfly 8.1.0.Final I get different results. I know that the catalina flag has no effect on undertow, and I have also tried all the workarounds I've seen, e.g.
> * implement a CharacterEncoding filter
> * set encoding in jboss-web.xml
> * set default-encoding in servlet-containter in the standalone.xml
> * set encoding in the http-listener in the standalone.xml
> None of these workarounds have any effect. I always get the same result:
> 09:22:42,330 INFO [stdout] (default task-1) Hello bￃﾥr
> which does not look like anything I've seen in UTF-8 or ISO-8859-1.
> If I could get the same output as I do in the jboss 7.1.1.Final (without the catalina flag) I would be very happy. The standard non-modified jboss 7.1.1 gave me this output:
> 09:31:11,723 INFO [stdout] (http--127.0.0.1-8080-1) Hello bår
> So my question is, how do I modify/configure wildfly so that I get the same output as I do in the standard jboss 7.1.1.Final? I have tried the known workarounds, and they did not change any output.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3895) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3895?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3895.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> 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.1#6329)
10 years
[JBoss JIRA] (WFLY-3835) Add missing statistics to Undertow subsystem
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3835?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3835:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Add missing statistics to Undertow subsystem
> --------------------------------------------
>
> Key: WFLY-3835
> URL: https://issues.jboss.org/browse/WFLY-3835
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management, Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> This includes:
> Deployment level session manager statistics:
> duplicated-session-ids
> expired-sessions
> max-active-sessions
> rejected-sessions
> session-avg-alive-time
> session-max-alive-time
> Servlet level statistics:
> load-time
> error-count
> Connector level statistics:
> bytes-received
> bytes-sent
> error-count
> processing-time
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3255) IllegalArgumentException occurs while accessing the handler information via JMX MBean?
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3255?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3255:
-----------------------------------------------
James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1087146|https://bugzilla.redhat.com/show_bug.cgi?id=1087146] from NEW to ASSIGNED
> IllegalArgumentException occurs while accessing the handler information via JMX MBean?
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3255
> URL: https://issues.jboss.org/browse/WFLY-3255
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.1.0.CR1
> Reporter: Jay Kumar SenSharma
> Assignee: James Perkins
> Labels: dmr
> Fix For: 9.0.0.Alpha1
>
> Attachments: WFLY-3255_TestCase.zip
>
>
> - While trying to get the "handler" information via JMX code the following kind of exception is encountered:
> {code}
> 12:09:24,853 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /LoggerJMX/index.jsp: org.apache.jasper.JasperException: java.lang.IllegalArgumentException
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.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.5.Final.jar:1.0.5.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.5.Final.jar:1.0.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getChild(ModelValue.java:112)
> at org.jboss.dmr.ModelNode.get(ModelNode.java:856)
> at org.jboss.as.jmx.model.TypeConverters$ComplexTypeConverter.fromModelNode(TypeConverters.java:538)
> at org.jboss.as.jmx.model.TypeConverters$ListTypeConverter.fromModelNode(TypeConverters.java:444)
> at org.jboss.as.jmx.model.TypeConverters.fromModelNode(TypeConverters.java:114)
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getAttribute(ModelControllerMBeanHelper.java:245)
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getAttribute(ModelControllerMBeanHelper.java:200)
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getAttribute(ModelControllerMBeanServerPlugin.java:96)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:384)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:73)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.Final.jar:1.0.0.Final]
> ... 28 more
> {code}
> - The Handler is configured as following:
> {code}
> <logger category="org.jboss.as.config">
> <handlers>
> <handler name="CONSOLE"/>
> </handlers>
> <level name="DEBUG"/>
> </logger>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (LOGTOOL-86) Add ability to use contravariant return type
by David Lloyd (JIRA)
David Lloyd created LOGTOOL-86:
----------------------------------
Summary: Add ability to use contravariant return type
Key: LOGTOOL-86
URL: https://issues.jboss.org/browse/LOGTOOL-86
Project: Log Tool
Issue Type: Enhancement
Reporter: David Lloyd
Assignee: James Perkins
Priority: Minor
I'd like to have the ability to specify a *less* specific type as the return type compared to the type that is instantiated.
For example I should be able to say something like this:
{code}
@Message(id = 12345, value = "There is a big problem named %s")
@ConstructType(IllegalArgumentException.class) // <-
RuntimeException bigProblem(String blah);
{code}
In this example I'm generating a method which returns {{RuntimeException}}, however the actual exception type I want to construct is an {{IllegalArgumentException}}.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-155) Evaluate robustness of decisions about target versions for transformation
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-155:
---------------------------------------
Summary: Evaluate robustness of decisions about target versions for transformation
Key: WFCORE-155
URL: https://issues.jboss.org/browse/WFCORE-155
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 1.0.0.CR1
Apologies; this is a bit vague, just a general thing I want us to look into.
Task is to evaluate how we choose whether transformation needs to occur for a given management API version from a slave, with a view toward checking that intelligent choices are made in the absence of proper transformation definitions.
The main kind of thing I'm thinking about is the DC is on 2.0.0 and has a transformer to 1.1.0 registered, and then a slave registers that is using 1.1.1. The subsystem author likely forgot to create the transformation to 1.1.1. Odds are good though that transforming to 1.1.0 is a better choice than not transforming and treating the slave as if it were on 2.0.0.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years