March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3146: ----------------------------------- It looks certain that upstream Undertow plus the aforementioned XNIO commits together fix this issue on Linux at least. [~ctomc] can you confirm Windows? If Windows is OK, then we can resolve this issue once both XNIO and Undertow releases are tagged and are upstream. > Undertow Memory Leak for JAX-RS requests > ---------------------------------------- > > Key: WFLY-3146 > URL: https://issues.jboss.org/browse/WFLY-3146 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: Windows 7 Professional > JDK 1.7.0_21 > WildFly 8.0.0.Final > Reporter: Darren Jones > Assignee: Tomaz Cerar > Priority: Critical > Labels: MemoryLeak > Fix For: 8.0.1.Final > > Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png > > > After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log. > I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. > I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently). > I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem. > The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem. > I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3146: ----------------------------------- Cautiously optimistic that we have a fix for the SSL issue, will confirm soon. > Undertow Memory Leak for JAX-RS requests > ---------------------------------------- > > Key: WFLY-3146 > URL: https://issues.jboss.org/browse/WFLY-3146 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: Windows 7 Professional > JDK 1.7.0_21 > WildFly 8.0.0.Final > Reporter: Darren Jones > Assignee: Tomaz Cerar > Priority: Critical > Labels: MemoryLeak > Fix For: 8.0.1.Final > > Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png > > > After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log. > I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. > I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently). > I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem. > The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem. > I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3067: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079084, https://bugzilla.redhat.com/show_bug.cgi?id=1079085 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1079084) > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3067: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079084 > Webservices DUP is not scanning all visible classes for @WebService annotation > ------------------------------------------------------------------------------ > > Key: WFLY-3067 > URL: https://issues.jboss.org/browse/WFLY-3067 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.0.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 8.0.1.Final > > > Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this: > {noformat} > UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBEE-146) jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-146?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-146: ---------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from MODIFIED to ON_QA > jboss-el-api_2.2_spec 1.0.2.Final cannot access public methods from non-public classes > -------------------------------------------------------------------------------------- > > Key: JBEE-146 > URL: https://issues.jboss.org/browse/JBEE-146 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: jboss-el-api_2.2_spec-1.0.3.Final, jboss-el-api_3.0_spec-1.0.0.Final > > > When accessing a public method of a non-public class via EL that implements a public interface or has a public superclass, the following exception occurs: > {code}java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "public" > {code} > See https://bugzilla.redhat.com/show_bug.cgi?id=1029387 for more details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2493: ----------------------------------------------- Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from MODIFIED to ON_QA > EL cannot access public methods/fields of non-public classes > ------------------------------------------------------------ > > Key: WFLY-2493 > URL: https://issues.jboss.org/browse/WFLY-2493 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Environment: JBoss AS 7.2.0.Final > Reporter: Jonáš Trantina > Attachments: elresolver_stack, reproducer.zip > > > When trying to access public method/field of non-public class that implements public interface via EL I get > {noformat} > java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private" > {noformat} > E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface. > This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround. > Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking. > I have attached a simple reproducer app as well as a stack trace of the exception. > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-3146: ----------------------------------- https://github.com/xnio/xnio/commit/7dbdf6f5424b seems to take care of the non-SSL case completely. Still looking into the SSL case. > Undertow Memory Leak for JAX-RS requests > ---------------------------------------- > > Key: WFLY-3146 > URL: https://issues.jboss.org/browse/WFLY-3146 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: Windows 7 Professional > JDK 1.7.0_21 > WildFly 8.0.0.Final > Reporter: Darren Jones > Assignee: Tomaz Cerar > Priority: Critical > Labels: MemoryLeak > Fix For: 8.0.1.Final > > Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png > > > After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log. > I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. > I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently). > I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem. > The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem. > I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3145) Problem with HTTPS Failed to start the http-interface service

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-3145. ----------------------------- Resolution: Rejected > Problem with HTTPS Failed to start the http-interface service > ------------------------------------------------------------- > > Key: WFLY-3145 > URL: https://issues.jboss.org/browse/WFLY-3145 > Project: WildFly > Issue Type: Support Request > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Jasbir Sahota > Assignee: Darran Lofthouse > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ] Tomaz Cerar moved UNDERTOW-203 to WFLY-3146: -------------------------------------------- Project: WildFly (was: Undertow) Key: WFLY-3146 (was: UNDERTOW-203) Affects Version/s: 8.0.0.Final (was: 1.0.0.Final) Component/s: Web (Undertow) (was: Core) Security: Public > Undertow Memory Leak for JAX-RS requests > ---------------------------------------- > > Key: WFLY-3146 > URL: https://issues.jboss.org/browse/WFLY-3146 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: Windows 7 Professional > JDK 1.7.0_21 > WildFly 8.0.0.Final > Reporter: Darren Jones > Assignee: Tomaz Cerar > Labels: MemoryLeak > Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png > > > After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log. > I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. > I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently). > I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem. > The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem. > I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3146: ------------------------------ Fix Version/s: 8.0.1.Final > Undertow Memory Leak for JAX-RS requests > ---------------------------------------- > > Key: WFLY-3146 > URL: https://issues.jboss.org/browse/WFLY-3146 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: Windows 7 Professional > JDK 1.7.0_21 > WildFly 8.0.0.Final > Reporter: Darren Jones > Assignee: Tomaz Cerar > Labels: MemoryLeak > Fix For: 8.0.1.Final > > Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png > > > After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log. > I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl. > I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently). > I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem. > The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem. > I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014