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)
cheers
--
Torsten
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://
mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
