April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3652) Network connection leak

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3652: ---------------------------------------- [~codeprince] FYI when a Jira issue is marked as 'Done' the 'Fix Version' field indicates which release contains the fix. > Network connection leak > ----------------------- > > Key: WFLY-3652 > URL: https://issues.jboss.org/browse/WFLY-3652 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.38-16-server > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Reporter: Jan Vanhercke > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem. > Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects. > However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack. > Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3652) Network connection leak

by Jason Spittel (JIRA)

[ https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin.... ] Jason Spittel commented on WFLY-3652: ------------------------------------- Where can I find the git commit for this? In the undertow repo? If in the wildfly repo, searching for 'WFLY-3652' in the logs or 3652 or 'Network connection leak' is not returning anything. > Network connection leak > ----------------------- > > Key: WFLY-3652 > URL: https://issues.jboss.org/browse/WFLY-3652 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.38-16-server > Java(TM) SE Runtime Environment (build 1.7.0_45-b18) > Reporter: Jan Vanhercke > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem. > Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects. > However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack. > Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-312) response.setBufferSize() has no effect when using the response writer

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/JBWEB-312?page=com.atlassian.jira.plugin.... ] Remy Maucherat commented on JBWEB-312: -------------------------------------- It is probably a great bad idea. It won't have any performance benefit, but it uses a lot more memory per connection (the buffer is never discarded, but recycled). > response.setBufferSize() has no effect when using the response writer > --------------------------------------------------------------------- > > Key: JBWEB-312 > URL: https://issues.jboss.org/browse/JBWEB-312 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Aaron Ogburn > > This is the same issue as https://issues.apache.org/bugzilla/show_bug.cgi?id=55842 > When using the response writer, we end up just flushing the buffer in org.apache.catalina.connector.OutputBuffer.realWriteChars instead of trying to grow the buffer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-761) Guided decision trees - new test for testing of unmarshalling drls containing different line endings

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-761: ------------------------------------ Summary: Guided decision trees - new test for testing of unmarshalling drls containing different line endings Key: DROOLS-761 URL: https://issues.jboss.org/browse/DROOLS-761 Project: Drools Issue Type: Enhancement Reporter: Tibor Zimányi Assignee: Michael Anstis Priority: Minor Drls can be written on different operating systems so they can contain different line endings. There is a need for test that will test unmarshalling DRLs with different line endings into GuidedDecisionTree models. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-759) GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling rules that contain line with only spaces in LHS

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-759?page=com.atlassian.jira.plugin... ] Michael Anstis resolved DROOLS-759. ----------------------------------- Fix Version/s: 6.3.0.Beta1 Resolution: Done https://github.com/droolsjbpm/drools/commit/7c4ba5b03 > GuidedDecisionTreeModelUnmarshallingVisitor doesn't support unmarshalling rules that contain line with only spaces in LHS > ------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-759 > URL: https://issues.jboss.org/browse/DROOLS-759 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Michael Anstis > Priority: Minor > Fix For: 6.3.0.Beta1 > > > GuidedDecisionTreeModelUnmarshallingVisitor don't support rules that contain lines with only spaces in LHS. These empty lines should be thrown away in preprocessing in RuleModelDRLPersistenceImpl. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-4374. ------------------------------- Resolution: Rejected Discussion may be resumed on the forums. > java.lang.IllegalAccessError and other classloader issues > --------------------------------------------------------- > > Key: WFLY-4374 > URL: https://issues.jboss.org/browse/WFLY-4374 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 8.2.0.Final, 9.0.0.Beta2 > Environment: Windows 7/Java 7 update 67 > Reporter: John Sipher > Assignee: David Lloyd > Attachments: problem-demo.zip > > > Update 4/1/2015: I have verified that 9.0.0.Beta2 fixes the IllegalAccessError and the war file in problem-demo.zip/hello-world6/target now duplicates the original problem. The order of the jar files in the classpath should be > WEB-INF/lib/patch/patch2.jar > WEB-INF/lib/patch/patch1.jar > WEB-INF/lib/base/helloworld-sans-cdi.jar > org.jboss.as.quickstarts.helloworld.HelloService exists in both patch2.jar and helloworld-sans-cdi.jar. The version from patch2.jar should be used because it is first in the classpath, but the classloader is picking up the original class from helloworld-sans-cdi.jar instead. > Original problem description follows: > We use manifest-only jar files in our WAR and EAR files to control the order that jar files are searched for classes. When we issue patches, we put the modified class(es) in a separate jar file, add that jar file to the affected EAR or WAR file, and update the classpath in our manifest-only jar file to put the new patch at the beginning of the class path so that it will be used in place of the original class (which is still in the original jar file). > > For example, WEB-INF/lib will contain a single jar file named manifest.jar and sub-folders named 3rdparty, base, patch, and custom. The Class-Path entry in WEB-INF/lib/manifest.jar|META-INF/MANIFEST.MF looks like this: > Class-Path: 3rdparty/manifest.jar patch/manifest.jar base/manifest.jar custom/manifest.jar > > When we publish a patch, the patch jar file is added to WEB-INF/lib/patch and to the front of the classpath in WEB-INF/lib/patch/manifest.jar's MANIFEST.MF. > > This worked fine for us for years with JBoss 4.2.3.GA, 5.1.0.GA, 7.1.2.Final, and 7.2.0.Final, but it's broken in WildFly 8.2.0.Final. > When I run it in debug I can see where the problem shows up in this section of org.jboss.modules.Module (lines 562 - 573). > final String path = pathOfClass(className); > final Map<String, List<LocalLoader>> paths = getPathsUnchecked(); > final List<LocalLoader> loaders = paths.get(path); > if (loaders != null) { > Class<?> clazz; > for (LocalLoader loader : loaders) { > clazz = loader.loadClassLocal(className, resolve); > if (clazz != null) { > return clazz; > } > } > } > The modules in the loaders list at line 565 are > * deployment.service.ear.lib/base/shared.jar:main > * deployment.service.ear.lib/base/deployment.jar:main > * deployment.service.ear.lib/patch/patch.jar:main > The last one should actually be the first in the list. I haven't been able to track down the actual source of the error yet. > I've been trying to create a simple example based on the helloworld quickstart to reproduce the problem, but I haven't been successful yet because of other classloader errors that I've run into. I decided to go ahead and open this issue and document the things I am able to reproduce. Those are: > 1. CDI injection doesn't work when the annotated classes are in jar files under WEB-INF/lib instead of unpacked in WEB-INF/classes. > 2. WildFly doesn't process the javax.servlet.annotation.WebServlet annotation if the jar file containing the annotated class is in a sub-folder of WEB-INF/lib. > 3. WildFly throws a java.lang.IllegalAccessError trying to load a "patched" class. > The first problem exists in both 7.2.0.Final and 8.2.0.Final. The other two problems are new in 8.2.0.Final. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4487) Unable to inject Web Service Context into CDI Interceptor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4487?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4487: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1210328 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149644, https://bugzilla.redhat.com/show_bug.cgi?id=1149646) > Unable to inject Web Service Context into CDI Interceptor > --------------------------------------------------------- > > Key: WFLY-4487 > URL: https://issues.jboss.org/browse/WFLY-4487 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: cdi-interceptors.zip > > > CDI Interceptor cannot inject Web Service context. > When trying to inject WebServiceContext in CDI Interceptor using @Resource annotation but it fails with: NameNotFoundException: env/org.example.MyInterceptor/webServiceContext -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-760) Code style formatters are not actual

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin... ] Tibor Zimányi updated DROOLS-760: --------------------------------- Description: Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. was: Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Code style formatters are not actual > ------------------------------------ > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zimányi > Assignee: Petr Široký > Priority: Minor > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-760) Code style formatters are not actual

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin... ] Tibor Zimányi updated DROOLS-760: --------------------------------- Attachment: code-styleQE.zip Attaching code style templates for IDEA and Eclipse that we use at QE. > Code style formatters are not actual > ------------------------------------ > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zimányi > Assignee: Petr Široký > Priority: Minor > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-760) Code style formatters are not actual

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-760: ------------------------------------ Summary: Code style formatters are not actual Key: DROOLS-760 URL: https://issues.jboss.org/browse/DROOLS-760 Project: Drools Issue Type: Task Reporter: Tibor Zimányi Assignee: Petr Široký Priority: Minor Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015