Hello,
I am going to try to report something that looks like a bug, or maybe multiple bugs, but right now I am so bewildered that I'm not sure it's not something stupid I am doing...
It all started when I was playing around with a lisp image and a Hunchentoot server, trying to get the hang of the library. When I added some things to *dispatch-table*, the server seemed to completely ignore me. (By the way, this is SBCL 0.9.18 on Linux behind mod_lisp). This was a bit frustrating. After poking the source for a bit, and making dispatch-request log the table it was getting, it turns out the server was using a value different from the current top-level *dispatch-table*. I assumed this was because it bound the result of calling *meta-dispatcher* to its own *dispatch-table* binding and apparently never left process-connections. I was about to write an email to this list about how this might not be the most desirable behaviour, but decided to test it one more time to make sure I wouldn't make a fool out of myself. And what do you know, after restarting my lisp process, starting a new server, and then messing with the *dispatch-table* it suddenly DID take my changes into account.
'What the hell', was what I thought. But it got even better. Refreshing the test page a few times showed that sometimes the changed *request-table* was used, but other times it would use the old one! I was about to dismiss Hunchentoot as a bug-ridden pile of weidness at this point.
But while I was writing this incoherent complaint I finally got it -- obviously process-request is called once for every THREAD, and since the server will keep a bunch of (4 on my setup) long-lived listening threads when communicating with mod_lisp, strange results will occur when each of these has a different dispatch-table -- the same client will see different behaviour from the page. I'd say this is not a desirable feature. A good fix would be to just call *meta-dispatcher* for every call to dispatch-request, so that you've always got the most recent dispatch-table and the programmer can fiddle with that variable from the REPL and immediately see the result. Unless someone goes and writes a really complicated and expensive meta-dispatcher this shouldn't be a problem. -- As far as I can see no other parts of the code refer to the dynamic *dispatch-table* var, so losing that binding shouldn't be a problem.
Let me know what you think.
Marijn Haverbeke
After experiencing some more problems, it seems my earlier explanation doesn't quite explain everything (though it is still valid). Some requests keep returning a completely empty page, and it turns out they do not even cause process-request to be called (or the loop in process-connection to go through a new iteration) -- so it might be an apache or mod_lisp problem with chunked or keep-alive connections. For your reading pleasure, I included the headers that apache sent me for a normal working request, and for a failed one...
Here's the working one (just returning a 3-character test page that said 'foo'):
Date Sun, 05 Nov 2006 09:42:38 GMT Server Apache/1.3.34 (Unix) (Gentoo) mod_lisp/2.42 Content-Length 3 Keep-Alive timeout=15, max=99 Connection Keep-Alive, Keep-Alive Content-Type text/html; charset=iso-8859-1
And here is the strange one (obtained by refreshing the very same url, note the lack of content-lenght -- both returned 200 OK):
Date Sun, 05 Nov 2006 09:42:35 GMT Server Apache/1.3.34 (Unix) (Gentoo) mod_lisp/2.42 Keep-Alive timeout=15, max=100 Connection Keep-Alive Transfer-Encoding chunked Content-Type text/plain
The problem only seems to occur when refreshing after waiting for a bit. When refreshing multiple times in a row, I always get the test page, but if I wait a few minutes and then refresh, the first try usually gives the empty page. Has anyone experienced something like this?
Regards, Marijn Haverbeke
On Sun, 5 Nov 2006 11:24:10 +0100, "Marijn Haverbeke" marijnh@gmail.com wrote:
Some requests keep returning a completely empty page, and it turns out they do not even cause process-request to be called (or the loop in process-connection to go through a new iteration) -- so it might be an apache or mod_lisp problem with chunked or keep-alive connections.
I think that's related to what I've described here:
http://common-lisp.net/pipermail/tbnl-devel/2006-October/000776.html
Unfortunately, I haven't yet found the time to fix it.
Cheers, Edi.
On Sun, 5 Nov 2006 11:24:10 +0100, "Marijn Haverbeke" marijnh@gmail.com wrote:
Some requests keep returning a completely empty page, and it turns out they do not even cause process-request to be called (or the loop in process-connection to go through a new iteration) -- so it might be an apache or mod_lisp problem with chunked or keep-alive connections.
It'd be nice if you could check whether these problems can be reproduced with 0.4.8 which I just released.
Thanks, Edi.
On Sat, 4 Nov 2006 21:48:24 +0100, "Marijn Haverbeke" marijnh@gmail.com wrote:
A good fix would be to just call *meta-dispatcher* for every call to dispatch-request, so that you've always got the most recent dispatch-table and the programmer can fiddle with that variable from the REPL and immediately see the result.
I've implemented that now in the new version. *META-DISPATCHER* came in pretty late in the game, and it wasn't intended to behave like it did until 0.4.5. Thanks for the report.
Cheers, Edi.
-
Edi Weitz -
Marijn Haverbeke