On Sep 16, 2010, at 11:17 PM, Hans Hübner wrote:
On Fri, Sep 17, 2010 at 08:08, 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.
If anyone disagrees with this analysis or has a better idea of how to deploy a Lisp app onto a production server I would love to hear it.
I favor this approach, too. Two years ago, I evaluated a few caching proxies and blogged about that (http://netzhansa.blogspot.com/2008/07/building-load-resilient-web-servers.ht...), you might find some interesting info in that post.
Thanks! For the moment I've settled on nginx for my front-end. So I have nginx running on port 80 forwarding requests to HT on some other port, but HT is still visible to the outside world, which seems like a bad thing security-wise. So my next question is: what is the best way to hide HT from the outside world? It seems the HT cannot serve a unix domain socket, and doesn't have IP-based access control built in. The only other solution would seem to be a firewall of some sort. Is that what people who use HT behind a front end generally do, or is there a more straightforward solution that I've overlooked?
Thanks, rg