From sebyte at smolny.plus.com Tue Feb 1 06:09:43 2011 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Tue, 01 Feb 2011 06:09:43 +0000 Subject: [hunchentoot-devel] Hunchentoot sessions References: Message-ID: <62t4p9p4.fsf@chimera.gnukahvesi.net> Hi Hans, Thanks for your quick reply. Sorry for my slow one. Quoth Hans H?bner : > Am I right in understanding that you are calling REMOVE-SESSION and > START-SESSION in one request, and that you're not seeing correct > results? Or rather, are you calling REMOVE-SESSION and then REDIRECT > and don't see the results? Is there a reason why you (seem to) need a > fresh session rather than just changing the session variable that your > application uses? As I said, I wrote these notes about six months ago and I no longer remember the precise steps I took that lead me to draw the conclusions I did. > It would be helpful if you could formulate your problem in terms of a > bug report and include steps to reproduce the behavior. Certainly. I will happily do this, but it'll have to wait for some time. More important deadlines loom. Regards, Sebastian -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap From martynov.alexey at gmail.com Tue Feb 1 07:00:17 2011 From: martynov.alexey at gmail.com (Alexey Martynov) Date: Tue, 1 Feb 2011 10:00:17 +0300 Subject: [hunchentoot-devel] send-headers and SBCL's run-program Message-ID: Hi I have following problem: I need to run external script which outputs image to standard output. To deliver it to client I use hunchentoot:send-headers call. Following code works fine: (setf (hunchentoot:content-type*) "image/png") (setf (hunchentoot:header-out "Pragma") "no-cache") (let ((out (hunchentoot:send-headers))) (let ((process (sb-ext:run-program "generate-image" '() :output :stream :wait nil :error nil))) (let ((file (sb-ext:process-output process))) (loop with buf = (make-array 10240 :element-type '(unsigned-byte 8)) for pos = (read-sequence buf file) until (zerop pos) do (write-sequence buf out :end pos))))) But when I want to use stream from "send-headers" as stream for standard output for external program then status line and headers received after image content. I use following code: (setf (hunchentoot:content-type*) "image/png") (setf (hunchentoot:header-out "Pragma") "no-cache") (let ((out (hunchentoot:send-headers))) (let ((process (sb-ext:run-program "generate-image" '() :output out :wait nil :error nil))) (sb-ext:process-wait process))) So I have following question: is it possible to use stream received from "send-headers" as output stream for spawned process or not? If yes how correct code must look? Thanks in advance -- Alexey Martynov From archimag at gmail.com Tue Feb 1 07:09:02 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Tue, 1 Feb 2011 10:09:02 +0300 Subject: [hunchentoot-devel] send-headers and SBCL's run-program In-Reply-To: References: Message-ID: > I need to run external script which outputs > image to standard output. http://cyrusharmon.org/projects?project=hunchentoot-cgi Andrey From edi at weitz.de Tue Feb 1 17:43:56 2011 From: edi at weitz.de (Edi Weitz) Date: Tue, 1 Feb 2011 18:43:56 +0100 Subject: [hunchentoot-devel] send-headers and SBCL's run-program In-Reply-To: References: Message-ID: On Tue, Feb 1, 2011 at 8:00 AM, Alexey Martynov wrote: > So I have following question: is it possible to use stream received > from "send-headers" as output stream for spawned process or not? I'd say this depends on how sb-ext:run-program works. If it can accept a Lisp stream to send its output to, you should be fine. >From it looks like what you're doing is correct. This doesn't work for you? Maybe SBCL expects another stream type? From edi at weitz.de Tue Feb 1 17:47:52 2011 From: edi at weitz.de (Edi Weitz) Date: Tue, 1 Feb 2011 18:47:52 +0100 Subject: [hunchentoot-devel] Hunchentoot sessions In-Reply-To: References: Message-ID: The general question is: Why would you want to delete a session? The idea is that you set, modify, or remove values in the session using (setf session-value) or delete-session-value. I think this should give you enough flexibility to do whatever you want, as you can use arbitrary Lisp values and as many as you want. Edi. From iperminov at dwavesys.com Sat Feb 5 00:20:11 2011 From: iperminov at dwavesys.com (Ilya Perminov) Date: Fri, 04 Feb 2011 16:20:11 -0800 Subject: [hunchentoot-devel] Truncated responses from Hunchentoot Message-ID: Hi, I use Hunchentoot 1.1.1 with SBCL 1.0.43 under Linux. Under load Hunchentoot sometimes sends incomplete responses to the clients. I tried to debug the problem and Hunchentoot seems to close the output stream without waiting for the buffered data to be sent. In "connection per request" mode (i.e. keep-alive is disabled), immediately after writing a response to the output stream function PROCESS-CONNECTION makes the following calls: (force-output *hunchentoot-stream*) (close *hunchentoot-stream* :abort t) As FORCE-OUTPUT does not wait till all the buffered output is sent, CLOSE (with :ABORT T) is sometimes called before the buffers are empty and discards a part of the output. I wrote a small test to demonstrate the problem. The server and the client has to run on different computers. Regards, Ilya ;; ======================== Server ============== (require :hunchentoot) (defparameter *port* 8085) (defparameter *data-len* 50000) (hunchentoot:start (make-instance 'hunchentoot:acceptor :port *port*)) (hunchentoot:define-easy-handler (test-handler :uri "/test") () (make-string *data-len* :initial-element #\a)) ;; =============== Client =================== (require :drakma) (defparameter *host* "lich") (defparameter *port* 8085) (defparameter *data-len* 50000) (defun test () (multiple-value-bind (res status-code) (drakma:http-request (format nil "http://~a:~a/test" *host* *port*)) (assert (= status-code 200)) (assert (= (length res) *data-len*)) (assert (equalp res (make-string *data-len* :initial-element #\a))))) (dotimes (n 10) (sb-thread:make-thread (lambda () (dotimes (i 1000) (test))))) From hans.huebner at gmail.com Sat Feb 5 07:47:34 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 5 Feb 2011 08:47:34 +0100 Subject: [hunchentoot-devel] Truncated responses from Hunchentoot In-Reply-To: References: Message-ID: Hi Ilya, thank you for the bug report. On Sat, Feb 5, 2011 at 1:20 AM, Ilya Perminov wrote: > I use Hunchentoot 1.1.1 with SBCL 1.0.43 under Linux. Under load > Hunchentoot sometimes sends incomplete responses to the clients. I tried > to debug the problem and Hunchentoot seems to close the output > stream without waiting for the buffered data to be sent. > In "connection per request" mode (i.e. keep-alive is disabled), > immediately after writing a response to the output stream > function PROCESS-CONNECTION makes the following calls: > (force-output *hunchentoot-stream*) > (close *hunchentoot-stream* :abort t) I think that the right fix is to call FINISH-OUTPUT in PROCESS-CONNECTION instead. I have committed http://bknr.net/trac/changeset/4641, can you please try that patch and let us know if it helps? Thanks, Hans From iperminov at dwavesys.com Sat Feb 5 08:10:15 2011 From: iperminov at dwavesys.com (Ilya Perminov) Date: Sat, 05 Feb 2011 00:10:15 -0800 Subject: [hunchentoot-devel] Truncated responses from Hunchentoot In-Reply-To: ("Hans =?iso-8859-1?Q?H=FCbner=22's?= message of "Sat\, 5 Feb 2011 08\:47\:34 +0100") References: Message-ID: <87sjw2kil4.fsf@dwavesys.com> Thanks Hans, your patch solved the problem. Regards, Ilya From snmsts at gmail.com Mon Feb 7 06:33:29 2011 From: snmsts at gmail.com (SANO Masatoshi) Date: Mon, 7 Feb 2011 15:33:29 +0900 Subject: [hunchentoot-devel] [Patch] support range request in handle-static-file Message-ID: Hi, I tried to use hunchentoot for providing video to chrome. And find out it is not supported to return 206 in handle-static-file function. So I created patch for support it. I know it is not completed RFC but It looks working. -- ????(SANO Masatoshi) snmsts at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot.206.patch Type: application/octet-stream Size: 2452 bytes Desc: not available URL: From mario.maio at libero.it Mon Feb 7 14:43:31 2011 From: mario.maio at libero.it (Mario Maio) Date: Mon, 07 Feb 2011 15:43:31 +0100 Subject: [hunchentoot-devel] Fwd: can't install hunchentoot, because of usocket Message-ID: <4D500513.9010202@libero.it> I was trying to follow the steps explained in http://www.adampetersen.se/articles/lispweb.htm, but I can't install hunchentoot using quicklisp in my Windows 7 / Emacs / CLISP environment, because usocket fails to install, this is what happens in Emacs (the following refers to isolated 'usocket' installation but the same happens when I try to install hunchentoot): CL-USER> (ql:quickload "usocket") ; Fetching # ; 78.15KB ================================================== 80,026 bytes in 1.29 seconds (60.67KB/sec) ; Fetching # ; 111.77KB ================================================== 114,451 bytes in 0.29 seconds (388.06KB/sec) To load "usocket": Install 1 Quicklisp release: usocket ; Fetching # ; 54.77KB ================================================== 56,082 bytes in 0.35 seconds (157.37KB/sec) ; Loading "usocket" [package usocket].. *** - Program stack overflow. RESET ;; swank:close-connection: NIL [2]> I might have done any stupid mistake, I'm a CLISP/Emacs newbie. Any help is appreciated. Thanks in advance. From xach at xach.com Mon Feb 7 15:11:01 2011 From: xach at xach.com (Zach Beane) Date: Mon, 07 Feb 2011 10:11:01 -0500 Subject: [hunchentoot-devel] Fwd: can't install hunchentoot, because of usocket In-Reply-To: <4D500513.9010202@libero.it> (Mario Maio's message of "Mon, 07 Feb 2011 15:43:31 +0100") References: <4D500513.9010202@libero.it> Message-ID: <874o8fdgmy.fsf@hangup.portland.xach.com> Mario Maio writes: > I was trying to follow the steps explained in > > http://www.adampetersen.se/articles/lispweb.htm, but I can't install > hunchentoot using quicklisp in my Windows 7 / Emacs / CLISP environment, > because usocket fails to install, this is what happens in Emacs (the > following refers to isolated 'usocket' installation but the same happens > when I try to install hunchentoot): [snip] You'll have better luck with a different CL implementation. Clozure seems to work nicely, and LispWorks would certainly do the trick too. Zach From hans.huebner at gmail.com Mon Feb 7 15:16:34 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 7 Feb 2011 16:16:34 +0100 Subject: [hunchentoot-devel] [Patch] support range request in handle-static-file In-Reply-To: References: Message-ID: SANO, thank you for your patch. I will incorporate the functionality in the upcoming Hunchentoot release. Unfortunately, I have already made enough changes to make your patch not work anymore, so it would be great if you could test the new release once I've announce it in this list to see whether the partial response stuff works with your video client. I'm expecting to commit a big bunch of changes in the coming two weeks. Thanks again, Hans 2011/2/7 SANO Masatoshi : > Hi, > > I tried to use hunchentoot for providing video to chrome. > And find out it is not supported to return 206 in handle-static-file function. > So I created patch for support it. > > I know it is not completed RFC but It looks working. > > > -- > ????(SANO Masatoshi) > snmsts at gmail.com > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From hans.huebner at gmail.com Mon Feb 7 23:50:51 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 8 Feb 2011 00:50:51 +0100 Subject: [hunchentoot-devel] Incompatible Hunchentoot changes Message-ID: Hi, I have committed a fairly large and incompatible change to Hunchentoot: http://bknr.net/trac/changeset/4643 The biggest incompatibility for most users is that the acceptor class for the easy handler system is now called EASY-ACCEPTOR. There are other changes relating to how Hunchentoot invokes hooks for logging, error handling and more. Most of the changes are already documented, but please complain if I left something out. If you could give it a spin and report anything that you find worth reporting, I'd be grateful! Thanks, Hans From binghe.lisp at gmail.com Tue Feb 8 01:30:43 2011 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Tue, 8 Feb 2011 09:30:43 +0800 Subject: [hunchentoot-devel] Fwd: can't install hunchentoot, because of usocket In-Reply-To: <874o8fdgmy.fsf@hangup.portland.xach.com> References: <4D500513.9010202@libero.it> <874o8fdgmy.fsf@hangup.portland.xach.com> Message-ID: I can't imagine any code in USOCKET's CLISP backend could cause such stack overflow (by infinite loop?!). I used think this is a ASDF + CLISP issue, unless any CLISP familiar lisper could figure out what code was running when stack overflow happened. --binghe On Mon, Feb 7, 2011 at 11:11 PM, Zach Beane wrote: > Mario Maio writes: > >> I was trying to follow the steps explained in >> >> http://www.adampetersen.se/articles/lispweb.htm, but I can't install >> hunchentoot using quicklisp in my Windows 7 / Emacs / CLISP environment, >> because usocket fails to install, this is what happens in Emacs (the >> following refers to isolated 'usocket' installation but the same happens >> when I try to install hunchentoot): > [snip] > > You'll have better luck with a different CL implementation. Clozure > seems to work nicely, and LispWorks would certainly do the trick too. > > Zach > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- Chun Tian (binghe) From snmsts at gmail.com Tue Feb 8 02:18:58 2011 From: snmsts at gmail.com (SANO Masatoshi) Date: Tue, 8 Feb 2011 11:18:58 +0900 Subject: [hunchentoot-devel] [Patch] support range request in handle-static-file In-Reply-To: References: Message-ID: Hi Hans I read committed code that looks good enough for me. I'll try it. Thank you very much. 2011/2/8 Hans H?bner : > SANO, > > thank you for your patch. ?I will incorporate the functionality in the > upcoming Hunchentoot release. ?Unfortunately, I have already made > enough changes to make your patch not work anymore, so it would be > great if you could test the new release once I've announce it in this > list to see whether the partial response stuff works with your video > client. ?I'm expecting to commit a big bunch of changes in the coming > two weeks. > > Thanks again, > Hans > > 2011/2/7 SANO Masatoshi : >> Hi, >> >> I tried to use hunchentoot for providing video to chrome. >> And find out it is not supported to return 206 in handle-static-file function. >> So I created patch for support it. >> >> I know it is not completed RFC but It looks working. >> >> >> -- >> ????(SANO Masatoshi) >> snmsts at gmail.com >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- ????(SANO Masatoshi) snmsts at gmail.com From dlw at itasoftware.com Tue Feb 8 22:25:39 2011 From: dlw at itasoftware.com (Daniel Weinreb) Date: Tue, 08 Feb 2011 17:25:39 -0500 Subject: [hunchentoot-devel] Proposed Hunchentoot patch to add soft shutdown feature Message-ID: <4D51C2E3.4070105@itasoftware.com> The following patch adds a feature to Hunchentoot called "soft shutdown" or "soft stop". It provides a way to shut down the Hunchentoot server, but only after any pending requests have been processed (including sending back the reply). Is this OK to add to the official Hunchentoot? Thanks. -- Dan ------------------------------------------------------------------------ *** /ita/hunchentoot/hunchentoot-1.1.1/acceptor.lisp 2010-08-22 15:33:01.000000000 -0400 --- /ita/work/four/qres/lisp/libs/hunchentoot/acceptor.lisp 2011-02-07 15:41:35.000000000 -0500 *************** *** 122,127 **** --- 125,143 ---- :accessor acceptor-shutdown-p :documentation "A flag that makes the acceptor shutdown itself when set to something other than NIL.") + (requests-in-progress :initform 0 + :accessor accessor-requests-in-progress + :documentation "The number of + requests currently in progress.") + (shutdown-queue :initform (make-condition-variable) + :accessor acceptor-shutdown-queue + :documentation "A condition variable + used with soft shutdown, signaled when all requests + have been processed.") + (shutdown-lock :initform (make-lock "hunchentoot-acceptor-shutdown") + :accessor acceptor-shutdown-lock + :documentation "The lock protecting the shutdown-queue + condition variable and the requests-in-progress counter.") (access-logger :initarg :access-logger :accessor acceptor-access-logger :documentation "Designator for a function to call to *************** *** 183,191 **** (:documentation "Starts the ACCEPTOR so that it begins accepting connections. Returns the acceptor.")) ! (defgeneric stop (acceptor) (:documentation "Stops the ACCEPTOR so that it no longer accepts ! requests.")) (defgeneric start-listening (acceptor) (:documentation "Sets up a listen socket for the given ACCEPTOR and --- 199,209 ---- (:documentation "Starts the ACCEPTOR so that it begins accepting connections. Returns the acceptor.")) ! (defgeneric stop (acceptor &key soft) (:documentation "Stops the ACCEPTOR so that it no longer accepts ! requests. If SOFT is true, and there are any requests in progress, ! wait until all requests are fully processed, but meanwhile do ! not accept new requests.")) (defgeneric start-listening (acceptor) (:documentation "Sets up a listen socket for the given ACCEPTOR and *************** *** 251,262 **** (execute-acceptor taskmaster)) acceptor) ! (defmethod stop ((acceptor acceptor)) (setf (acceptor-shutdown-p acceptor) t) (shutdown (acceptor-taskmaster acceptor)) ! #-:lispworks ! (usocket:socket-close (acceptor-listen-socket acceptor)) ! #-:lispworks (setf (acceptor-listen-socket acceptor) nil) acceptor) --- 269,285 ---- (execute-acceptor taskmaster)) acceptor) ! (defmethod stop ((acceptor acceptor) &key soft) (setf (acceptor-shutdown-p acceptor) t) (shutdown (acceptor-taskmaster acceptor)) ! (when soft ! (with-lock-held ((acceptor-shutdown-lock acceptor)) ! (when (plusp (accessor-requests-in-progress acceptor)) ! (condition-variable-wait (acceptor-shutdown-queue acceptor) ! (acceptor-shutdown-lock acceptor))))) ! (#+:lispworks close ! #-:lispworks usocket:socket-close ! (acceptor-listen-socket acceptor)) (setf (acceptor-listen-socket acceptor) nil) acceptor) *************** *** 328,346 **** chunked encoding, but acceptor is configured to not use it."))))) (multiple-value-bind (remote-addr remote-port) (get-peer-address-and-port socket) (process-request (make-instance (acceptor-request-class *acceptor*) ! :acceptor *acceptor* ! :remote-addr remote-addr ! :remote-port remote-port ! :headers-in headers-in ! :content-stream *hunchentoot-stream* ! :method method ! :uri url-string ! :server-protocol protocol)))) (force-output *hunchentoot-stream*) (setq *hunchentoot-stream* (reset-connection-stream *acceptor* *hunchentoot-stream*)) (when *close-hunchentoot-stream* (return))))) (when *hunchentoot-stream* ;; as we are at the end of the request here, we ignore all ;; errors that may occur while flushing and/or closing the --- 351,379 ---- chunked encoding, but acceptor is configured to not use it."))))) (multiple-value-bind (remote-addr remote-port) (get-peer-address-and-port socket) + (with-lock-held ((acceptor-shutdown-lock *acceptor*)) + (incf (accessor-requests-in-progress *acceptor*))) (process-request (make-instance (acceptor-request-class *acceptor*) ! :acceptor *acceptor* ! :remote-addr remote-addr ! :remote-port remote-port ! :headers-in headers-in ! :content-stream *hunchentoot-stream* ! :method method ! :uri url-string ! :server-protocol protocol))) ! ) (force-output *hunchentoot-stream*) (setq *hunchentoot-stream* (reset-connection-stream *acceptor* *hunchentoot-stream*)) (when *close-hunchentoot-stream* (return))))) + + ;; When we are finished processing the request: + (with-lock-held ((acceptor-shutdown-lock *acceptor*)) + (decf (accessor-requests-in-progress *acceptor*)) + (when (acceptor-shutdown-p *acceptor*) + (condition-variable-signal (acceptor-shutdown-queue *acceptor*)))) + (when *hunchentoot-stream* ;; as we are at the end of the request here, we ignore all ;; errors that may occur while flushing and/or closing the *** /ita/hunchentoot/hunchentoot-1.1.1/taskmaster.lisp 2010-08-22 15:33:01.000000000 -0400 --- /ita/work/four/qres/lisp/libs/hunchentoot/taskmaster.lisp 2011-02-03 14:17:16.000000000 -0500 *************** *** 27,32 **** --- 27,34 ---- ;;; NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS ;;; SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + #+xcvb (module (:depends-on ("conditions"))) + (in-package :hunchentoot) (defclass taskmaster () *************** *** 60,65 **** --- 62,117 ---- might terminate all threads that are currently associated with it. This function is called by the acceptor's STOP method.")) + (defgeneric create-taskmaster-thread (taskmaster socket) + (:documentation + "Create a new thread in which to process the request. + This thread will call PROCESS-CONNECTION to process the request.")) + + (defgeneric too-many-taskmaster-requests (taskmaster socket) + (:documentation + "Signal a \"too many requests\" error, just prior to closing the connection.")) + + (defgeneric taskmaster-max-thread-count (taskmaster) + (:documentation + "The maximum number of request threads this taskmaster will simultaneously + run before refusing or queueing new connections requests. If the value + is null, then there is no limit.") + (:method ((taskmaster taskmaster)) + "Default method -- no limit on the number of threads." + nil)) + + (defgeneric taskmaster-max-accept-count (taskmaster) + (:documentation + "The maximum number of connections this taskmaster will accept before refusing + new connections. If supplied, this must be greater than MAX-THREAD-COUNT. + The number of queued requests is the difference between MAX-ACCEPT-COUNT + and MAX-THREAD-COUNT.") + (:method ((taskmaster taskmaster)) + "Default method -- no limit on the number of connections." + nil)) + + (defgeneric taskmaster-request-count (taskmaster) + (:documentation + "Returns the current number of taskmaster requests.") + (:method ((taskmaster taskmaster)) + "Default method -- claim there is one connection thread." + 1)) + + (defgeneric increment-taskmaster-request-count (taskmaster) + (:documentation + "Atomically increment the number of taskmaster requests.") + (:method ((taskmaster taskmaster)) + "Default method -- do nothing." + nil)) + + (defgeneric decrement-taskmaster-request-count (taskmaster) + (:documentation + "Atomically decrement the number of taskmaster requests") + (:method ((taskmaster taskmaster)) + "Default method -- do nothing." + nil)) + + (defclass single-threaded-taskmaster (taskmaster) () (:documentation "A taskmaster that runs synchronously in the thread *************** *** 78,96 **** ;; in a single-threaded environment we just call PROCESS-CONNECTION (process-connection (taskmaster-acceptor taskmaster) socket)) (defclass one-thread-per-connection-taskmaster (taskmaster) (#-:lispworks ! (acceptor-process :accessor acceptor-process ! :documentation "A process that accepts incoming ! connections and hands them off to new processes for request ! handling.")) (:documentation "A taskmaster that starts one thread for listening ! to incoming requests and one thread for each incoming connection. This is the default taskmaster implementation for multi-threaded Lisp implementations.")) ! ;; usocket implementation #-:lispworks (defmethod shutdown ((taskmaster taskmaster)) --- 130,271 ---- ;; in a single-threaded environment we just call PROCESS-CONNECTION (process-connection (taskmaster-acceptor taskmaster) socket)) + (defvar *default-max-thread-count* 100) + (defvar *default-max-accept-count* (+ *default-max-thread-count* 20)) + + ;; You might think it would be nice to provide a taskmaster that takes + ;; threads out of a thread pool. There are two things to consider: + ;; - On a 2010-ish Linux box, thread creation takes less than 250 microseconds. + ;; - Bordeaux Threads doesn't provide a way to "reset" and restart a thread, + ;; and it's not clear how many Lisp implementations can do this. + ;; So for now, we leave this out of the mix. (defclass one-thread-per-connection-taskmaster (taskmaster) (#-:lispworks ! (acceptor-process ! :accessor acceptor-process ! :documentation ! "A process that accepts incoming connections and hands them off to new processes ! for request handling.") ! ;; Support for bounding the number of threads we'll create ! (max-thread-count ! :type (or integer null) ! :initarg :max-thread-count ! :initform nil ! :accessor taskmaster-max-thread-count ! :documentation ! "The maximum number of request threads this taskmaster will simultaneously ! run before refusing or queueing new connections requests. If the value ! is null, then there is no limit.") ! (max-accept-count ! :type (or integer null) ! :initarg :max-accept-count ! :initform nil ! :accessor taskmaster-max-accept-count ! :documentation ! "The maximum number of connections this taskmaster will accept before refusing ! new connections. If supplied, this must be greater than MAX-THREAD-COUNT. ! The number of queued requests is the difference between MAX-ACCEPT-COUNT ! and MAX-THREAD-COUNT.") ! (request-count ! :type integer ! :initform 0 ! :accessor taskmaster-request-count ! :documentation ! "The number of taskmaster threads currently running.") ! (request-count-lock ! :initform (make-lock "taskmaster-request-count") ! :reader taskmaster-request-count-lock ! :documentation ! "In the absence of 'atomic-incf', we need this to atomically ! increment and decrement the request count.") ! (wait-queue ! :initform (make-condition-variable) ! :reader taskmaster-wait-queue ! :documentation ! "A queue that we use to wait for a free connection.") ! (wait-lock ! :initform (make-lock "taskmaster-thread-lock") ! :reader taskmaster-wait-lock ! :documentation ! "The lock for the connection wait queue.") ! (worker-thread-name-format ! :type (or string null) ! :initarg :worker-thread-name-format ! :initform "hunchentoot-worker-~A" ! :accessor taskmaster-worker-thread-name-format)) ! (:default-initargs ! :max-thread-count *default-max-thread-count* ! :max-accept-count *default-max-accept-count*) (:documentation "A taskmaster that starts one thread for listening ! to incoming requests and one new thread for each incoming connection. ! ! If MAX-THREAD-COUNT is null, a new thread will always be created for ! each request. ! ! If MAX-THREAD-COUNT is supplied, the number of request threads is ! limited to that. Furthermore, if MAX-ACCEPT-COUNT is not supplied, an ! HTTP 503 will be sent if the thread limit is exceeded. Otherwise, if ! MAX-ACCEPT-COUNT is supplied, it must be greater than MAX-THREAD-COUNT; ! in this case, requests are accepted up to MAX-ACCEPT-COUNT, and only ! then is HTTP 503 sent. ! ! In a load-balanced environment with multiple Hunchentoot servers, it's ! reasonable to provide MAX-THREAD-COUNT but leave MAX-ACCEPT-COUNT null. ! This will immediately result in HTTP 503 when one server is out of ! resources, so the load balancer can try to find another server. ! ! In an environment with a single Hunchentoot server, it's reasonable ! to provide both MAX-THREAD-COUNT and a somewhat larger value for ! MAX-ACCEPT-COUNT. This will cause a server that's almost out of ! resources to wait a bit; if the server is completely out of resources, ! then the reply will be HTTP 503. This is the default taskmaster implementation for multi-threaded Lisp implementations.")) ! (defmethod initialize-instance :after ((taskmaster one-thread-per-connection-taskmaster) &rest init-args) ! "Ensure the if MAX-ACCEPT-COUNT is supplied, that it is greater than MAX-THREAD-COUNT." ! (declare (ignore init-args)) ! (when (taskmaster-max-accept-count taskmaster) ! (unless (taskmaster-max-thread-count taskmaster) ! (parameter-error "MAX-THREAD-COUNT must be supplied if MAX-ACCEPT-COUNT is supplied")) ! (unless (> (taskmaster-max-accept-count taskmaster) (taskmaster-max-thread-count taskmaster)) ! (parameter-error "MAX-ACCEPT-COUNT must be greater than MAX-THREAD-COUNT")))) ! ! (defmethod increment-taskmaster-request-count ((taskmaster one-thread-per-connection-taskmaster)) ! (when (taskmaster-max-thread-count taskmaster) ! (with-lock-held ((taskmaster-request-count-lock taskmaster)) ! (incf (taskmaster-request-count taskmaster))))) ! ! (defmethod decrement-taskmaster-request-count ((taskmaster one-thread-per-connection-taskmaster)) ! (when (taskmaster-max-thread-count taskmaster) ! (prog1 ! (with-lock-held ((taskmaster-request-count-lock taskmaster)) ! (decf (taskmaster-request-count taskmaster))) ! (when (and (taskmaster-max-accept-count taskmaster) ! (< (taskmaster-request-count taskmaster) (taskmaster-max-accept-count taskmaster))) ! (note-free-connection taskmaster))))) ! ! (defmethod note-free-connection ((taskmaster one-thread-per-connection-taskmaster)) ! "Note that a connection has been freed up" ! (with-lock-held ((taskmaster-wait-lock taskmaster)) ! (condition-variable-signal (taskmaster-wait-queue taskmaster)))) ! ! (defmethod wait-for-free-connection ((taskmaster one-thread-per-connection-taskmaster)) ! "Wait for a connection to be freed up" ! (with-lock-held ((taskmaster-wait-lock taskmaster)) ! (loop until (< (taskmaster-request-count taskmaster) (taskmaster-max-thread-count taskmaster)) ! do (condition-variable-wait (taskmaster-wait-queue taskmaster) (taskmaster-wait-lock taskmaster))))) ! ! (defmethod too-many-taskmaster-requests ((taskmaster one-thread-per-connection-taskmaster) socket) ! (declare (ignore socket)) ! (let* ((acceptor (taskmaster-acceptor taskmaster)) ! (logger (and acceptor (acceptor-message-logger acceptor)))) ! (when logger ! (funcall logger :warning "Can't handle a new request, too many request threads already")))) ! ! ! ;;; usocket implementation #-:lispworks (defmethod shutdown ((taskmaster taskmaster)) *************** *** 108,123 **** #-:lispworks (defmethod execute-acceptor ((taskmaster one-thread-per-connection-taskmaster)) (setf (acceptor-process taskmaster) ! (bt:make-thread (lambda () ! (accept-connections (taskmaster-acceptor taskmaster))) ! :name (format nil "Hunchentoot listener \(~A:~A)" ! (or (acceptor-address (taskmaster-acceptor taskmaster)) "*") ! (acceptor-port (taskmaster-acceptor taskmaster)))))) #-:lispworks (defun client-as-string (socket) "A helper function which returns the client's address and port as a ! string and tries to act robustly in the presence of network problems." (let ((address (usocket:get-peer-address socket)) (port (usocket:get-peer-port socket))) (when (and address port) --- 283,348 ---- #-:lispworks (defmethod execute-acceptor ((taskmaster one-thread-per-connection-taskmaster)) (setf (acceptor-process taskmaster) ! (bt:make-thread ! (lambda () ! (accept-connections (taskmaster-acceptor taskmaster))) ! :name (format nil "hunchentoot-listener-~A:~A" ! (or (acceptor-address (taskmaster-acceptor taskmaster)) "*") ! (acceptor-port (taskmaster-acceptor taskmaster)))))) ! ! #-:lispworks ! (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) ! ;; Here's the idea, with the stipulations given in ONE-THREAD-PER-CONNECTION-TASKMASTER ! ;; - If MAX-THREAD-COUNT is null, just start a taskmaster ! ;; - If the connection count will exceed MAX-ACCEPT-COUNT or if MAX-ACCEPT-COUNT ! ;; is null and the connection count will exceed MAX-THREAD-COUNT, ! ;; return an HTTP 503 error to the client ! ;; - Otherwise if we're between MAX-THREAD-COUNT and MAX-ACCEPT-COUNT, ! ;; wait until the connection count drops, then handle the request ! ;; - Otherwise, increment REQUEST-COUNT and start a taskmaster ! (cond ((null (taskmaster-max-thread-count taskmaster)) ! ;; No limit on number of requests, just start a taskmaster ! (create-taskmaster-thread taskmaster socket)) ! ((if (taskmaster-max-accept-count taskmaster) ! (>= (taskmaster-request-count taskmaster) (taskmaster-max-accept-count taskmaster)) ! (>= (taskmaster-request-count taskmaster) (taskmaster-max-thread-count taskmaster))) ! ;; Send HTTP 503 to indicate that we can't handle the request right now ! (too-many-taskmaster-requests taskmaster socket) ! (send-http-error-reply taskmaster socket +http-service-unavailable+)) ! ((and (taskmaster-max-accept-count taskmaster) ! (>= (taskmaster-request-count taskmaster) (taskmaster-max-thread-count taskmaster))) ! ;; Wait for a request to finish, then carry on ! (wait-for-free-connection taskmaster) ! (increment-taskmaster-request-count taskmaster) ! (create-taskmaster-thread taskmaster socket)) ! (t ! ;; We're within both limits, just start a taskmaster ! (increment-taskmaster-request-count taskmaster) ! (create-taskmaster-thread taskmaster socket)))) ! ! (defun send-http-error-reply (taskmaster socket error-code) ! "A helper function to send out a quick error reply, ! before any state is set up via PROCESS-REQUEST." ! (let* ((acceptor (taskmaster-acceptor taskmaster)) ! (stream (initialize-connection-stream acceptor (make-socket-stream socket acceptor))) ! (reason-phrase (reason-phrase error-code)) ! (first-line (format nil "HTTP/1.1 ~D ~A" ! error-code reason-phrase)) ! (content (format nil "~D ~A

~:*~A

~A" ! error-code reason-phrase reason-phrase))) ! (write-sequence (map 'list #'char-code first-line) stream) ! (write-sequence +crlf+ stream) ;end of first line ! (write-header-line "Content-Type" "text/html; charset=iso-8859-1" stream) ! (write-header-line "Content-Length" (length content) stream) ! (write-sequence +crlf+ stream) ;end of headers ! (write-sequence (map 'list #'char-code content) stream) ! (write-sequence +crlf+ stream) ;end of content ! (force-output stream))) #-:lispworks (defun client-as-string (socket) "A helper function which returns the client's address and port as a ! string and tries to act robustly in the presence of network problems." (let ((address (usocket:get-peer-address socket)) (port (usocket:get-peer-port socket))) (when (and address port) *************** *** 126,149 **** port)))) #-:lispworks ! (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) ;; we are handling all conditions here as we want to make sure that ;; the acceptor process never crashes while trying to create a ;; worker thread; one such problem exists in ;; GET-PEER-ADDRESS-AND-PORT which can signal socket conditions on ;; some platforms in certain situations. (handler-case* ! (bt:make-thread (lambda () ! (process-connection (taskmaster-acceptor taskmaster) socket)) ! :name (format nil "Hunchentoot worker \(client: ~A)" (client-as-string socket))) ! ! (error (cond) ! ;; need to bind *ACCEPTOR* so that LOG-MESSAGE can do its work. ! (let ((*acceptor* (taskmaster-acceptor taskmaster))) ! (log-message *lisp-errors-log-level* ! "Error while creating worker thread for new incoming connection: ~A" cond))))) ! ;; LispWorks implementation #+:lispworks (defmethod shutdown ((taskmaster taskmaster)) --- 351,377 ---- port)))) #-:lispworks ! (defmethod create-taskmaster-thread ((taskmaster one-thread-per-connection-taskmaster) socket) ! "Create a thread for handling a single request" ;; we are handling all conditions here as we want to make sure that ;; the acceptor process never crashes while trying to create a ;; worker thread; one such problem exists in ;; GET-PEER-ADDRESS-AND-PORT which can signal socket conditions on ;; some platforms in certain situations. (handler-case* ! (bt:make-thread ! (lambda () ! (unwind-protect ! (process-connection (taskmaster-acceptor taskmaster) socket) ! (decrement-taskmaster-request-count taskmaster))) ! :name (format nil (taskmaster-worker-thread-name-format taskmaster) (client-as-string socket))) ! (error (cond) ! ;; need to bind *ACCEPTOR* so that LOG-MESSAGE can do its work. ! (let ((*acceptor* (taskmaster-acceptor taskmaster))) ! (log-message *lisp-errors-log-level* ! "Error while creating worker thread for new incoming connection: ~A" cond))))) ! ;;; LispWorks implementation #+:lispworks (defmethod shutdown ((taskmaster taskmaster)) *************** *** 158,172 **** (accept-connections (taskmaster-acceptor taskmaster))) #+:lispworks ! (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) handle) (incf *worker-counter*) ;; check if we need to perform a global GC (when (and *cleanup-interval* (zerop (mod *worker-counter* *cleanup-interval*))) (when *cleanup-function* (funcall *cleanup-function*))) ! (mp:process-run-function (format nil "Hunchentoot worker \(client: ~{~A:~A~})" ! (multiple-value-list ! (get-peer-address-and-port handle))) ! nil #'process-connection ! (taskmaster-acceptor taskmaster) handle)) --- 386,424 ---- (accept-connections (taskmaster-acceptor taskmaster))) #+:lispworks ! (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) (incf *worker-counter*) ;; check if we need to perform a global GC (when (and *cleanup-interval* (zerop (mod *worker-counter* *cleanup-interval*))) (when *cleanup-function* (funcall *cleanup-function*))) ! (cond ((null (taskmaster-max-thread-count taskmaster)) ! ;; No limit on number of requests, just start a taskmaster ! (create-taskmaster-thread taskmaster socket)) ! ((if (taskmaster-max-accept-count taskmaster) ! (>= (taskmaster-request-count taskmaster) (taskmaster-max-accept-count taskmaster)) ! (>= (taskmaster-request-count taskmaster) (taskmaster-max-thread-count taskmaster))) ! ;; Send HTTP 503 to indicate that we can't handle the request right now ! (too-many-taskmaster-requests taskmaster socket) ! (send-http-error-reply taskmaster socket +http-service-unavailable+)) ! ((and (taskmaster-max-accept-count taskmaster) ! (>= (taskmaster-request-count taskmaster) (taskmaster-max-thread-count taskmaster))) ! ;; Lispworks doesn't have condition variables, so punt ! (too-many-taskmaster-requests taskmaster socket) ! (send-http-error-reply taskmaster socket +http-service-unavailable+)) ! (t ! ;; We're within both limits, just start a taskmaster ! (increment-taskmaster-request-count taskmaster) ! (create-taskmaster-thread taskmaster socket)))) ! ! #+:lispworks ! (defmethod create-taskmaster-thread ((taskmaster one-thread-per-connection-taskmaster) socket) ! (flet ((process (taskmaster sock) ! (unwind-protect ! (process-connection (taskmaster-acceptor taskmaster) socket) ! (decrement-taskmaster-request-count taskmaster)))) ! (mp:process-run-function (format nil "hunchentoot-worker~{-~A:~A~})" ! (multiple-value-list ! (get-peer-address-and-port socket))) ! nil #'process taskmaster socket))) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vseloved at gmail.com Wed Feb 9 18:12:02 2011 From: vseloved at gmail.com (Vsevolod Dyomkin) Date: Wed, 9 Feb 2011 20:12:02 +0200 Subject: [hunchentoot-devel] error at weitz.de/hunchentoot Message-ID: Hi, the Hunchentoot web-site currently shows the following message: This page contains the following errors: error on line 2 at column 3: Char 0x0 out of allowed range Below is a rendering of the page up to the first error. Best, Vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Feb 9 18:36:42 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 9 Feb 2011 19:36:42 +0100 Subject: [hunchentoot-devel] error at weitz.de/hunchentoot In-Reply-To: References: Message-ID: Vsevolod, On Wed, Feb 9, 2011 at 7:12 PM, Vsevolod Dyomkin wrote: > the Hunchentoot web-site currently shows the following message: What web site are you talking about? I am looking at http://weitz.de/hunchentoot/ and it appears to be okay. -Hans From vseloved at gmail.com Wed Feb 9 18:48:59 2011 From: vseloved at gmail.com (Vsevolod Dyomkin) Date: Wed, 9 Feb 2011 20:48:59 +0200 Subject: [hunchentoot-devel] error at weitz.de/hunchentoot In-Reply-To: References: Message-ID: The error is displayed in Chrome 6 and Epiphany 2.30 on Debian Squeeze. Firefox 3.6 renders the page correctly. Vsevolod On Wed, Feb 9, 2011 at 8:36 PM, Hans H?bner wrote: > Vsevolod, > > On Wed, Feb 9, 2011 at 7:12 PM, Vsevolod Dyomkin > wrote: > > the Hunchentoot web-site currently shows the following message: > > What web site are you talking about? I am looking at > http://weitz.de/hunchentoot/ and it appears to be okay. > > -Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Wed Feb 9 20:01:14 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 9 Feb 2011 21:01:14 +0100 Subject: [hunchentoot-devel] error at weitz.de/hunchentoot In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 7:48 PM, Vsevolod Dyomkin wrote: > The error is displayed in Chrome 6 and Epiphany 2.30 on Debian Squeeze. > Firefox 3.6 renders the page correctly. The site uses client-side XSL, but all modern browsers support that. In particular, Chrome works well for me. Does anyone else see experience this issue? -Hans From gordon at itasoftware.com Wed Feb 9 20:11:05 2011 From: gordon at itasoftware.com (Gordon Sims) Date: Wed, 09 Feb 2011 15:11:05 -0500 Subject: [hunchentoot-devel] error at weitz.de/hunchentoot In-Reply-To: References: Message-ID: <4D52F4D9.4010301@itasoftware.com> Chrome 6 seems fairly old.. the current version is 9. From hans.huebner at gmail.com Thu Feb 10 17:25:59 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 10 Feb 2011 18:25:59 +0100 Subject: [hunchentoot-devel] Robustness change committed Message-ID: Hi, I committed a (modified) patch submitted by Dan Weinreb that makes Hunchentoot more resilient to high load conditions by limiting the number of request handler threads that can be running at any time. If you are running a site with a lot of traffic, you'll want to be aware of this change. Documentation for this feature is not yet available. -Hans ---------- Forwarded message ---------- From: BKNR Commits Date: Thu, Feb 10, 2011 at 6:22 PM Subject: [bknr-cvs] hans changed trunk/thirdparty/hunchentoot/ To: bknr-cvs at common-lisp.net Revision: 4645 Author: hans URL: http://bknr.net/trac/changeset/4645 Patch from Dan Weinreb: limit the maximum number of request handler threads that a taskmaster may create. Support a new SOFT argument to the STOP function that makes Hunchentoot wait until all currently outstanding requests have been processed before returning. Add a favicon.ico to the standard file tree. Refactorings in the START-OUTPUT function to separate out the actual header sending from the request processing part. ?The new SEND-RESPONSE function does the I/O part of sending the response header (and possibly content) and also does the logging. ?Used by the thread count limiting code to send a 503 message if no more threads can be created. U ? trunk/thirdparty/hunchentoot/acceptor.lisp U ? trunk/thirdparty/hunchentoot/compat.lisp U ? trunk/thirdparty/hunchentoot/headers.lisp U ? trunk/thirdparty/hunchentoot/taskmaster.lisp U ? trunk/thirdparty/hunchentoot/util.lisp A ? trunk/thirdparty/hunchentoot/www/favicon.ico Change set too large, please see URL above _______________________________________________ bknr-cvs mailing list bknr-cvs at common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-cvs From hans.huebner at gmail.com Fri Feb 11 11:08:42 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 11 Feb 2011 12:08:42 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted Message-ID: Hi, as you may have seen from the revision log (http://bknr.net/trac/log/trunk/thirdparty/hunchentoot?rev=4650), there has been a fair amount of change to Hunchentoot in the recent weeks and Edi is planning to make a new release soon. Here are the highlights of what has been changed: - Logging has been overhauled. There are now two generic function ACCEPTOR-LOG-MESSAGE and ACCEPTOR-LOG-ACCESS that perform the logging and can be specialized on a per-acceptor basis. By default, Hunchentoot now logs to the console instead of being silent. - Error handling and reporting has been reworked. Internal errors are handled more gracefully. - The default request handler is gone. By default, Hunchentoot now generates a 404 message if an unknown URL is requested. - Error message generation can now be customized on a per-acceptor fashion. Also, code to generate error messages from HTML template files has been added. - By default, Hunchentoot now serves static files. A document tree including a simple "It works!"-like home page, the documentation in HTML format and customized error pages will be distributed with Hunchentoot and served by default. - Robustness changes from ITA - Various smaller bug fixes Before making a release, I would like to improve the looks of the standard document tree and the error pages a little. Does someone have web design skills that they want to contribute? If so, please have a look at the current development version (svn co http://bknr.net/svn/ediware) and me patches. I'm not looking for anything too fancy. Good looks can't hurt, though! :) Thanks! -Hans From archimag at gmail.com Tue Feb 15 16:22:50 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Tue, 15 Feb 2011 16:22:50 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: Message-ID: Hi, I started testing a new version of Hunchentoot and found that you forgot to exported "ACCEPTOR-DISPATCH-REQUEST" - it is absolutely necessary! In addition, the exported "ACCEPTOR-REQUEST-DISPATCHER" is obsolete. Andrey From gordon at itasoftware.com Tue Feb 15 16:30:42 2011 From: gordon at itasoftware.com (Gordon Sims) Date: Tue, 15 Feb 2011 11:30:42 -0500 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: Message-ID: <4D5AAA32.1020809@itasoftware.com> Andrey Moskvitin wrote: > In addition, the exported "ACCEPTOR-REQUEST-DISPATCHER" is obsolete. (I am using ITA QRes' version of Hunchentoot rather than the newest) HUNCHENTOOT:*LISTENER* seems the same. Perhaps it can also be removed. -Gordon From hans.huebner at gmail.com Tue Feb 15 17:00:40 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 15 Feb 2011 18:00:40 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: <4D5AAA32.1020809@itasoftware.com> References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Tue, Feb 15, 2011 at 5:30 PM, Gordon Sims wrote: > Andrey Moskvitin wrote: >> In addition, the exported "ACCEPTOR-REQUEST-DISPATCHER" is obsolete. > HUNCHENTOOT:*LISTENER* seems the same. ?Perhaps it can also be removed. Thank you for the reports, I have fixed those two and will see if I can automatically clean up the rest of the exports. Cheers, Hans From archimag at gmail.com Tue Feb 15 18:58:53 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Tue, 15 Feb 2011 21:58:53 +0300 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: "ACCEPTOR-STATUS-MESSAGE" also want to export. Please add to the documentation ("Tutorials and add-ons") link to the RESTAS (http://restas.lisper.ru/) - my web framework based on Hunchentoot. Andrey From hans.huebner at gmail.com Tue Feb 15 21:46:03 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 15 Feb 2011 22:46:03 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Tue, Feb 15, 2011 at 7:58 PM, Andrey Moskvitin wrote: > "ACCEPTOR-STATUS-MESSAGE" also want to export. > > Please add to the documentation ("Tutorials and add-ons") link to the > RESTAS (http://restas.lisper.ru/) - my web framework based on Hunchentoot. Done, thank you! Please keep bug reports coming! -Hans From archimag at gmail.com Wed Feb 16 09:55:30 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Wed, 16 Feb 2011 09:55:30 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: Hi, Problems with calling 'error-contents-from-template in the 'acceptor-status-message: 1. Ignored variables *show-lisp-errors-p* and *show-lisp-backtraces-p* 2. Do not set content-type to "text/html; charset=iso-8859-1" 3. Path /img/made-with-lisp-logo.jpg may be invalid Maybe it does not need? (apply 'make-cooked-message http-status-code args) well suited for most occasions. IMHO, 404.html and 500.html templates only complicate the code and create problems, but virtually useless in practice. Andrey From hans.huebner at gmail.com Wed Feb 16 10:40:09 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 16 Feb 2011 11:40:09 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Wed, Feb 16, 2011 at 10:55 AM, Andrey Moskvitin wrote: > Problems with calling 'error-contents-from-template > in the 'acceptor-status-message: > > 1. Ignored variables *show-lisp-errors-p* and *show-lisp-backtraces-p* This is intentional. The template determines whether a backtrace or error message is displayed. > 2. Do not set content-type to "text/html; charset=iso-8859-1" That is right. I am going to fix this, but while looking at the problem, I found that Hunchentoot is not currently smart about the content type that it generates. I think that the content type should automatically match the external format, and that it should default to utf-8 instead of latin-1. I'm going to address that in a separate commit. > 3. Path /img/made-with-lisp-logo.jpg may be invalid Right. The error pages supplied with Hunchentoot will work only when the images and possibly other resources that are referenced from them are available at the expected locations. My plan is to supply a standard document tree that is useful. Users are free to ignore that document tree, and Hunchentoot will automatically fall back to cooked message bodies when no template is found. > Maybe it does not need? > (apply 'make-cooked-message http-status-code args) > well suited for most occasions. IMHO, 404.html and 500.html templates > only complicate the code and create problems, but virtually useless > in practice. I don't find the whole thing overly complicated, and you are free to ignore the feature if you don't like it or think it is useless. Thank you for reporting the problems that you've found! Edi has the last say in all this anyway. -Hans From archimag at gmail.com Wed Feb 16 10:57:06 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Wed, 16 Feb 2011 10:57:06 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: > you are free to ignore the feature if you don't like it In this case, need to export "MAKE-COOKED-MESSAGE", so that I could normally call it for my acceptor. Andrey From hans.huebner at gmail.com Wed Feb 16 11:01:07 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 16 Feb 2011 12:01:07 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Wed, Feb 16, 2011 at 11:57 AM, Andrey Moskvitin wrote: >> you are free to ignore the feature if you don't like it > > In this case, need to export "MAKE-COOKED-MESSAGE", > so that I could normally call it for my acceptor. Setting ACCEPTOR-ERROR-TEMPLATE-DIRECTORY in the acceptor to NIL and (CALL-NEXT-METHOD) from your own ACCEPTOR-STATUS-MESSAGE method should do, or am I missing something? -Hans From hans.huebner at gmail.com Wed Feb 16 11:50:38 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 16 Feb 2011 12:50:38 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Wed, Feb 16, 2011 at 11:40 AM, Hans H?bner wrote: > On Wed, Feb 16, 2011 at 10:55 AM, Andrey Moskvitin wrote: >> 2. Do not set content-type to "text/html; charset=iso-8859-1" > > That is right. ?I am going to fix this, but while looking at the > problem, I found that Hunchentoot is not currently smart about the > content type that it generates. ?I think that the content type should > automatically match the external format, and that it should default to > utf-8 instead of latin-1. ?I'm going to address that in a separate > commit. http://bknr.net/trac/changeset/4655 corrects this problem. Hunchentoot now determines the charset= attribute in text content type headers automatically when a handler returned a string. The content type is not touched when the handler directly writes to the stream or returns octets for Hunchentoot to send. Please let me know if there are any problems with this change. -Hans From archimag at gmail.com Wed Feb 16 12:08:39 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Wed, 16 Feb 2011 12:08:39 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: > Setting ACCEPTOR-ERROR-TEMPLATE-DIRECTORY in the acceptor to NIL and > (CALL-NEXT-METHOD) from your own ACCEPTOR-STATUS-MESSAGE method > should do, or am I missing something? Yes, thank you, but only ACCEPTOR-ERROR-TEMPLATE-DIRECTORY then also need to export ) Andrey From hans.huebner at gmail.com Wed Feb 16 12:13:24 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 16 Feb 2011 13:13:24 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Wed, Feb 16, 2011 at 1:08 PM, Andrey Moskvitin wrote: >> Setting ACCEPTOR-ERROR-TEMPLATE-DIRECTORY in the acceptor to NIL and >> (CALL-NEXT-METHOD) from your own ACCEPTOR-STATUS-MESSAGE method >> should do, or am I missing something? > > Yes, thank you, but only ACCEPTOR-ERROR-TEMPLATE-DIRECTORY > then also need to export ) I've done that, but you'll normally don't want to follow my advice literally but rather supply a :ERROR-TEMPLATE-DIRECTORY as initarg when you create your acceptor. If you're working with a derived acceptor class, consider using a :DEFAULT-INITARGS clause in your acceptor class definition to override what Hunchentoot uses for bare ACCEPTOR instances. -Hans From archimag at gmail.com Wed Feb 16 12:16:18 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Wed, 16 Feb 2011 12:16:18 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: > I've done that, but you'll normally don't want to follow my advice > literally but rather supply a :ERROR-TEMPLATE-DIRECTORY as initarg > when you create your acceptor. ?If you're working with a derived > acceptor class, consider using a :DEFAULT-INITARGS clause in your > acceptor class definition to override what Hunchentoot uses for bare > ACCEPTOR instances. Yes, just like I did) Thank you. Andrey From archimag at gmail.com Wed Feb 16 12:21:49 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Wed, 16 Feb 2011 12:21:49 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: > Hunchentoot now determines the charset= attribute in text content type > headers automatically when a handler returned a string. ?The content > type is not touched when the handler directly writes to the stream or > returns octets for Hunchentoot to send. > > Please let me know if there are any problems with this change. My code set content-type to "text/plain", but after this error occurs. As a result, sends to client 500.html with "content-type=text/plain". Andrey From hans.huebner at gmail.com Wed Feb 16 12:27:11 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 16 Feb 2011 13:27:11 +0100 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: On Wed, Feb 16, 2011 at 1:21 PM, Andrey Moskvitin wrote: >> Hunchentoot now determines the charset= attribute in text content type >> headers automatically when a handler returned a string. ?The content >> type is not touched when the handler directly writes to the stream or >> returns octets for Hunchentoot to send. >> >> Please let me know if there are any problems with this change. > > My code set content-type to "text/plain", but after this error occurs. > As a result, sends to client 500.html with "content-type=text/plain". Thanks for the report, the problem is fixed by this change: http://bknr.net/trac/changeset/4657 -Hans From archimag at gmail.com Wed Feb 16 15:11:55 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Wed, 16 Feb 2011 15:11:55 +0000 Subject: [hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted In-Reply-To: References: <4D5AAA32.1020809@itasoftware.com> Message-ID: I ended adaptation own applications for the new version of Hunchentoot. I have everything working. In general, I think Hunchentoot is improved. Thank you. Andrey From avodonosov at yandex.ru Sun Feb 20 03:36:14 2011 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Sun, 20 Feb 2011 06:36:14 +0300 Subject: [hunchentoot-devel] web programming api for lisp Message-ID: <7731298172974@web10.yandex.ru> Hello. What do you think about the idea to have a server-independent API for web programming in Common Lisp, similar to the Java Servlet API, Ruby Rack, etc. ? We may take the current hunchentoot API and use it for other servers. For example, we may implement the same request, reply, *dispatch-table*, sessions, cookies functions as provided by hunchentoot for google app engine (with ABCL). Then web applications may be freely moved between the hunchentoot and the google app engine (for course, if they don't depend on other APIs, like google app engine persistence api). Another option, is to use this API to embed ECL into apache or nginx, and write Common Lisp web applications for these servers. If the API will be based on hunchentoot, existing and new Common Lisp web applications will be easily moved between hunchentoot and these servers. (Embedding ECL into apache is already possible with mod_ecl[1]. We will only need to adopt the mod_lisp API to the hunchentoot-like interface, to make Lisp applications portable. Nginx has embedded perl, therefore it has an API for external modules; if we embed ECL into nginx, we again only need to adopt the nginx-specific API to the standard hunchentoot-like form, and Lisp we applications will become portable between servers). But the most interesting option was suggested by Andrey Moskvitin in his blog [2]: to implement the hunchentoot-like interface for the Mongrel2 web server. The advantage of this solution is that it will work for any Common Lisp implementation, but not for only one (ECL or ABCL) as in the previous options. BTW, Mongrel2 integration for Common Lisp already exists in the form of cl-mongrel2 [3], and the question is again only in adopting the APIs. Even although porting the hunchentoot interface as is to Mongrel2 will not allow to fully untilize the Mongrel2 high concurrency asynchronous IO features, it seems like a good improvement in the Common Lisp ecosystem. It is roughly clear what parts of the hunchentoot API should turned into cross-server API: request, reply, cookies, sessions, request dispatch and handling (partially, only the basic things), conditions and error handling, miscellaneous (partially). Other parts, like acceptors, taskmasters, logging are not the interface between web application and server but rather the web server startup and configuration API. Writing an actual implementation for another web server will clarify the questionable points. And Andrey Moskvitin has yesterday started implementing the hucnentoot interfece for Mongrel2, therefore we have chances to see it soon. The parts Andrey quickly extracted from the hunchentoot codebase for the web server independent API may be found here: https://github.com/archimag/cl-wsal. As you may notice, small incompatibility exists: huncentoot-error become wsal-error. There is also a peace of code from chunga: know-words.lisp. Andrey told us he just took everything is needed to make the interface code compilable. The question for hunchentoot developers and community: in case of successful implementation of the hunchentoot-like API on other web servers, do you think it is good for hunchentoot itself to split its API into two parts: abstract web server interface shared with other servers, and actual common lisp implemented web server providing this interface? Interestingly, hunchentoot emerged from a library to talk to mod_lisp and other front-ends [4]. Today, when hunchentoot is highly adopted, it seems reasonable to pick out it's web programming API into a separate module, and share this API between hunchentoot and other front-end adapters, maybe other common lisp web servers, etc. And this will not add implementation complexity to the hunchentoot itself (which was the cause of the mod_lisp support removal in the 1.0 release). What do you think? 1. mod_ecl - http://mod-ecl.sourceforge.net/index.htm 2. The blog post by Andrey Moskvitin (russian language) - http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html 3. cl-mongrel2 - https://github.com/vseloved/cl-mongrel2 4. http://www.weitz.de/hunchentoot/#history From archimag at gmail.com Mon Feb 21 15:19:49 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Mon, 21 Feb 2011 15:19:49 +0000 Subject: [hunchentoot-devel] web programming api for lisp In-Reply-To: <7731298172974@web10.yandex.ru> References: <7731298172974@web10.yandex.ru> Message-ID: > What do you think about the idea to have a server-independent API for > Web programming in Common Lisp I already have some success in this direction: * Performed general work by moving code from Hunchentoot to in cl-wsal (Common Lisp web servers abstraction layer). * Implemented the minimum necessary functionality of cl-mongrel2 on base cl-wsal * Adapted RESTAS for use with cl-wsal. * I've able run a local version of the site http://lisper.ru/ with using Mongrel2 (instead of Hunchentoot) Thus, the http://lisper.ru/ codebase already now can be used both with Hunchentoot, and with Mongrel2 without any changes. cl-wsal - https://github.com/archimag/cl-wsal cl-mongrel2 (my fork) - https://github.com/archimag/cl-mongrel2 Andrey From marko.kocic at gmail.com Mon Feb 21 16:06:15 2011 From: marko.kocic at gmail.com (=?UTF-8?B?TWFya28gS29jacSH?=) Date: Mon, 21 Feb 2011 17:06:15 +0100 Subject: [hunchentoot-devel] web programming api for lisp In-Reply-To: <7731298172974@web10.yandex.ru> References: <7731298172974@web10.yandex.ru> Message-ID: Clojure community did a pretty good job at using ring [1] as *the* web development api. The concept is quite simple, basically it is a series of transformations of request objects using "handlers" and "middlewares". That approach enables them to have quite a few of libraries [2] that can be mixed and matched between different ring and thirdparty web server implementations and frameworks. [1] https://github.com/mmcgrana/ring [2] https://github.com/mmcgrana/ring/wiki/Libraries Regards, Marko On Sun, Feb 20, 2011 at 4:36 AM, Anton Vodonosov wrote: > Hello. > > What do you think about the idea to have a server-independent API for web > programming in Common Lisp, similar to the Java Servlet API, Ruby Rack, etc. ? > > We may take the current hunchentoot API and use it for other servers. > > For example, we may implement the same request, reply, *dispatch-table*, > sessions, cookies functions as provided by hunchentoot for google app engine > (with ABCL). Then web applications may be freely moved between the > hunchentoot and the google app engine (for course, if they don't depend > on other APIs, like google app engine persistence api). > > Another option, is to use this API to embed ECL into apache or nginx, and > write Common Lisp web applications for these servers. If the API will be based > on hunchentoot, existing and new Common Lisp web applications will be easily > moved between hunchentoot and these servers. > > (Embedding ECL into apache is already possible with mod_ecl[1]. We will > only need to adopt the mod_lisp API to the hunchentoot-like interface, > to make Lisp applications portable. Nginx has embedded perl, therefore it > has an API for external modules; if we embed ECL into nginx, we again > only need to adopt the nginx-specific API to the standard hunchentoot-like form, > and Lisp we applications will become portable between servers). > > But the most interesting option was suggested by Andrey Moskvitin in his > blog [2]: to implement the hunchentoot-like interface for the Mongrel2 web server. > The advantage of this solution is that it will work for any Common Lisp implementation, > but not for only one (ECL or ABCL) as in the previous options. BTW, Mongrel2 > integration for Common Lisp already exists in the form of cl-mongrel2 [3], and > the question is again only in adopting the APIs. > > Even although porting the hunchentoot interface as is to Mongrel2 will not allow to > fully untilize the Mongrel2 high concurrency asynchronous IO features, it > seems like a good improvement in the Common Lisp ecosystem. > > It is roughly clear what parts of the hunchentoot API should turned into cross-server > API: request, reply, cookies, sessions, request dispatch and handling (partially, > only the basic things), conditions and error handling, miscellaneous (partially). > Other parts, like acceptors, taskmasters, logging are not the interface > between web application and server but rather the web server startup and > configuration API. > > Writing an actual implementation for another web server will clarify the > questionable points. > > And Andrey Moskvitin has yesterday started implementing the hucnentoot > interfece for Mongrel2, therefore we have chances to see it soon. The parts Andrey > quickly extracted from the hunchentoot codebase for the web server independent > API may be found here: https://github.com/archimag/cl-wsal. > > As you may notice, small incompatibility exists: huncentoot-error become wsal-error. > There is also a peace of code from chunga: know-words.lisp. Andrey told us he > just took everything is needed to make the interface code compilable. > > The question for hunchentoot developers and community: in case of successful > implementation of the hunchentoot-like API on other web servers, do you think > it is good for hunchentoot itself to split its API into two parts: abstract web server > interface shared with other servers, and actual common lisp implemented web > server providing this interface? > > Interestingly, hunchentoot emerged from a library to talk to mod_lisp and > other front-ends [4]. > > Today, when hunchentoot is highly adopted, it seems reasonable to pick out > it's web programming API into a separate module, and share this API > between hunchentoot and other front-end adapters, maybe other > common lisp web servers, etc. And this will not add implementation > complexity to the hunchentoot itself (which was the cause of the > mod_lisp support removal in the 1.0 release). > > What do you think? > > 1. mod_ecl - http://mod-ecl.sourceforge.net/index.htm > 2. The blog post by Andrey Moskvitin (russian language) - > ? ?http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html > 3. cl-mongrel2 - https://github.com/vseloved/cl-mongrel2 > 4. http://www.weitz.de/hunchentoot/#history > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From vseloved at gmail.com Mon Feb 21 16:10:14 2011 From: vseloved at gmail.com (Vsevolod Dyomkin) Date: Mon, 21 Feb 2011 18:10:14 +0200 Subject: [hunchentoot-devel] web programming api for lisp In-Reply-To: References: <7731298172974@web10.yandex.ru> Message-ID: Yeah, I also wanted to write about that. There's a good talk on the topic: http://blip.tv/file/4706750 Cheers, Vsevolod On Mon, Feb 21, 2011 at 6:06 PM, Marko Koci? wrote: > Clojure community did a pretty good job at using ring [1] as *the* web > development api. > > The concept is quite simple, basically it is a series of > transformations of request objects using "handlers" and "middlewares". > That approach enables them to have quite a few of libraries [2] that > can be mixed and matched between different ring and thirdparty web > server implementations and frameworks. > > [1] https://github.com/mmcgrana/ring > [2] https://github.com/mmcgrana/ring/wiki/Libraries > > Regards, > Marko > > On Sun, Feb 20, 2011 at 4:36 AM, Anton Vodonosov > wrote: > > Hello. > > > > What do you think about the idea to have a server-independent API for web > > programming in Common Lisp, similar to the Java Servlet API, Ruby Rack, > etc. ? > > > > We may take the current hunchentoot API and use it for other servers. > > > > For example, we may implement the same request, reply, *dispatch-table*, > > sessions, cookies functions as provided by hunchentoot for google app > engine > > (with ABCL). Then web applications may be freely moved between the > > hunchentoot and the google app engine (for course, if they don't depend > > on other APIs, like google app engine persistence api). > > > > Another option, is to use this API to embed ECL into apache or nginx, and > > write Common Lisp web applications for these servers. If the API will be > based > > on hunchentoot, existing and new Common Lisp web applications will be > easily > > moved between hunchentoot and these servers. > > > > (Embedding ECL into apache is already possible with mod_ecl[1]. We will > > only need to adopt the mod_lisp API to the hunchentoot-like interface, > > to make Lisp applications portable. Nginx has embedded perl, therefore it > > has an API for external modules; if we embed ECL into nginx, we again > > only need to adopt the nginx-specific API to the standard > hunchentoot-like form, > > and Lisp we applications will become portable between servers). > > > > But the most interesting option was suggested by Andrey Moskvitin in his > > blog [2]: to implement the hunchentoot-like interface for the Mongrel2 > web server. > > The advantage of this solution is that it will work for any Common Lisp > implementation, > > but not for only one (ECL or ABCL) as in the previous options. BTW, > Mongrel2 > > integration for Common Lisp already exists in the form of cl-mongrel2 > [3], and > > the question is again only in adopting the APIs. > > > > Even although porting the hunchentoot interface as is to Mongrel2 will > not allow to > > fully untilize the Mongrel2 high concurrency asynchronous IO features, it > > seems like a good improvement in the Common Lisp ecosystem. > > > > It is roughly clear what parts of the hunchentoot API should turned into > cross-server > > API: request, reply, cookies, sessions, request dispatch and handling > (partially, > > only the basic things), conditions and error handling, miscellaneous > (partially). > > Other parts, like acceptors, taskmasters, logging are not the interface > > between web application and server but rather the web server startup and > > configuration API. > > > > Writing an actual implementation for another web server will clarify the > > questionable points. > > > > And Andrey Moskvitin has yesterday started implementing the hucnentoot > > interfece for Mongrel2, therefore we have chances to see it soon. The > parts Andrey > > quickly extracted from the hunchentoot codebase for the web server > independent > > API may be found here: https://github.com/archimag/cl-wsal. > > > > As you may notice, small incompatibility exists: huncentoot-error become > wsal-error. > > There is also a peace of code from chunga: know-words.lisp. Andrey told > us he > > just took everything is needed to make the interface code compilable. > > > > The question for hunchentoot developers and community: in case of > successful > > implementation of the hunchentoot-like API on other web servers, do you > think > > it is good for hunchentoot itself to split its API into two parts: > abstract web server > > interface shared with other servers, and actual common lisp implemented > web > > server providing this interface? > > > > Interestingly, hunchentoot emerged from a library to talk to mod_lisp and > > other front-ends [4]. > > > > Today, when hunchentoot is highly adopted, it seems reasonable to pick > out > > it's web programming API into a separate module, and share this API > > between hunchentoot and other front-end adapters, maybe other > > common lisp web servers, etc. And this will not add implementation > > complexity to the hunchentoot itself (which was the cause of the > > mod_lisp support removal in the 1.0 release). > > > > What do you think? > > > > 1. mod_ecl - http://mod-ecl.sourceforge.net/index.htm > > 2. The blog post by Andrey Moskvitin (russian language) - > > http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html > > 3. cl-mongrel2 - https://github.com/vseloved/cl-mongrel2 > > 4. http://www.weitz.de/hunchentoot/#history > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetmonk at gmail.com Sun Feb 27 23:34:46 2011 From: jetmonk at gmail.com (JTK) Date: Sun, 27 Feb 2011 13:34:46 -1000 Subject: [hunchentoot-devel] Hunchentoot examples aren't working for me Message-ID: <702CF10D-81A2-46E7-AB1D-8EDAFDA13BDE@gmail.com> Hello, I'm on a 10.6 mac, running sbcl and ccl/openmcl inside slime. I tried installing the latest svn hunchetoot from bknr-svn, replacing my old version of h'toot and the supporting libraries with the whole tree. Then I followed the instructions for the example server: (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name) (setf (hunchentoot:content-type*) "text/plain") (format nil "Hey~@[ ~A~]!" name)) ==> SAY-YO Now the main page http://127.0.0.1:4242/ is OK - I see 'Welcome' and the doc tree. But http://127.0.0.1:4242/yo gives "Resource /yo not found" Similarly, (asdf:oos 'asdf:load-op :hunchentoot-test) loads But http://127.0.0.1:4242/hunchentoot/test give 'resource not found.' Is there anything obvious that I'm doing wrong? (Also, for some reason sbcl didn't like the fact that babel didn't have the positive-fixnum type defined, so I defined it. CCL was OK with babel as it was.) Thanks, John Klein From andrew.pennebaker at gmail.com Mon Feb 28 03:19:40 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Sun, 27 Feb 2011 22:19:40 -0500 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: Message-ID: The "New York version" (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) creates a stalling web server, never loading, never error'ing. When I remove the code :ready-only t from line 377: (when (usocket:wait-for-input listener :timeout +new-connection-wait-time+) The New York version works fine. Specs: - Hunchentoot 1.1.1 - Quicklisp - CLISP - Mac OS X -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Mon Feb 28 09:17:19 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 28 Feb 2011 10:17:19 +0100 Subject: [hunchentoot-devel] Hunchentoot examples aren't working for me In-Reply-To: <702CF10D-81A2-46E7-AB1D-8EDAFDA13BDE@gmail.com> References: <702CF10D-81A2-46E7-AB1D-8EDAFDA13BDE@gmail.com> Message-ID: On Mon, Feb 28, 2011 at 12:34 AM, JTK wrote: > Then I followed the instructions for the example server: > > (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) This is the problem, you'll need to change this to: (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)) The easy handler framework is now optional. To use it, the easy-acceptor class must be used. I'll fix the documentation. > (Also, for some reason sbcl didn't like the fact that babel didn't have the ?positive-fixnum type > defined, so I defined it. ?CCL was OK with babel as it was.) I'm not normally using SBCL, but I quickly tried 1.0.29 on my machine and had no problem. From what you report, it seems to be a Babel problem anyway, right? Is your Babel version up to date with respect to your SBCL? Thank you for reporting the problem! Hans From hans.huebner at gmail.com Mon Feb 28 09:19:06 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 28 Feb 2011 10:19:06 +0100 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: Message-ID: On Mon, Feb 28, 2011 at 4:19 AM, Andrew Pennebaker wrote: > The "New York version" (hunchentoot:start (make-instance > 'hunchentoot:acceptor :port 4242)) > creates a stalling web server, never loading, never error'ing. > When I remove the code?:ready-only t from line 377: > (when (usocket:wait-for-input listener :timeout +new-connection-wait-time+) > The New York version works fine. > Specs: > > Hunchentoot 1.1.1 > Quicklisp > CLISP > Mac OS X This sounds like a bug in CLISP or usocket. Usocket guys, do you know something about READY-ONLY on CLISP? -Hans From jetmonk at gmail.com Mon Feb 28 09:40:22 2011 From: jetmonk at gmail.com (JTK) Date: Sun, 27 Feb 2011 23:40:22 -1000 Subject: [hunchentoot-devel] Hunchentoot examples aren't working for me In-Reply-To: References: <702CF10D-81A2-46E7-AB1D-8EDAFDA13BDE@gmail.com> Message-ID: On Feb 27, 2011, at 11:17 PM, Hans H?bner wrote: > From what you report, it seems to be a Babel > problem anyway, right? Is your Babel version up to date with respect > to your SBCL? I think so. I downloaded the entire bknr-svn svn archive. This is for sbcl 1.0.39 rather than 29. The absence of positive-fixnum was a minor glitch and if no one else reports it, it should be ignored, probably. Apparently the positive-fixum type is defined in alexandria, but in some complicated macro. Thank you for fixing the docs. Hunchentoot worked before for me, so I was baffled why the new one didn't. J.Klein From andrew.pennebaker at gmail.com Mon Feb 28 11:41:23 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Mon, 28 Feb 2011 06:41:23 -0500 Subject: [hunchentoot-devel] Hunchentoot examples aren't working for me In-Reply-To: References: <702CF10D-81A2-46E7-AB1D-8EDAFDA13BDE@gmail.com> Message-ID: (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)) *** - READ from # #> : # has no external symbol with name "EASY-ACCEPTOR" On Mon, Feb 28, 2011 at 4:40 AM, JTK wrote: > > On Feb 27, 2011, at 11:17 PM, Hans H?bner wrote: > > > From what you report, it seems to be a Babel > > problem anyway, right? Is your Babel version up to date with respect > > to your SBCL? > > > I think so. I downloaded the entire bknr-svn svn archive. > This is for sbcl 1.0.39 rather than 29. The absence of positive-fixnum > was a minor glitch and if no one else reports it, it should be ignored, > probably. > Apparently the positive-fixum type is defined in > alexandria, but in some complicated macro. > > Thank you for fixing the docs. Hunchentoot worked before for me, so I was > baffled why the new one didn't. > > > J.Klein > > > > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Mon Feb 28 13:15:42 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 28 Feb 2011 14:15:42 +0100 Subject: [hunchentoot-devel] Hunchentoot examples aren't working for me In-Reply-To: References: <702CF10D-81A2-46E7-AB1D-8EDAFDA13BDE@gmail.com> Message-ID: On Mon, Feb 28, 2011 at 12:41 PM, Andrew Pennebaker wrote: > (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242)) > *** - READ from > ?? ? ? # > ?? ? ? ? #> > ?? ? ?: # has no external symbol with name > ?? ? ?"EASY-ACCEPTOR" Are you running the Subversion trunk version of Hunchentoot? -Hans > On Mon, Feb 28, 2011 at 4:40 AM, JTK wrote: >> >> On Feb 27, 2011, at 11:17 PM, Hans H?bner wrote: >> >> > From what you report, it seems to be a Babel >> > problem anyway, right? ?Is your Babel version up to date with respect >> > to your SBCL? >> >> >> I think so. ?I downloaded the entire ?bknr-svn svn archive. >> This is for sbcl 1.0.39 rather than 29. ?The absence of positive-fixnum >> ?was a minor glitch and if no one else reports it, it should be ignored, >> probably. >> Apparently the positive-fixum type is defined in >> alexandria, but in some complicated macro. >> >> Thank you for fixing the docs. ?Hunchentoot worked before for me, so I was >> baffled why the new one didn't. >> >> >> J.Klein >> >> >> >> >> >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From dlw at itasoftware.com Mon Feb 28 19:11:42 2011 From: dlw at itasoftware.com (Daniel Weinreb) Date: Mon, 28 Feb 2011 14:11:42 -0500 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: Message-ID: <4D6BF36E.2080106@itasoftware.com> That's interesting. We ran into a problem here which I had to fix by changing the default value of the read-only keyword parameter of wait-for-input from nil to t. I got some explanation of wait-for-input from Erik Huelsmann, who designed this stuff. I sent him back some suggestions and questions, but I don't think I got an answer. The real question is whether Hunchentoot is interacting properly with usocket. I haven't checked to see whether we are currently using the very latest usocket library here. Andrew Pennebaker wrote: > The "New York version" (hunchentoot:start (make-instance > 'hunchentoot:acceptor :port 4242)) > > creates a stalling web server, never loading, never error'ing. > > When I remove the code :ready-only t from line 377: > > (when (usocket:wait-for-input listener :timeout > +new-connection-wait-time+) > > The New York version works fine. > > Specs: > > * Hunchentoot 1.1.1 > * Quicklisp > * CLISP > * Mac OS X > > ------------------------------------------------------------------------ > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.pennebaker at gmail.com Mon Feb 28 20:32:13 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Mon, 28 Feb 2011 15:32:13 -0500 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: <4D6BF36E.2080106@itasoftware.com> References: <4D6BF36E.2080106@itasoftware.com> Message-ID: I finally got the New York version to work, but only with Lispbox CCL. Any other flavor of Common Lisp gives me trouble. On Mon, Feb 28, 2011 at 2:11 PM, Daniel Weinreb wrote: > That's interesting. We ran into a problem here which I > had to fix by changing the default value of the read-only > keyword parameter of wait-for-input from nil to t. > > I got some explanation of wait-for-input from Erik > Huelsmann, who designed this stuff. I sent him > back some suggestions and questions, but I > don't think I got an answer. The real > question is whether Hunchentoot is interacting > properly with usocket. > > I haven't checked to see whether we are currently > using the very latest usocket library here. > > Andrew Pennebaker wrote: > > The "New York version" (hunchentoot:start (make-instance > 'hunchentoot:acceptor :port 4242)) > > creates a stalling web server, never loading, never error'ing. > > When I remove the code :ready-only t from line 377: > > (when (usocket:wait-for-input listener :timeout > +new-connection-wait-time+) > > The New York version works fine. > > Specs: > > - Hunchentoot 1.1.1 > - Quicklisp > - CLISP > - Mac OS X > > ------------------------------ > > _______________________________________________ > tbnl-devel site listtbnl-devel at common-lisp.nethttp://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at weitz.de Mon Feb 28 21:16:55 2011 From: edi at weitz.de (Edi Weitz) Date: Mon, 28 Feb 2011 22:16:55 +0100 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker wrote: > I finally got the New York version to work, but only with Lispbox CCL. Any > other flavor of Common Lisp gives me trouble. What exactly does "any other flavor" mean? Which ones did you try on which platforms?