You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Jonathan S Fisher (JIRA)" <ji...@apache.org> on 2019/01/08 16:10:00 UTC

[jira] [Updated] (TOMEE-2449) Rate of JMS Messages consumed by TomEE drops significantly over time

     [ https://issues.apache.org/jira/browse/TOMEE-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan S Fisher updated TOMEE-2449:
-------------------------------------
    Attachment: jstack.txt
                jstack5.txt
                jstack4.txt
                jstack3.txt
                jstack2.txt

> Rate of JMS Messages consumed by TomEE drops significantly over time
> --------------------------------------------------------------------
>
>                 Key: TOMEE-2449
>                 URL: https://issues.apache.org/jira/browse/TOMEE-2449
>             Project: TomEE
>          Issue Type: Bug
>          Components: TomEE Core Server
>    Affects Versions: 7.0.5
>            Reporter: Jonathan S Fisher
>            Priority: Major
>         Attachments: jstack.txt, jstack2.txt, jstack3.txt, jstack4.txt, jstack5.txt
>
>
> Hey guys, 
> We're noticing a pretty strange issue processing a large number of JMS 
> messages. After about 20k messages, messages consumed per second drops off 
> and there's heavy GC activity (smells like a memory leak). What interesting 
> though is the server continues to run and doesn't OutOfMemoryError. A simple 
> restart of TomEE (but not the broker) temporarily fixes the problem. We're 
> using an external broker, not the internal one 
> What's interesting, is that Jonathan Gallimore and I were talking about a 
> similar issue with Websockets. We noticed that eventually the servers will 
> exhibit the same behavior once enough websockets are opened and closed. This 
> issue occurs infrequently enough because we might handle 20,000 websockets 
> over the course of a few days, but we can process 20,000 JMS messages in a 
> few mins. 
> I have a heap dump from the issue and several jstacks. I'll be honest, I'm 
> not sure where to start. In the past I've solved memory leaks by careful 
> code audits. Our codebase happens to be mostly stateless, with everything 
> else being managed by CDI scopes (ApplicationScoped and TransactionScoped). 
> What's a good way to get started? 
> http://tomee-openejb.979440.n4.nabble.com/Performance-issue-with-JMS-on-Tomee-7-0-5-td4687296.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)