Re: [Lift] Re: Postmortem thoughts on a small production Lift site

2010-01-07 Thread David Pollak
On Sat, Jan 2, 2010 at 7:17 AM, Nathan Parry npa...@gmail.com wrote:

 Jetty seems to do questionable things with filehandles, opening
 multiple copies of the same template file and keeping them open too
 long.  Setting ulimit fixes the issue of Too many open files
 exceptions  failed requests, but it still seems like at most
 templates should need 1 access to check mtime.  Not really a lift
 issue, and not a deal breaker for us to switch to a different
 servlet
 container, but I am curious to see what the eventual solution for
 comet performance is.
 
If you can put together a reproducible case on this, we'll see what
 we
   can
do to close stuff that Jetty hands us more explicitly.
 
   I'm a total Lift and Scala newbie, but file-handle problems and last-
   modified checks remind me of this bug in Facelets:
 
  https://facelets.dev.java.net/issues/show_bug.cgi?id=278
 
  Thanks.  Looks like you found a defect and I've opened a defect.

 In case it is helpful, I think you can reproduce the behavior by doing
 something like this:

 1. mvn jetty:run
 2. Figure out the pid for jetty
 3. Figure out how many file descriptors are open after startup using:
  lsof | grep pid | wc -l
 4. Run a command like the one copied below to request the same file
 over and over.
 5. Run the lsof command line every few seconds to watch the FD count.

 Sample command to fetch a file in a loop:

 while (`true`); do curl -H If-Modified-Since: Tue, 29 Dec 2009
 20:02:16 UTC -H Cache-Control: max-age=0
 http://localhost:8080/classpath/blueprint/screen.css;
 done

 Running this locally the FD count seems to fluctuate between the
 baseline count and around 2x the baseline.  I would guess that might
 be based on how frequently the garbage collector is running and
 cleaning up any connections that were not explicitly closed.


Nathan,

Now don't take this the wrong way, but I could kiss you. ;-)

This is a great defect report... it's led to:
http://github.com/dpp/liftweb/issues/#issue/275

As well as a fix that I'm posting to review board right now.

Thanks,

David



 --
 Nathan

 --

 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: Postmortem thoughts on a small production Lift site

2009-12-31 Thread David Pollak
On Wed, Dec 30, 2009 at 4:01 PM, Nathan npa...@gmail.com wrote:


   Jetty seems to do questionable things with filehandles, opening
   multiple copies of the same template file and keeping them open too
   long.  Setting ulimit fixes the issue of Too many open files
   exceptions  failed requests, but it still seems like at most
   templates should need 1 access to check mtime.  Not really a lift
   issue, and not a deal breaker for us to switch to a different servlet
   container, but I am curious to see what the eventual solution for
   comet performance is.
 
  If you can put together a reproducible case on this, we'll see what we
 can
  do to close stuff that Jetty hands us more explicitly.

 I'm a total Lift and Scala newbie, but file-handle problems and last-
 modified checks remind me of this bug in Facelets:

 https://facelets.dev.java.net/issues/show_bug.cgi?id=278


Thanks.  Looks like you found a defect and I've opened a defect.


 It looks like ResourceServer.scala may be hitting the same problem
 between the  findResourceInClasspath and calcLastModified methods, but
 again - total newbie - so take that with a boulder sized grain of
 salt.

 --
 Nathan

 --

 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.