I used to work at BEA, on WebLogic Server, which our customers
used to implement advanced (by the standards of the time)
web sites. All of them used this strategy, namely have a
basic HTTP server which would serve up the static content,
and pass through the interesting stuff to the WebLogic
Server process.

On the other hand, patching Lisp dynamically is not the only
way to be able to do hot upgrade. Here at ITA, we do not
patch running Lisp processes; it's just too fraught with
intermediate states that are hard to have Q/A'ed in
advance. Fortunately for us, we never run just one
server; we always use a cluster of servers with a load
balancer. So we do a "rolling upgrade", where we
bring down each server and then bring up the new
version of the server, one machine at a time. Or,
we bring down half, upgrade those, and then switch
to the other half.

The issue you then must cope with is sessions with
many requests, some of which go to old-version servers
and some to new. (Even with code patching, there
are such windows.) The latter approach (halves)
means you only have to worry about a session
first seeing one of many old-version servers, followed
by one or many new version servers, which can
make things easier to reason about, but then
you jhave to make sure that only 1/2 of your
servers can handle the load. If you have
a mostly-diurnal load, you can do this "at night",
if your load goes down to < .5 or whatever.

The point is that the new version can be Q/A'ed
intensively before you do this and you don't
have to worry about things like "I updated
function X, but some existing thread has
an existing stack frame with the PC at the
old version of X" and such.

-- Dan

Shaneal Manek wrote:

Generally, I deploy Hunchentoot behind a reverse proxy (just nginx for
single-instance deployments, or HAProxy and nginx for more complex
setups).

In either case, I let nginx serve the static content (no need to waste
the relatively expensive Lisp threads for serving images). In the
single-hunchentoot case, nginx can serve a static error page when the
hunchentoot instance is down. On the other hand, if you have a HAProxy
in front of multiple hunchentoots, then as long as one hunchentoot is
still up your site can continue with no downtime.

-Shaneal

On Fri, Sep 17, 2010 at 1:08 AM, Ron Garret <ron@flownet.com> wrote:

I'm getting close to deploying CCL on a production server, which has forced me to reluctantly reach the following conclusion: the fact that Lisp allows code to be changed dynamically means that unless you are extremely disciplined about how you patch the code in your server, it is not at all difficult to end up in a situation where the server needs to be restarted.  When that happens, it would be nice not to have the server machine go completely dead, but instead to respond with a nice "Server temporarily unavailable" page, and maybe even continue to serve static content.  So much as I'm a fan of Lisp and Hunchentoot, it seems to me that it's not a good idea to use that combination as the front-end of a production application, but instead to deploy the Lisp app as a FastCGI or the back-end of a proxy server setup.


_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel