cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: Javaflow - major memory issue
Date Mon, 17 Mar 2008 19:15:37 GMT
Hm... not sure - javaflow instrumentation should be fairly  
lightweight and this might be a simple bug that turns out bad ...but  
frankly the huge amount of byte arrays doesn't ring a bell yet. I  
would need to look into the javaflow code.

As a general note though: Keep in mind that any continuation based  
webapp will have an ever increasing amount of memory unless you add  
some limitations and clean up code. Every connection means a new  
continuation (more or less) and some memory that needs to be kept on  
the server side. This can only remotely scale if you limit the total  
number of continuations ....similar like it is for sessions.

I would have a look into the continuation management infrastructure  
in cocoon and then start digging from there. I am wondering if  
limiting and expiring the continuations works well enough for you.  
(It was on my TODO to improve this part in cocoon - but I never got  
around to it and moved on)


On 17.03.2008, at 18:57, footh wrote:

> I've been trying to track down a memory problem with
> my Cocoon application for a long time now.  After a
> period of time, maybe a week or two, the application
> would die with an OutOfMemory error.  I've tried
> increasing the VM memory for the servlet container
> (using Tomcat 5.5) and switching to the JRockIt VM
> (delayed the OOM error, but still got it).  Nothing
> seemed to work.  Finally, I put my app through a
> series of tests to narrow down the culprit.
> After stripping layer upon layer of functionality, I
> finally discovered that Javaflow seems to be the
> problem.  I started with a bare-bones site and drilled
> it with a load tester.  The Tomcat memory use would
> remain stable.  I added more features and still no
> problem.  Then, I threw in the Javaflow, and the
> memory skyrocketed.  To make sure it wasn't something
> I was doing in the Javaflow, I created the simplest
> flow possible - a one-line "sendPage(uri)" call.
> Still the memory would blow up.
> As a final test, to make sure it wasn't something I
> was doing wrong, I ran the test on the sample Javaflow
> application that comes with Cocoon.  I used the
> calculator sample and just hit the first page.  Once
> again, the memory kept rising.  If I took that page
> off the test, there were no memory issues.
> My next step was to profile the memory use to see if I
> could find out where the memory was being allocated.
> It turns out that byte array data comprised the
> majority of the allocated memory. After running a test
> for 20 minutes or so, the Tomcat memory use was around
> 1GB with byte array data responsible for 82% of the
> total.
> Now, I realize that Javaflow is considered an unstable
> block.  I'm wondering if anyone else using this
> feature has had similar problems?  Any idea why this
> might be occurring with Javaflow?  Does flowscript
> have similar problems?
> I now need to reconsider the MVC architecture of my
> application which has been in production for several
> years.  I do a lot of stuff in the Javaflow.  I'm open
> to any suggestions!
> Regards,
> JF
> ______________________________________________________________________ 
> ______________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now.  http:// 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message