hunchentoot stress test fails in interesting ways

[Nikodemus Siivola]

The following test-case provokes all sorts of badness. Some of it may originate in Hunchentoot
or various libraries, but it should none the less be diagnoses, as odds good are that something goes
wrong on the SBCL side of the fence as well.

(require :asdf)
(require :drakma)
(require :hunchentoot)

(defun stress-threads ()
  (declare (optimize (speed 3)))
  (hunchentoot:start-server :port 4242)
  (let ((dribble-lock (sb-thread:make-mutex :name "dribble")))
    (loop for i from 2 upto 4
          collect (let ((n (character (princ-to-string i)))
                        (url (format nil "http://localhost:4242")))
                    (sb-thread:make-thread
                     (lambda ()
                       (dotimes (i 10000000)
                         (when (zerop (mod i 50))
                           (sb-thread:with-mutex (dribble-lock)
                             (write-char n *terminal-io*)
                             (force-output *terminal-io*)))
                         (handler-case
                             (drakma:http-request url)
                           (end-of-file ()
                             t)
                           (sb-bsd-sockets:socket-error ()
                             t))))
                     :name n)))))

[Gábor Melis (melisgl)]

Recent hunchentoot is started slightly differently and I got a lot of "connection reset by peer" simple-stream-errors so I had to handle that condition:

(defun stress-threads ()
  (declare (optimize (speed 3)))
  (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242))
  (let ((dribble-lock (sb-thread:make-mutex :name "dribble")))
    (loop for i from 2 upto 4
          collect (let ((n (character (princ-to-string i)))
                        (url (format nil "http://localhost:4242")))
                    (sb-thread:make-thread
                     (lambda ()
                       (dotimes (i 10000000)
                         (when (zerop (mod i 50))
                           (sb-thread:with-mutex (dribble-lock)
                             (write-char n *terminal-io*)
                             (force-output *terminal-io*)))
                         (handler-case
                             (drakma:http-request url)
                           (sb-int:simple-stream-error ()
                             t)
                           (end-of-file ()
                             t)
                           (sb-bsd-sockets:socket-error ()
                             t))))
                     :name n)))))

On a two cpu x86/linux box I left it running on sbcl 1.0.28 for a couple of hours without experiencing any sort of badness. Versions of major components:
hunchentoot: 1.0.0
drakma: 1.0.0
usocket: 0.4.1
flexi-streams: 0.9.1
chunga: 0.2.3
cl+ssl: 2008-11-04

[Gábor Melis (melisgl)]

Since to my knowledge nobody else complained for at least half a year I'm closing this.

[Tobias C. Rittweiler (tcr)]

I wonder whether this shouldn't become "Invalid" rather?

[Gábor Melis (melisgl)]

I wondered the same. What makes me lean towards fixed is that at some point this bug report was certainly valid. Now it is not and we don't know what fixed it.

[Tobias C. Rittweiler (tcr)]

Wasn't Hunchentoot considerably rewritten in between?
Have you actually tried a version of it from end of 2008?

I was thinking of "Invalid" because I thought the "fix" may have
been due to major changes in Hunchentoot.

[Gábor Melis (melisgl)]

Changing status to invalid, although "gone stale" would be better.