[richfaces-issues] [JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final

[Marcel Šebek (JIRA)]

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

Marcel Šebek commented on RF-13250:
-----------------------------------

I'll try to answer your questions and describe the environment in which I see the leaking behavior. I also present some ideas what could be the cause.

The first thing is that 'old-version' atmosphere requests seem to be one way how to rapidly create a huge number (in our case 700 000) of AtomicBoolean instances. However, even without such requests, heap gets exhausted. I suspect a relation to RFPL-2345 - problem with dead sessions. With RF 4.3.3, heap gets filled with MessageData classes, even with org.atmosphere.cpr.CometSupport.maxInactiveActivity = 60000 and org.richfaces.push.session.maxInactiveInterval = 60000 parameters. However, with RF 4.3.5, heap gets filled with AtomicBoolean and char[] instances (and possibly other classes). The heap growth in both cases is similar and very non-linear. In the beginning, the number is 0 (for MessageData) or low (AtomicBoolean), but after some time, it starts to grow and the speed of grow increases. The application runs in non-critical production environment, so I cannot tell exactly what the clients are doing, but it seems that new dead session appears from time to time, and with each new dead session, the speed of memory exhaustion grows.

I'm not sure if I'd be able to isolate a small testcase. However, I have a heap dump which I can provide you. I don't want to provide it publicly (it may contant some sensitive information), but if you are interested, I can provide it to you privately. It is about 70M gzipped.

Finally, here are the answers for your questions.

Except a few libraries, I don't use any framework that should affect the result. The application is deployed on jboss 7.1 (latest build from git) with default jsf (mojarra 2.1.16) and native ssl on 64-bit linux. Extreme memory usage was not my invention, this name was chosen by original bug reporter. However, in my case, the application exhausts 0.75 GB heap with quite low but continuous load in scope of days (like 1-3 days). Low load means something like at most 5 clients simultaneously, but often just one client. The application is pushing just "null" messages (requests for re-rendering) with no useful data.

Any additional questions or suggestions what to try are welcome.
                
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
>                 Key: RF-13250
>                 URL: https://issues.jboss.org/browse/RF-13250
>             Project: RichFaces
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.3.4
>         Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
>            Reporter: Milo van der Zee
>            Assignee: Pavol Pitonak
>              Labels: memoryleak
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN  org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee

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