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: ----------------------------------- 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

10 years, 9 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

10 years, 9 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

10 years, 9 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

10 years, 9 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: ------------------------------ Priority: Critical (was: Major) > 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2713) ViewExpiredException in Chrome on WildFly 8.0.0.CR1

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2713?page=com.atlassian.jira.plugin.... ] Farah Juma reassigned WFLY-2713: -------------------------------- Assignee: Farah Juma > ViewExpiredException in Chrome on WildFly 8.0.0.CR1 > --------------------------------------------------- > > Key: WFLY-2713 > URL: https://issues.jboss.org/browse/WFLY-2713 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 8.0.0.CR1 > Environment: WildFly 8.0.0.CR1 > Chrome 31.0.1650.63 @ Fedora 20 x86_64 > Reporter: Pavol Pitonak > Assignee: Farah Juma > Attachments: reproducer.zip > > > # unzip attached reproducer > # mvn clean package > # deploy reproducer.war to WildFly > # open http://localhost:8080/reproducer/ > # type something to the input > result: > * in Chrome, a popup with error is displayed > * server console contains stack trace: > {code} > 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored. > {code} > * works fine in Firefox 26 > * works fine in WildFly 8.0.0.Beta1 -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-2594: ---------------------------------- My patch for JAVASERVERFACES-3189 has now been committed to the Mojarra 2.2.x branch and will be included in the 2.2.7 release. > Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps > ----------------------------------------------------------------------------------------------- > > Key: WFLY-2594 > URL: https://issues.jboss.org/browse/WFLY-2594 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JSF > Environment: WildFly Beta2-SNAPSHOT from 2013-12-02 > Reporter: Tomas Remes > Assignee: Farah Juma > > When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log: > {noformat} > SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI? > SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI? > {noformat} > I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?). -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1750) RELAY2 : Address formats are not relayed.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1750?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1750: -------------------------------- {{JChannel.setAddressGenerator()}} is very simple now: it doesn't have to take into account already installed address generators, as all address generators are now stored in a list. When the address is generated, if no or only 1 generators are installed, we use it to generate the address. If we have multiple address generators, we let all of them create an address. If one of them doesn't create an {{ExtendedUUID}}, we discard it. Then the first {{ExtendedUUID}} is taken and the data and flags of all other addresses is added to the first address, which will be returned. > RELAY2 : Address formats are not relayed. > ----------------------------------------- > > Key: JGRP-1750 > URL: https://issues.jboss.org/browse/JGRP-1750 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4.1 > Reporter: Karim AMMOUS > Assignee: Bela Ban > Fix For: 3.5 > > > When defining a relay channel, we haven't the ability to set an AddressGenrator. Indeed, the Relayer uses its own AddressGenerator providing addresses of type SiteUUID. > This is particularly embarrassing in the following case: when we define a customized address format (like CanBeSiteMasterTopology or TopologyUUID) for members of two Sites A and B, address format is lost by crossing relay. Address type of messages sent by A to B are seen as SiteUUID at B side. > Suggestions: > - Making address format "relayable" ? > - Using the same (or an extended format) AddressGenerator of site Channel -- 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

10 years, 9 months

1
0
0 / 0

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

by Jasbir Sahota (JIRA)

[ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.... ] Jasbir Sahota commented on WFLY-3145: ------------------------------------- Darran, many thanks for your reply and apologies for raising this in the wrong place. Will look into the Port 9990 conflict and close this here. > 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

10 years, 9 months

1
0
0 / 0

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3145?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3145: ---------------------------------------- >From the details so far this appears to be something you should be discussing in the forums not in Jira, Jira is for the recording of bugs and feature requests - the forums are for discussing problems you may be experiencing. Note: From the stack trace you show this is the management http server which is having a problem which would most likely mean it is port 9990 that is having a conflict not 8080 > 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

10 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 March 2014