Re: [Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-21 Thread David Pollak
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.


The project does not build:

  Path to dependency:
  1) com.peopledesigned:memtest:war:1.0-SNAPSHOT
  2) org.jfree:jcommon:jar:1.0.16


Looking at your code, each of the functions created/passed as part of the
SHtml.ajaxCall(), etc. calls are retained for the duration of the session.
Lift garbage collects these references if there's not seen on a page for 10
minutes.  However, if the GUIDs are created within the scope of a
CometActor, the function is retained until the CometActor is released (in
your case, for the length of the session).

There are a couple of ways to deal with this:

   - Create a single SHtml.ajaxCall instance as part of the CometActor
   (rather than on each partialUpdate).
   - Use the CometActor's built-in JSON handler to send a message from the
   browser to the server.  See CometActor.handleJson()

The latter is the best bet for handling rich interactions with the
CometActor from the client without creating lots and lots of functions.




 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/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!


 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.






 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 

[Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-21 Thread Java1Guy
David:
Thanks for having a look.  Curious about that missing dependency - i
guess it's in the pom.xml but not really used.

Anyway, I'll digest your recommendations and have a go at it.  The
scenario I have running right now is one page open (and therefore its
session) for a very long time.  While that's not a terribly realistic
scenario, it probably is an indicator of why it did run out of memory
and lock up in the real deployment.

Cheers, Mark

ps - did fix the project in drop.io.  I guess in reality the pom
should make sure to point to a repository where all the dependencies
exist, vs. just having installed locally.

On Jan 21, 10:38 am, 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.

 The project does not build:

   Path to dependency:
       1) com.peopledesigned:memtest:war:1.0-SNAPSHOT
       2) org.jfree:jcommon:jar:1.0.16

 Looking at your code, each of the functions created/passed as part of the
 SHtml.ajaxCall(), etc. calls are retained for the duration of the session.
 Lift garbage collects these references if there's not seen on a page for 10
 minutes.  However, if the GUIDs are created within the scope of a
 CometActor, the function is retained until the CometActor is released (in
 your case, for the length of the session).

 There are a couple of ways to deal with this:

    - Create a single SHtml.ajaxCall instance as part of the CometActor
    (rather than on each partialUpdate).
    - Use the CometActor's built-in JSON handler to send a message from the
    browser to the server.  See CometActor.handleJson()

 The latter is the best bet for handling rich interactions with the
 CometActor from the client without creating lots and lots of functions.


-- 
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.



[Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-20 Thread Java1Guy
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 mark.cha...@gmail.com 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 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.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-20 Thread David Pollak
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/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!


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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.






-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://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.



Re: [Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-20 Thread mark chance
I did post the project to drop.io - http://drop.io/memtest.


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/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!


 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.






 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://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.comliftweb%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.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-20 Thread David Pollak
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/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!


 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.






 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://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.comliftweb%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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
-- 

You received this 

[Lift] Re: Memory behavior in Jetty with CometActor - 25MB of scala.xml.Text!

2010-01-20 Thread Java1Guy
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(btwhttp://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.comliftweb%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.comliftweb%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