[hunchentoot-devel] hunchentoot and sb-ext:run-process experiences

Cyrus Harmon ch-tbnl at bobobeach.com
Thu Jun 11 05:41:31 UTC 2009


I've finally been motivated to do some maintenance on my web server  
and one of the things that has been bothering me for a long time has  
been some relatively serious instability problems with my production- 
ish hunchentoot server. I had been using a pre-1.0-but-post-last- 
release development snapshot and the main problem has been that after  
a week or so of use my hunchentoot instance would fairly reliably  
crash, although it wasn't clear exactly when it would crash. After I  
time begin to suspect that the main culprit use my use of sb-ext:run- 
program in my hunchentoot-cgi stuff. hunchentoot-cgi is a hunchentoot  
handler and associated glue to allow hunchentoot to call CGI programs  
written in, say, perl that I wrote primarily so I could put gitweb  
behind my hunchentoot server directly, instead using apache or  
lighttpd or whatever as a front-end to hunchentoot. Like most of my  
code, it is, at least in the beginning, SBCL specific and it uses sb- 
ext:run-program to launch the CGI script. So far, so good, but then I  
kept getting these crashes and it was driving me crazy.

Today I figured out that if I manually close the process, bad things  
happen a lot less frequently. This may seem obvious, but if after  
calling sb-ext:run-program I make an unwind-protect block and call sb- 
ext:process-wait and sb-ext:process-close, things get a lot better. I  
guess I should have suspected that something like this might have been  
the problem when I had errors such as:

[2009-06-10 20:37:03 [ERROR]] The value 1026 is not of type (MOD 1025).

in the logs, but I never put two and two together.

I can now bang on the server (calling CGIs) pretty hard and it  
generally responds well and hasn't crashed on me yet, although it  
hasn't been all that long. Nevertheless, a thousand or so hits from ab  
with the old way of doing things would bring down the server and I can  
for multiple thousands of hits on the new server with no noticeable  
problems.

I should caveat this by saying that I was seeing the occasional  
sockout-timeout, writing to a closed pipe, etc... problems with the  
1.0 (or thereabouts, whatever is in luis' repo) release, but upgrading  
to the latest dev version from the ediware svn repo seems to have  
fixed even those problems. Well, I still occasionally see errors like  
the following:

[2009-06-10 22:35:25 [ERROR]] Couldn't write to #<SB-SYS:FD-STREAM for  
"a socket" {5A0E5BA1}>: Broken pipe
[2009-06-10 22:35:26 [ERROR]] Error while processing connection:  
Couldn't write to #<SB-SYS:FD-STREAM for "a socket" {5A0E5BA1}>:  
Broken pipe

but they neither bring down the server nor cause ab to freak out with  
a connection reset by peer error, which is nice.

So I guess this all a long-winded way of saying:

1) If you're going to be using sb-ext:run-program :wait nil and  
reading from the process' stream, make sure you sb-ext:process-close  
the process.

2) thanks to the hunchentoot team for the 1.0 release and beyond!

While I'm at it, I'll put in another plug for my hunchentoot add-on  
modules, hunchentoot-cgi, hunchentoot-auth and hunchentoot-vhost, for  
calling CGIs from hunchentoot, for providing (more of) an  
infrastructure for user authentication, and for trivially handling  
multiple "virtual hosts" with hunchentoot, respectively:

http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-cgi.git
http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-auth.git
http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-vhost.git

All of which should now be working with hunchentoot 1.0 (and beyond).

Thanks again to Edi and Hans.

Cyrus





More information about the Tbnl-devel mailing list