[cc'ed to hunchentoot list]
I can confirm that ccl+hunchentoot on OS X 10.6 does not crash in ssl at a concurrency of 20 after 100,000 accesses (100% success in apache bench), whereas before it would crash after a few hundred.
However, SBCL 1.0.47 is still freezing, but not coredumping. It just times out on the apachebench side, and in slime both the *inferior-lisp* and *slime-repl* stop responding, and the CPU is pegged at 100%.
Using the toy server below, ab also causes an eventual freeze in sbcl but with CCL it mostly works, sometimes giving "SSL read failed - closing connection," which might be the fault of a premature close in the toy server (but I don't see how to do it otherwise, besides waiting until the client side closes). So this isn't a hunchentoot problem, most likely.
Given that CCL+hunchentoot works perfectly maybe the problem is inside SBCL, or maybe just the Mac version of SBCL if other platforms now work.
-John
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; toy https server ;; (eval-when (load eval compile) (require 'cl+ssl) (require 'bordeaux-threads) (require 'usocket))
(defparameter *keyfile* "./server.key") (defparameter *certfile* "./server.crt")
;; the bad server associates an SSL with the client inside a ;; worker thread, not inside the main thread (defun test-https-server (&key (port 8080) (cert *certfile*) (key *keyfile*)) (format t "~&SSL server listening on port ~d~%" port) (let ((server (usocket:socket-listen "127.0.0.1" port :backlog 100))) (loop (let* ((socket (usocket:socket-accept server)) (stream (usocket:socket-stream socket))) ;; launch response in a separate thread (bordeaux-threads:make-thread (lambda () ;; MAKE SSL HERE (let ((client (cl+ssl:make-ssl-server-stream stream :external-format '(:iso-8859-1 :eol-style :lf) :certificate cert :key key))) (unwind-protect (progn (format client "HTTP/1.0 200 OK~%") (format client "Server: SSL-TEST/1.1~%") (format client "Content-Type: text/plain~%") (terpri client) (format client "HELLO WORLD") (finish-output client)) ;; maybe apachebench is surprised by this close? (close client)))))))))
On Apr 3, 2011, at 3:26 AM, David Lichteblau wrote:
Hi,
Quoting David Lichteblau (david@lichteblau.com):
Quoting JTK (jetmonk@gmail.com):
[...]
I've appended a test case in which I think I may have found the source of hunchentoot's problems with ssl and concurrency.
Does the attached patch help?
I have committed an updated version of the patch to CL+SSL CVS now.
This version works now because it avoids use of buggy code in the bordeaux-threads backend for SBCL.
It passes ab testing on SBCL for me; I haven't rechecked other Lisps yet.
It's done from Lisp, and should really be done directly in C, similar to the th-lock.c sample code from OpenSSL. But let's first check whether it addresses the issue at all.
If anyone is interested in developing a C version, let's move to that ultimately. But I've decided to commit the Lisp version for now, because I think that correctness should come before performance in this case.
d.
cl-plus-ssl-devel mailing list cl-plus-ssl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel