[JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-8466:
--------------------------------------
Yes, those three are all that are required
> Socket leak when setting HTTP Content-Length and client not reading entire response
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8466
> URL: https://issues.jboss.org/browse/WFLY-8466
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: CentOS 6.7
> Reporter: Johannes Ritter
> Assignee: Stuart Douglas
> Labels: leak, socket
> Attachments: socket_leak.tar.gz
>
>
> Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set.
> The leaked sockets can be determined by "lsof -p <process-id> | grep identify". The relevant sockets are listed with "Can't identify protocol".
> The leak occurs if the client connection is closed (on the client side) before the server could send the complete response.
> It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click.
> *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response
by Johannes Ritter (JIRA)
[ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.... ]
Johannes Ritter commented on WFLY-8466:
---------------------------------------
Thank you for the hint. After some first tests with Undertow 1.4.11 the issue seems to be fixed.
I downloaded Undertow 1.4.11 from [here|https://github.com/undertow-io/undertow/releases] and upgraded the following 3 modules:
* modules/system/layers/base/io/undertow/core/main/undertow-core-1.4.11.Final.jar
* modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.4.11.Final.jar
* modules/system/layers/base/io/undertow/websocket/main/undertow-websockets-jsr-1.4.11.Final.jar
I couldn't find a replacement for "modules/system/layers/base/io/undertow/js/main/undertow-js-1.0.2.Final.jar".
Since we have a serious issue on one of our customer's system regarding the socket leak I would like to upgrade Undertow on the customer system. It is save to only upgrade the 3 listed modules?
> Socket leak when setting HTTP Content-Length and client not reading entire response
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8466
> URL: https://issues.jboss.org/browse/WFLY-8466
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: CentOS 6.7
> Reporter: Johannes Ritter
> Assignee: Stuart Douglas
> Labels: leak, socket
> Attachments: socket_leak.tar.gz
>
>
> Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set.
> The leaked sockets can be determined by "lsof -p <process-id> | grep identify". The relevant sockets are listed with "Can't identify protocol".
> The leak occurs if the client connection is closed (on the client side) before the server could send the complete response.
> It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click.
> *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode.
by Manjunath S Paramesan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugi... ]
Manjunath S Paramesan updated DROOLS-1471:
------------------------------------------
Affects Version/s: 6.5.0.Final
> Unable to marshall a kieSession running in stream mode.
> -------------------------------------------------------
>
> Key: DROOLS-1471
> URL: https://issues.jboss.org/browse/DROOLS-1471
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final, 6.5.0.Final
> Reporter: Manjunath S Paramesan
> Assignee: Mario Fusco
>
> Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below:
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.NullPointerException
> at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142)
> at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324)
> at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode.
by Manjunath S Paramesan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugi... ]
Manjunath S Paramesan commented on DROOLS-1471:
-----------------------------------------------
This is not resolved in drools 6.5. We can reproduce this in drools 6.5.
> Unable to marshall a kieSession running in stream mode.
> -------------------------------------------------------
>
> Key: DROOLS-1471
> URL: https://issues.jboss.org/browse/DROOLS-1471
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Manjunath S Paramesan
> Assignee: Mario Fusco
>
> Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below:
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.NullPointerException
> at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142)
> at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324)
> at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8471) Elytron, *-authentication-factory protocol attribute should be case insensitive
by Martin Choma (JIRA)
Martin Choma created WFLY-8471:
----------------------------------
Summary: Elytron, *-authentication-factory protocol attribute should be case insensitive
Key: WFLY-8471
URL: https://issues.jboss.org/browse/WFLY-8471
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
When I use "HTTP" in protocol attribute instead of "http", I get 403 instead of succesfull access.
According to http://www.rfc-base.org/txt/rfc-1738.txt
Scheme names consist of a sequence of characters. The lower case
letters "a"--"z", digits, and the characters plus ("+"), period
("."), and hyphen ("-") are allowed. For resiliency, programs
interpreting URLs should treat upper case letters as equivalent to
lower case in scheme names (e.g., allow "HTTP" as well as "http").
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2595) Get rid of the subsystem test framework's use of jboss-metadata-common
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2595?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2595:
------------------------------------------
What the jboss-metadata stuff brings that ExpressionResolver doesn't is resolution against a set of passed in properties.
> Get rid of the subsystem test framework's use of jboss-metadata-common
> ----------------------------------------------------------------------
>
> Key: WFCORE-2595
> URL: https://issues.jboss.org/browse/WFCORE-2595
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
>
> The subsystem test framework's SchemaValidator class requires some expression resolution stuff from jboss-metadata-common, which means we have a test-only dep on that lib in core. Look into using something else for this, e.g. ExpressionResolver.SIMPLE_LENIENT. All it is doing is replacing expressions with defaults with the default value.
> SchemaValidator is less useful than we originally envisioned anyway, as a lot of the subsystem templates cannot be valid as they include substitution data.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2598) PathManager capability registration not available to resources
by Paul Ferraro (JIRA)
Paul Ferraro created WFCORE-2598:
------------------------------------
Summary: PathManager capability registration not available to resources
Key: WFCORE-2598
URL: https://issues.jboss.org/browse/WFCORE-2598
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Beta11
Reporter: Paul Ferraro
Assignee: Brian Stansberry
When attempting to add a requirement on the PathManager capability to a capability registered with some resource, e.g.
{noformat}
RuntimeCapability<Void> MY_CAPABILITY = RuntimeCapability.Builder.of("foo").addRequirements("org.wildfly.management.path-manager").build();
{noformat}
I get the following error during boot:
16:30:55,229 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=infinispan/cache-container=web/distributed-cache=dist/store=file' are not available:
org.wildfly.management.path-manager; There are no known registration points which can provide this capability.
It seems like this capability registration isn't available to subsystem resources.
Here's the real world use case:
https://github.com/pferraro/wildfly/commit/d5a00ecb6975137e40848b45abfc66...
See org.jboss.as.clustering.infinispan.subsystem.FileStoreResourceDefinition
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8466) Socket leak when setting HTTP Content-Length and client not reading entire response
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8466?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-8466:
--------------------------------------
Can you test with the latest Undertow (1.4.11.Final) and see if this resolves it?
> Socket leak when setting HTTP Content-Length and client not reading entire response
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8466
> URL: https://issues.jboss.org/browse/WFLY-8466
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: CentOS 6.7
> Reporter: Johannes Ritter
> Assignee: Stuart Douglas
> Labels: leak, socket
> Attachments: socket_leak.tar.gz
>
>
> Wildfly leaks half-open sockets if the client closes the connection before all data was sent to the client. This only happens when the HTTP header field "Content-Length" was manually set.
> The leaked sockets can be determined by "lsof -p <process-id> | grep identify". The relevant sockets are listed with "Can't identify protocol".
> The leak occurs if the client connection is closed (on the client side) before the server could send the complete response.
> It does not happen every time. I have attached an example application using a web browser as client. One button click sends the request 500 times. The socket does not leak on every button click.
> *Another interesting fact is, that the socket will also leak if a Content-Length larger than the actual response data is set.* This is independent from the client's behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years