[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:
---------------------------------
I narrowed down the issue. It is not Connection:keep-alive related. It is POST + content body + Expect:100=continue issue.
These will cause Wildfly to throw exception:
curl -X POST -H Content-Type:text/plain -H Expect:100-continue -d 'test' http://localhost:8080/
curl -X POST -H Content-Type:application/json -H Expect:100-continue -d '"name":"joe"' http://localhost:8080/
These will not:
curl -X POST -H Content-Type:text/plain -H Expect:100-continue http://localhost:8080/
curl -X POST -H Expect:100-continue -d 'test' http://localhost:8080/
curl -X POST -H Expect:100-continue http://localhost:8080/
Don't see the problem with PUT actions.
> Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3560
> URL: https://issues.jboss.org/browse/WFLY-3560
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Gary Yang
> Assignee: Jason Greene
>
> Issue is described in https://community.jboss.org/thread/242415
> If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
> {noformat}
> 2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> {noformat}
>
> If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
> Here is a test code using Apache HTTP client
> {code:java}
> HttpPost request = new HttpPost(serverURL);
> for (int i=0; i<200; i++) {
> StringEntity input = new StringEntity (payLoad);
> input.setContentType("application/json");
> request.setHeader("Connection", "keep-alive");
> request.setHeader("Expect", "100-continue");
> request.setEntity(input);
> HttpResponse response = httpclient.execute(request);
> HttpEntity entity = response.getEntity();
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (DROOLS-509) Constraint method is resolved erroneously when potential ambiguities exist
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-509?page=com.atlassian.jira.plugin... ]
Mario Fusco updated DROOLS-509:
-------------------------------
Labels: backport-to-6.0.x (was: )
> Constraint method is resolved erroneously when potential ambiguities exist
> --------------------------------------------------------------------------
>
> Key: DROOLS-509
> URL: https://issues.jboss.org/browse/DROOLS-509
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.6.0.Final, 6.1.0.Beta4
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Critical
> Labels: backport-to-6.0.x
> Fix For: 6.1.0.CR1
>
>
> Assume:
> Class X implement I1
> Interface I1 extends I0
> I0 defines the property foo
> Write a rule:
> I1( foo == .. )
> and insert an instance of class X
> The condition analyzer will look in classes first, rather than interfaces, assuming that "foo" is provided by X.
> The next time an instance of some class Y implementing I1 is inserted,
> a ClassCastException will be thrown since X is expected
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1309:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1110065|https://bugzilla.redhat.com/show_bug.cgi?id=1110065] from MODIFIED to ON_QA
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"i1\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-2511) NPE in QueueReadAttributeHandler if QueueControl does not exist
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2511?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2511:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1095294|https://bugzilla.redhat.com/show_bug.cgi?id=1095294] from MODIFIED to ON_QA
> NPE in QueueReadAttributeHandler if QueueControl does not exist
> ---------------------------------------------------------------
>
> Key: WFLY-2511
> URL: https://issues.jboss.org/browse/WFLY-2511
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1
>
>
> I noticed this in a testsuite server log for EAP, but looking at WF code the same thing could happen there. Basically QueueReadAttributeHandler assumes a QueueControl exists and throws an NPE if that assumption is wrong:
> 19:14:25,402 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("queue" => "39742e8e-32e7-481d-905a-580fd6b67476")
> ]): java.lang.NullPointerException
> at org.jboss.as.messaging.QueueReadAttributeHandler.executeRuntimeStep(QueueReadAttributeHandler.java:115)
> at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:96) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_25]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
> IIRC this kind of thing has been fixed elsewhere???
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years