Well, no idea where it went :(
I'm uploading it again, but this time, I'll keep the heapdump files
separate since they're so big.
Waiting on drop.io now...
Thanks David!

On Jan 20, 10:40 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> On Wed, Jan 20, 2010 at 9:28 PM, mark chance <mark.cha...@gmail.com> wrote:
> > I did post the project to drop.io -http://drop.io/memtest.
>
> This drop is empty
>
>
>
>
>
> > On Wed, Jan 20, 2010 at 10:06 PM, David Pollak <
> > feeder.of.the.be...@gmail.com> wrote:
>
> >> On Wed, Jan 20, 2010 at 9:03 PM, Java1Guy <mark.cha...@gmail.com> wrote:
>
> >>> 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/z0xnxalmost 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!
>
> >> Without your actual code, there's little we can do.
>
> >>> Thanks in advance if you can have a look.
> >>> Mark
>
> >>> On Jan 18, 6:36 pm, Java1Guy <mark.cha...@gmail.com> wrote:
> >>> > Thanks for the response.  I have created a small project here:
> >>>http://drop.io/memtest(btw<http://drop.io/memtest%28btw> - 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 <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 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 lift...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/liftweb?hl=en.
>
> >> --
> >> Lift, the simply functional web frameworkhttp://liftweb.net
> >> Beginning Scalahttp://www.apress.com/book/view/1430219890
> >> Follow me:http://twitter.com/dpp
> >> Surf the harmonics
>
> >> --
> >> 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<liftweb%2bunsubscr...@googlegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/liftweb?hl=en.
>
> > --
> > 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<liftweb%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics
-- 
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.


Reply via email to