[
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
_______________________________________________
richfaces-issues mailing list
richfaces-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-issues
