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 its behavior... 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 <marius.dan...@gmail.com> 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 this behavior? > > 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
