I just wrapped up switching our deployment of OpenStudy from Jetty to Glassfish. We learned a couple of things, but the most important one has to do with non-Jetty continuations support. The default web.xml that ships with Lift sample apps and such unfortunately does not include a required parameter, and also doesn't seem to be in the right schema, to enable Glassfish continuations. This caused us some serious head-scratching (and a lot of tied-up threads), since very few places deign it necessary to tell you that you need to have this setting in your web.xml.
To fix up your web.xml, you'll want to drop the doctype and change the web-app tag to:
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
This indicates you're using a more recent version of the schema, which lets you specify you want async (continuation) support. Part 2 is updating the filter declaration that sets up the Lift filter and servlet. You'll want to drop the description and display-name tags in the filter, since they no longer seem to be supported. Most critically, you need to add
<async-supported>true</async-supported>
This lets the container (Glassfish in our case) know that we want continuations for our app. If you're wondering why we're telling the container we support continuations rather than the container telling us that it supports them, I didn't find a proper explanation of that. All evidence points to this being a requirement if you want a Servlet 3.0 container to enable continuations support.
The other thing we quickly noticed is that Glassfish seems to use up more file descriptors than jetty does as it manages similar load. This seems like it may be related to the bug at http://java.net/jira/browse/GLASSFISH-11539, though that bug is marked fixed and we're running Glassfish 3.1.1, which is well past the 3.0.1 fix release. Nonetheless, we find the file descriptors leveling out around 34000, so as a stopgap we simply go to /etc/security/limits.conf and add:
@admin soft nofile 10000 @admin hard nofile 65535
This bumps up the file descriptor limit for processes run by users in the admin group, which our glassfish process user is.
So far things have been going well; we switched to Glassfish to avoid the NullPointerExceptions that jetty starts giving us under load (more at https://groups.google.com/d/topic/liftweb/MeJnuk-lH9A/discussion). So far, we haven't seen a similar instance with Glassfish, but it's early days yet. Fingers crossed!