Ok - i've left my Jetty server up and running with one page open... The good news is Jetty hasn't crapped out. It had 500MB of heap space used before a forced GC brought it down to 250MB. The heap dump is interesting: http://twitpic.com/z0xnx almost 25MB of Text objects used by the almost 80K displayList partial function objects in my CometActor. To me that sounds like a lot of functions!
Thanks in advance if you can have a look. Mark On Jan 18, 6:36 pm, Java1Guy <[email protected]> wrote: > Thanks for the response. I have created a small project > here:http://drop.io/memtest(btw - the zip file is so big because there are > 3 heap dumps - before that it was only 21k!) which i believe does > exhibit the problem. One comet actor page which gets updated every 20 > sec. via tick. > So to run this, I've built the war file and installed it into a Jetty > 6.1.22 installation. The file etc/memtest.xml goes in the jetty/ > contexts dir. > I open my Firefox browser to the only page it shows and just leave it > open for about four hours now - so the session should still be active, > FWIW. > An additional thing I'm noticing now is that despite not much else > happening in the app, the comet responses are taking just under 20 > sec. That seems huge. > There are two things I notice in the heap dumps: one is the large > number of xml.Text objects and their Strings, but second the 5800 > anonFuncs from the DatastreamActor which are being held by the S > $ProxtFuncHolder. I guess I could look up the API on that to see if > there's a way to controls itsbehavior... but there it is. > Thanks to anyone who takes a look at this, Mark > > The stdout: > ConsoleActor.lowPriority.Tick...>>>DataStreamActor.lowPriority: HostAddMsg > local > > ds count 4 > DataStreamActor.refreshStreams: now we know about stream count: 8 > INFO - Service request (GET) /memtest/comet_request/2021921075/ > p6s263zexmzz took 19513 Milliseconds > ConsoleActor.lowPriority.Tick...>>>DataStreamActor.lowPriority: HostAddMsg > local > > ds count 4 > DataStreamActor.refreshStreams: now we know about stream count: 8 > INFO - Service request (GET) /memtest/comet_request/11287578067/ > p6s263zexmzz took 19879 Milliseconds > ConsoleActor.lowPriority.Tick...>>>DataStreamActor.lowPriority: HostAddMsg > local > > ds count 4 > DataStreamActor.refreshStreams: now we know about stream count: 8 > INFO - Service request (GET) /memtest/comet_request/26532853932/ > p6s263zexmzz took 19868 Milliseconds > ConsoleActor.lowPriority.Tick...>>>DataStreamActor.lowPriority: HostAddMsg > local > > ds count 4 > DataStreamActor.refreshStreams: now we know about stream count: 8 > INFO - Service request (GET) /memtest/comet_request/11619469749/ > p6s263zexmzz took 19918 Milliseconds > > On Jan 16, 2:32 am, Marius <[email protected]> wrote: > > > Lift GC is likely keeping your functions to not expire but this is > > meant to be that way ... but this doesn't explain the large amount of > > functions. Can you post a minimalistic example of your app where you > > can reproduce thisbehavior? > > > Br's, > > Marius
-- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
