October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3966) Update saaj-impl based on fix for SAAJ-74

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3966: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151526 > Update saaj-impl based on fix for SAAJ-74 > ----------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3720) Run clustering tests with ip_ttl=0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3720?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-3720: -------------------------------------- There seems to be a test in manual mode section that also needs addressing. > Run clustering tests with ip_ttl=0 > ---------------------------------- > > Key: WFLY-3720 > URL: https://issues.jboss.org/browse/WFLY-3720 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: testsuite > Fix For: 9.0.0.Alpha1 > > > Best we could probably change the xml in the subsystem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps

by Russell Nile (JIRA)

[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ] Russell Nile commented on WFLY-3560: ------------------------------------ .NET solicitors will be sending the "Expect: 100-continue" by default. The way to turn that off is: System.Net.ServicePointManager.Expect100Continue = false; or, for an individual request: var req = (HttpWebRequest) WebRequest.Create(...); req.ServicePoint.Expect100Continue = false; This workaround works for us only because we know the client (and there is only one). If you have a public facing service you may have some challenges. > 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

1
0
0 / 0

[JBoss JIRA] (DROOLS-628) DecisionTable incorrectly parsed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-628?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-628: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1150308|https://bugzilla.redhat.com/show_bug.cgi?id=1150308] from ASSIGNED to MODIFIED > DecisionTable incorrectly parsed > --------------------------------- > > Key: DROOLS-628 > URL: https://issues.jboss.org/browse/DROOLS-628 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.2.0.CR1 > > > 5.2.0.CR1 creates incorrect drl from decision table. With 5.1.0.M1 the drl for the same decision table is correct. > Wrong DRL from 5.2.0.CR1: > rule "ProcessState" > salience 65522 > ruleflow-group "CompleteSubOrder" > activation-group "ProcessState" > when > $m:ModifiedMarker(processState==null, state ==null) > $s:SubOrder > then > $m.setIsModified(true); > $s.setProcessState(ProcessState.CREATED); > end > Correct DRL with 5.1.0.M1: > rule "ProcessState" > salience 65522 > ruleflow-group "CompleteSubOrder" > activation-group "ProcessState" > when > $m:ModifiedMarker() > $s:SubOrder(processState==null, state ==null) > then > $m.setIsModified(true); > $s.setProcessState(ProcessState.CREATED); > end > The difference is that the constraints are put to $m instead of putting them to $s. > The behaviour in 5.2.0.CR1 is the same for all decision tables in my project and prevents me from upgrading to newer drools versions. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-3942: --------------------------------- Bugzilla Update: (was: Perform) > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3942: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1083563 > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ] Karel Piwko updated WFLY-1264: ------------------------------ Assignee: Panagiotis Sotiropoulos (was: Karel Piwko) > Create a test to get notifications when hosts join/leave a domain > ----------------------------------------------------------------- > > Key: WFLY-1264 > URL: https://issues.jboss.org/browse/WFLY-1264 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Andrew Rubinger > Assignee: Panagiotis Sotiropoulos > > Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ] Karel Piwko commented on WFLY-1264: ----------------------------------- Requirement is to be able to figure out when host joins or leaves the domain. If there is a notification bus in WF, Arquillian should get information from it. Otherwise, being able to ask for current hosts and do diff in time seems like a reasonable approach. Note, Arquillian does not have a notification bus - so notification are rather "a way to figure that out" in my opinion. > Create a test to get notifications when hosts join/leave a domain > ----------------------------------------------------------------- > > Key: WFLY-1264 > URL: https://issues.jboss.org/browse/WFLY-1264 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Andrew Rubinger > Assignee: Karel Piwko > > Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps

by Russell Nile (JIRA)

[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ] Russell Nile commented on WFLY-3560: ------------------------------------ Folks, .NET solicitors will be sending the "Expect: 100-continue" by default. The way to turn that off is: System.Net.ServicePointManager.Expect100Continue = false; or, for an individual request: var req = (HttpWebRequest) WebRequest.Create(...); req.ServicePoint.Expect100Continue = false; This workaround works for us only because we know the client (and there is only one). If you can't and have a public facing service you may have some challenges. > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-1264) Create a test to get notifications when hosts join/leave a domain

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFLY-1264?page=com.atlassian.jira.plugin.... ] Panagiotis Sotiropoulos edited comment on WFLY-1264 at 10/10/14 9:00 AM: ------------------------------------------------------------------------- Karel could you please provide the requirements and assign the issue back, or close it? Thank you in advance. was (Author: takis): Karel could you please provide the requirements and assign the issue back, or close it. Thank you in advance. > Create a test to get notifications when hosts join/leave a domain > ----------------------------------------------------------------- > > Key: WFLY-1264 > URL: https://issues.jboss.org/browse/WFLY-1264 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Andrew Rubinger > Assignee: Karel Piwko > > Should be implemented by using the mechanism provided by AS7-1415, injection of the ManagementClient into the test. Verify this is working to fulfill the feature request from QE to get notifications on hosts joining/leaving the Domain. May depend upon the presence of an AS7 Domain Controller Container. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014