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

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12954787#comment-12954787 ] 

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