From jetmonk at gmail.com Fri Apr 1 06:43:38 2011 From: jetmonk at gmail.com (JTK) Date: Thu, 31 Mar 2011 20:43:38 -1000 Subject: [hunchentoot-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: <5A4213B9-FC24-4C46-9FB6-437AAF382E59@gmail.com> References: <5A4213B9-FC24-4C46-9FB6-437AAF382E59@gmail.com> Message-ID: <11FF5BD7-BDB0-4B8B-838B-B5C6AAB572F0@gmail.com> I hope it is OK to send this to both the hunchentoot and cl+ssl lists. I think it is relevant to both. I've appended a test case in which I think I may have found the source of hunchentoot's problems with ssl and concurrency. Code containing good and bad toy servers is attached at end of email. Apologies in advance if this is way out in left field. Here's my explanation - the comments in the code explain it in greater detail. It appears that if you run a main listener thread and turn a client connection into an SSL socket using cl+ssl:make-ssl-server-stream within the main listener, and pass this ssl-socket to a child thread, then things work. However, if you pass the raw socket to the child thread, and the child thread itself runs cl+ssl:make-ssl-server-stream, then SSL can fail and crash lisp if there are concurrent connections. It seems that hunchentoot passes the job of running cl+ssl:make-ssl-server-stream to child threads, as described in the comments to the code. I'd be interested if people agree with the diagnosis. I'm not really clear on what the broader repercussions of moving the initialization are, so I haven't patched hunchentoot. (plus I might not have more time for a while). John -------------- next part -------------- A non-text attachment was scrubbed... Name: example-threaded.lisp Type: application/octet-stream Size: 5083 bytes Desc: not available URL: From hans.huebner at gmail.com Fri Apr 1 11:59:40 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 1 Apr 2011 13:59:40 +0200 Subject: [hunchentoot-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: <11FF5BD7-BDB0-4B8B-838B-B5C6AAB572F0@gmail.com> References: <5A4213B9-FC24-4C46-9FB6-437AAF382E59@gmail.com> <11FF5BD7-BDB0-4B8B-838B-B5C6AAB572F0@gmail.com> Message-ID: Hi, David L. has looked into this problem briefly and reports that the problem really is that cl+ssl is not thread safe as it currently stands. Fixing that is possible, but it is not entirely straightforward as cl+ssl needs to include a C file that implements functions to ensure thread safety. Until that has been fixed, I would propose to make SSL and multi-threading in Hunchentoot incompatible. Thoughts? -Hans On Fri, Apr 1, 2011 at 8:43 AM, JTK wrote: > > I hope it is OK to send this to both the hunchentoot and cl+ssl lists. ?I think it is relevant to both. > > I've appended a test case in which I think I may have found the source of hunchentoot's problems > with ssl and concurrency. > > Code containing good and bad toy servers is attached at end of email. > > Apologies in advance if this is way out in left field. > > > > > Here's my explanation - the comments in the code explain it in greater detail. > > It appears that if you run a main listener ?thread and turn a client connection > into an SSL socket using cl+ssl:make-ssl-server-stream within the main listener, > and pass this ssl-socket to a child thread, then things work. > > However, if you pass the raw socket to the child thread, and the child thread itself runs > cl+ssl:make-ssl-server-stream, then SSL can fail and crash lisp if there are > concurrent connections. > > It seems that hunchentoot passes the job of running cl+ssl:make-ssl-server-stream > to child threads, as described in the comments to the code. > > I'd be interested if people agree with the diagnosis. ? ? ?I'm not really clear > on what the broader repercussions of moving the initialization are, so > I haven't patched hunchentoot. ?(plus I might not have more time for a while). > > John > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From hans.huebner at gmail.com Fri Apr 1 12:13:36 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 1 Apr 2011 14:13:36 +0200 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: References: Message-ID: Andrey, thank you for your report: On Thu, Mar 31, 2011 at 10:22 AM, Andrey Moskvitin wrote: > A few days ago on the site lisper.ru I started using Hunchentoot from trunk. > And found that the system stopped working in a few hours. I watched the behavior > of the system during the day and found that some threads do not complete their > work and hangs on "finish-ouptut" (in "process-connection"). ?When they > accumulate enough, the work stops. In principle, I am fine with making that change in Hunchentoot. I do wonder what is really going on. The difference between finish-output and force-output is, according to the spec, that finish-output actually waits for the output to have drained, while force-output just initiates the flushing and returns immediately. What you seem to report is that the flushing is not actually terminating when finish-output is used. Just to understand what's going on, what kind of setup did you observe the bad behavior in? Can you reproduce the problem and tell us some more about the connections that seem to be hanging - Are they still in ESTABLISHED or in FIN_WAIT state? It'd be great if you could supply us with some more information. Thanks! Hans From daniel at dbrunner.de Fri Apr 1 13:32:36 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Fri, 01 Apr 2011 15:32:36 +0200 Subject: [hunchentoot-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: References: <5A4213B9-FC24-4C46-9FB6-437AAF382E59@gmail.com> <11FF5BD7-BDB0-4B8B-838B-B5C6AAB572F0@gmail.com> Message-ID: <4D95D3F4.8040506@dbrunner.de> Hi, I tested David's patch and my CCL (LinuxX8664) worked but the SBCL still crashes with --8<-- CORRUPTION WARNING in SBCL pid 13380(tid 140737285650176): Memory fault at 0 (pc=0x7ffff4c7edfd, sp=0x7ffff3eae000) The integrity of this image is possibly compromised. Continuing with fingers crossed. --8<-- Kind regards, Daniel Am 01.04.2011 13:59, schrieb Hans H?bner: > Hi, > > David L. has looked into this problem briefly and reports that the > problem really is that cl+ssl is not thread safe as it currently > stands. Fixing that is possible, but it is not entirely > straightforward as cl+ssl needs to include a C file that implements > functions to ensure thread safety. > > Until that has been fixed, I would propose to make SSL and > multi-threading in Hunchentoot incompatible. > > Thoughts? > -Hans > > On Fri, Apr 1, 2011 at 8:43 AM, JTK wrote: >> >> I hope it is OK to send this to both the hunchentoot and cl+ssl lists. I think it is relevant to both. >> >> I've appended a test case in which I think I may have found the source of hunchentoot's problems >> with ssl and concurrency. >> >> Code containing good and bad toy servers is attached at end of email. >> >> Apologies in advance if this is way out in left field. >> >> >> >> >> Here's my explanation - the comments in the code explain it in greater detail. >> >> It appears that if you run a main listener thread and turn a client connection >> into an SSL socket using cl+ssl:make-ssl-server-stream within the main listener, >> and pass this ssl-socket to a child thread, then things work. >> >> However, if you pass the raw socket to the child thread, and the child thread itself runs >> cl+ssl:make-ssl-server-stream, then SSL can fail and crash lisp if there are >> concurrent connections. >> >> It seems that hunchentoot passes the job of running cl+ssl:make-ssl-server-stream >> to child threads, as described in the comments to the code. >> >> I'd be interested if people agree with the diagnosis. I'm not really clear >> on what the broader repercussions of moving the initialization are, so >> I haven't patched hunchentoot. (plus I might not have more time for a while). >> >> John >> >> >> >> >> _______________________________________________ >> 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 archimag at gmail.com Fri Apr 1 14:02:43 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 1 Apr 2011 18:02:43 +0400 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: References: Message-ID: > Are they still in ESTABLISHED or in FIN_WAIT state? > It'd be great if you could supply us with some more information. Hmm... Threads (via *slime-threads*): 27 repl-thread Running 28 auto-flush-thread Running 29 reader-thread Running 30 control-thread Running 31 hunchentoot-worker-62.78.43.253:8576 Running 7 hunchentoot-listener-*:80 Running 8 Swank 4005 Running 9 initial thread Running Backtrace: Interrupt from Emacs [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Continue from break. 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: ("bogus stack frame") 1: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL) 2: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL) 3: (SB-SYS:SERVE-ALL-EVENTS NIL) 4: (SB-IMPL::FINISH-FD-STREAM-OUTPUT #) 5: (FINISH-OUTPUT #) 6: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) ..) 7: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) ..) 8: ((LAMBDA ())) 9: ((LAMBDA ())) 10: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK358]363)) 11: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 12: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]293)) 13: (SB-THREAD::CALL-WITH-MUTEX ..) 14: (SB-THREAD::INITIAL-THREAD-FUNCTION) 15: ("foreign function: #x4220F0") 16: ("foreign function: #x418D67") But, NETSTAT not show connection to 62.78.43.253:8576. It looks like a bug in SBCL. Andrey From hans.huebner at gmail.com Fri Apr 1 14:14:23 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 1 Apr 2011 16:14:23 +0200 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: References: Message-ID: On Fri, Apr 1, 2011 at 4:02 PM, Andrey Moskvitin wrote: >> Are they still in ESTABLISHED or in FIN_WAIT state? >> It'd be great if you could supply us with some more information. > But, NETSTAT not show connection to 62.78.43.253:8576. It looks like a > bug in SBCL. Thanks for this report - Would you be able to try another SBCL version? Someone else have any ideas? -Hans From archimag at gmail.com Fri Apr 1 14:21:58 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 1 Apr 2011 18:21:58 +0400 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: References: Message-ID: > Would you be able to try another SBCL version? I tested with SBCL 1.0.47 and SBCL 1.0.37. I have not had this problem on a local network, only on http://lisper.ru/. Andrey 2011/4/1 Hans H?bner : > On Fri, Apr 1, 2011 at 4:02 PM, Andrey Moskvitin wrote: >>> Are they still in ESTABLISHED or in FIN_WAIT state? >>> It'd be great if you could supply us with some more information. >> But, NETSTAT not show connection to 62.78.43.253:8576. It looks like a >> bug in SBCL. > > Thanks for this report - Would you be able to try another SBCL > version? ?Someone else have any ideas? > > -Hans > From hans at huebner.org Fri Apr 1 14:30:17 2011 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 1 Apr 2011 16:30:17 +0200 Subject: [hunchentoot-devel] Fwd: (forw) Re: [cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: <20110401142859.GB15213@radon> References: <20110401124056.GA15213@radon> <20110401142859.GB15213@radon> Message-ID: Here is another patch from David, can someone please test on SBCL multithreaded? Thanks! Hans ---------- Forwarded message ---------- From: David Lichteblau Date: Fri, Apr 1, 2011 at 4:28 PM Subject: Re: (forw) Re: [cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution? To: Hans H?bner Quoting Hans H?bner (hans at huebner.org): > Zugegeben, ich habe nur CCL getestet, f?r SBCL hilft es wohl nicht :/ Ein letzter blinder Versuch (alternativ muesste ich doch selbst testen): >From 207a12ea7053643ef53683907e6d894d8ecb5ecd Mon Sep 17 00:00:00 2001 From: David Lichteblau Date: Fri, 1 Apr 2011 16:26:19 +0200 Subject: [PATCH 2/2] Fix thread id computation --- ?ffi.lisp | ? 11 +++++++---- ?1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/ffi.lisp b/ffi.lisp index d773bef..3049c7f 100644 --- a/ffi.lisp +++ b/ffi.lisp @@ -392,11 +392,17 @@ will use this value.") ? ? ? ?(bt:release-recursive-lock lock)))) ?(defvar *threads* (trivial-garbage:make-weak-hash-table :weakness :key)) +(defvar *thread-counter* 0) +(defparameter *initialization-lock* + ? ?(bordeaux-threads:make-recursive-lock "SSL initialization")) ?(cffi:defcallback threadid-callback :unsigned-long () ? (let ((self (bt:current-thread))) ? ? (or (gethash self *threads*) - ? ? ? (setf (gethash self *threads*) (hash-table-count *threads*))))) + ? ? ? (setf (gethash self *threads*) + ? ? ? ? ? ? (bordeaux-threads:with-recursive-lock-held + ? ? ? ? ? ? ? ? (*initialization-lock*) + ? ? ? ? ? ? ? (incf *thread-counter*)))))) ?(defun initialize (&key (method 'ssl-v23-method) rand-seed) ? (setf *locks* (loop @@ -415,9 +421,6 @@ will use this value.") ? (ssl-ctx-set-default-passwd-cb *ssl-global-context* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(cffi:callback pem-password-callback))) -(defparameter *initialization-lock* - ? ?(bordeaux-threads:make-recursive-lock "SSL initialization")) - ?(defun ensure-initialized (&key (method 'ssl-v23-method) (rand-seed nil)) ? "In most cases you do *not* need to call this function, because it ?is called automatically by all other functions. The only reason to -- 1.7.0 From daniel at dbrunner.de Fri Apr 1 15:04:40 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Fri, 01 Apr 2011 17:04:40 +0200 Subject: [hunchentoot-devel] Fwd: (forw) Re: [cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: References: <20110401124056.GA15213@radon> <20110401142859.GB15213@radon> Message-ID: <4D95E988.8090303@dbrunner.de> I hope that I applied the patch properly. But the problem still exists on SBCL 1.0.46 on Linux8664. Kind regards, Daniel. Am 01.04.2011 16:30, schrieb Hans H?bner: > Here is another patch from David, can someone please test on SBCL multithreaded? > > Thanks! > Hans > > > ---------- Forwarded message ---------- > From: David Lichteblau > Date: Fri, Apr 1, 2011 at 4:28 PM > Subject: Re: (forw) Re: [cl-plus-ssl-devel] ssl crashing in > hunchentoot. A solution? > To: Hans H?bner > > > Quoting Hans H?bner (hans at huebner.org): >> Zugegeben, ich habe nur CCL getestet, f?r SBCL hilft es wohl nicht :/ > > Ein letzter blinder Versuch (alternativ muesste ich doch selbst testen): > >>From 207a12ea7053643ef53683907e6d894d8ecb5ecd Mon Sep 17 00:00:00 2001 > From: David Lichteblau > Date: Fri, 1 Apr 2011 16:26:19 +0200 > Subject: [PATCH 2/2] Fix thread id computation > > --- > ffi.lisp | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/ffi.lisp b/ffi.lisp > index d773bef..3049c7f 100644 > --- a/ffi.lisp > +++ b/ffi.lisp > @@ -392,11 +392,17 @@ will use this value.") > (bt:release-recursive-lock lock)))) > > (defvar *threads* (trivial-garbage:make-weak-hash-table :weakness :key)) > +(defvar *thread-counter* 0) > +(defparameter *initialization-lock* > + (bordeaux-threads:make-recursive-lock "SSL initialization")) > > (cffi:defcallback threadid-callback :unsigned-long () > (let ((self (bt:current-thread))) > (or (gethash self *threads*) > - (setf (gethash self *threads*) (hash-table-count *threads*))))) > + (setf (gethash self *threads*) > + (bordeaux-threads:with-recursive-lock-held > + (*initialization-lock*) > + (incf *thread-counter*)))))) > > (defun initialize (&key (method 'ssl-v23-method) rand-seed) > (setf *locks* (loop > @@ -415,9 +421,6 @@ will use this value.") > (ssl-ctx-set-default-passwd-cb *ssl-global-context* > (cffi:callback pem-password-callback))) > > -(defparameter *initialization-lock* > - (bordeaux-threads:make-recursive-lock "SSL initialization")) > - > (defun ensure-initialized (&key (method 'ssl-v23-method) (rand-seed nil)) > "In most cases you do *not* need to call this function, because it > is called automatically by all other functions. The only reason to > -- > 1.7.0 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From archimag at gmail.com Fri Apr 1 15:19:15 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 1 Apr 2011 19:19:15 +0400 Subject: [hunchentoot-devel] Fwd: (forw) Re: [cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: <4D95E988.8090303@dbrunner.de> References: <20110401124056.GA15213@radon> <20110401142859.GB15213@radon> <4D95E988.8090303@dbrunner.de> Message-ID: > But the problem still exists on SBCL 1.0.46 on Linux8664. In latest releases of SBCL had problems with the FFI. But in SBCL 1.0.47, they seem be solved. For SBCL 1.0.46 makes no sense test it, better switch to SBCL 1.0.47. Andrey From prytane at gmail.com Fri Apr 1 15:32:28 2011 From: prytane at gmail.com (G Horiske) Date: Fri, 1 Apr 2011 08:32:28 -0700 Subject: [hunchentoot-devel] Support for PUT and DELETE HTTP Verbs? Message-ID: I'm considering using HT as a back-end RESTful web service for an Adobe Flex client. Does HT support the PUT and DELETE HTTP verbs? If so, how does one use them? I see from the docs that the "define-easy-handler has a "request-type" parameter that accepts "GET", "POST", or "BOTH". Is there any chance "PUT" and "DELETE" have been added recently? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at dbrunner.de Fri Apr 1 15:34:39 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Fri, 01 Apr 2011 17:34:39 +0200 Subject: [hunchentoot-devel] Fwd: (forw) Re: [cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: References: <20110401124056.GA15213@radon> <20110401142859.GB15213@radon> <4D95E988.8090303@dbrunner.de> Message-ID: <4D95F08F.9050501@dbrunner.de> Good point, Andrey, I missed that. I testet it with 1.0.47 on LinuxX8664 but it still crashes. If I use the single threaded taskmaster it works. Therefore I suppose the problems lies in the multi-threading. Daniel. Am 01.04.2011 17:19, schrieb Andrey Moskvitin: >> But the problem still exists on SBCL 1.0.46 on Linux8664. > > In latest releases of SBCL had problems with the FFI. But in SBCL 1.0.47, > they seem be solved. For SBCL 1.0.46 makes no sense test it, better > switch to SBCL 1.0.47. > > Andrey > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From archimag at gmail.com Fri Apr 1 15:52:52 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 1 Apr 2011 19:52:52 +0400 Subject: [hunchentoot-devel] Support for PUT and DELETE HTTP Verbs? In-Reply-To: References: Message-ID: > Does HT support the PUT and DELETE HTTP verbs? Yes, of course. hunchentoot:request-method and hunchentoot:request-method* returns a request type. > RESTful > define-easy-handler define-easy-handler ill for REST. I develop RESTAS web framework (based on Hunchentoot) with RESTful in mind. Look http://restas.lisper.ru/en/manual/routes.html. You can easily install RESTAS via quicklisp. Andrey From edi at weitz.de Fri Apr 1 17:24:47 2011 From: edi at weitz.de (Edi Weitz) Date: Fri, 1 Apr 2011 19:24:47 +0200 Subject: [hunchentoot-devel] Support for PUT and DELETE HTTP Verbs? In-Reply-To: References: Message-ID: On Fri, Apr 1, 2011 at 5:32 PM, G Horiske wrote: > I'm considering using HT as a back-end RESTful web service for an Adobe Flex > client.? Does HT support the PUT and DELETE HTTP verbs?? If so, how does one > use them? In addition to looking at RESTAS, you might also want to look at the source code of CL-WEBDAV. > I see from the docs that the "define-easy-handler has a "request-type" > parameter that accepts "GET", "POST", or "BOTH".? Is there any chance "PUT" > and "DELETE" have been added recently? DEFINE-EASY-HANDLER is not meant to be Hunchentoot's Swiss Army Knife. It's just a convenience macro to write simple "standard" handlers. Edi. From fbogdanovic at xnet.hr Sun Apr 3 10:23:53 2011 From: fbogdanovic at xnet.hr (Haris) Date: Sun, 3 Apr 2011 12:23:53 +0200 Subject: [hunchentoot-devel] ht-simple-ajax Message-ID: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> Hi. I hope I can ask questions about ht-simple-ajax here. If not, please tell me where I can. I'm trying out ht-simple-ajax but it doesn't work. I have: (defparameter *ajax-processor* (make-instance 'ajax-processor :server-uri "/ajax")) (defun-ajax say-hi (name) (*ajax-processor*) (concatenate 'string "Hi " name)) (setq *dispatch-table* (list 'dispatch-easy-handlers (create-ajax-dispatcher *ajax-processor*))) And then I go to: http://localhost/ajax/SAY-HI?name=Martin but nothing happens ? Thanks From andy.arvid at gmail.com Sun Apr 3 11:05:42 2011 From: andy.arvid at gmail.com (Andy Peterson) Date: Sun, 3 Apr 2011 07:05:42 -0400 Subject: [hunchentoot-devel] ht-simple-ajax In-Reply-To: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> Message-ID: Did you start the Hunchentoot web server? (defparameter *my-server* (start (make-instance 'acceptor :address "localhost" :port 8000))) I tested the example on?http://martin-loetzsch.de/ht-simple-ajax/?and it worked for me. andy On Sun, Apr 3, 2011 at 6:23 AM, Haris wrote: > > Hi. > > I hope I can ask questions about ht-simple-ajax here. If not, please tell me > where I can. > I'm trying out ht-simple-ajax but it doesn't work. I have: > > (defparameter *ajax-processor* > ?(make-instance 'ajax-processor :server-uri "/ajax")) > > (defun-ajax say-hi (name) (*ajax-processor*) > ?(concatenate 'string "Hi " name)) > > (setq *dispatch-table* (list 'dispatch-easy-handlers > ? ? ? ? ? ? ? ? ? ? ? ? ? ? (create-ajax-dispatcher *ajax-processor*))) > > And then I go to: > http://localhost/ajax/SAY-HI?name=Martin > but nothing happens ? > > Thanks > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans.huebner at gmail.com Sun Apr 3 13:26:52 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 3 Apr 2011 15:26:52 +0200 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: References: Message-ID: On Fri, Apr 1, 2011 at 4:21 PM, Andrey Moskvitin wrote: >> Would you be able to try another SBCL version? > > I tested with SBCL 1.0.47 and SBCL 1.0.37. I have not had this problem on > a local network, only on http://lisper.ru/. I have made the change, as there does not seem to be any downside. -Hans From fbogdanovic at xnet.hr Sun Apr 3 14:37:31 2011 From: fbogdanovic at xnet.hr (Haris) Date: Sun, 3 Apr 2011 16:37:31 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> Message-ID: <3D73C9880A5C455C873FDA2F7ED7CA93@komp> Here is the complete code, (I start Hunchentoot from REPL and use parenscript) (defpackage :ajax (:use :cl :hunchentoot :cl-who :parenscript :ht-simple-ajax)) (in-package ajax) (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") (setf *js-string-delimiter* #\") (defparameter *ajax-processor* (make-instance 'ajax-processor :server-uri "/ajax")) (defun-ajax say-hi (name) (*ajax-processor*) (concatenate 'string "Hi " name)) (define-easy-handler (main-page :uri "/") () (with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" (:head (:title "ht-simple-ajax demo") (princ (generate-prologue *ajax-processor*)) (:script :type "text/javascript" (str (ps (defun callback (response) (alert (@ response firstChild firstChild nodeValue))) (defun sayHi () (ajax_say_hi (chain document (getElementById "name") value) callback)))))) (:body (:p "Please enter your name: " (:input :id "name" :type "text")) (:p (:a :href "javascript:sayHi()" "Say Hi!")))))) From andy.arvid at gmail.com Sun Apr 3 15:31:37 2011 From: andy.arvid at gmail.com (Andy Peterson) Date: Sun, 3 Apr 2011 11:31:37 -0400 Subject: [hunchentoot-devel] ht-simple-ajax In-Reply-To: <3D73C9880A5C455C873FDA2F7ED7CA93@komp> References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> <3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: I see two problems: 1. You do not inform Hunchentoot about your ajax-dispatcher you need to add this: (setq *dispatch-table* (list 'dispatch-easy-handlers (create-ajax-dispatcher *ajax-processor*))) above as in the example of ht-simple-ajax. Instead, I normally use: (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) 2. Do not use camel-case in parenscript. Parenscript is not case-sensitive. Parenscript uses the lisp standard of hyphens which translates to the javascript standard camel-case. AJAX> (ps getElementByID) "getelementbyid;" AJAX> (ps firstChild) "firstchild;" AJAX> (ps get-element-by-id) "getElementById;" AJAX> (ps first-child) "firstChild;" Similarly See also "sayHi" and "nodeValue" On Sun, Apr 3, 2011 at 10:37 AM, Haris wrote: > Here is the complete code, > (I start Hunchentoot from REPL and use parenscript) > > (defpackage :ajax (:use :cl :hunchentoot :cl-who :parenscript > :ht-simple-ajax)) > (in-package ajax) > > (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") > (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") > > (setf *js-string-delimiter* #\") > > (defparameter *ajax-processor* > ?(make-instance 'ajax-processor :server-uri "/ajax")) > > (defun-ajax say-hi (name) (*ajax-processor*) > ?(concatenate 'string "Hi " name)) > > (define-easy-handler (main-page :uri "/") () > ?(with-html-output-to-string (*standard-output* nil :prologue t :indent t) > ? ?(:html :xmlns "http://www.w3.org/1999/xhtml" > ? ? (:head > ? ? ?(:title "ht-simple-ajax demo") > ? ? ?(princ (generate-prologue *ajax-processor*)) > ? ? ?(:script :type "text/javascript" > ? ? ? (str > ? ? ? ?(ps > ? ? ? ? ?(defun callback (response) > ? ? ? ? ? ?(alert (@ response firstChild firstChild nodeValue))) > > ? ? ? ?(defun sayHi () > ? ? ? ? ?(ajax_say_hi (chain document (getElementById "name") value) > callback)))))) > > ? ? (:body > ? ? ?(:p "Please enter your name: " > ? ? ? ? ?(:input :id "name" :type "text")) > ? ? ?(:p (:a :href "javascript:sayHi()" "Say Hi!")))))) > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From fbogdanovic at xnet.hr Sun Apr 3 17:40:39 2011 From: fbogdanovic at xnet.hr (Haris) Date: Sun, 3 Apr 2011 19:40:39 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp><3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: I changed the code. When I click on say-hi link it goes to: http://localhost/sayHi(); and the page says: Hunchentoot Default page. Where is the problem now ? ------------------------------------------------------------------------------------------------------ (defpackage :ajax (:use :cl :hunchentoot :cl-who :parenscript :ht-simple-ajax)) (in-package ajax) (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") (setf *js-string-delimiter* #\") (defparameter *ajax-processor* (make-instance 'ajax-processor :server-uri "/ajax")) (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) (defun-ajax say-hi (name) (*ajax-processor*) (concatenate 'string "Hi " name)) (define-easy-handler (main-page :uri "/") () (with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" (:head (:title "ht-simple-ajax demo") (princ (generate-prologue *ajax-processor*)) (:script :type "text/javascript" (str (ps (defun callback (response) (alert (@ response first-child first-child node-value))) (defun say-hi () (ajax_say_hi (chain document (get-element-by-id "name") value) callback)))))) (:body (:p "Please enter your name: " (:input :id "name" :type "text")) (:p (:a :href (ps (say-hi)) "Say Hi!")))))) From andy.arvid at gmail.com Sun Apr 3 21:48:37 2011 From: andy.arvid at gmail.com (Andy Peterson) Date: Sun, 3 Apr 2011 17:48:37 -0400 Subject: [hunchentoot-devel] ht-simple-ajax In-Reply-To: References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> <3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: Use the parenscript function ps-inline instead of ps (:a :href (ps-inline (say-hi)) "Say Hi!") AJAX> (ps-inline (say-hi)) "javascript:sayHi()" On Sun, Apr 3, 2011 at 1:40 PM, Haris wrote: > I changed the code. When I click on say-hi link it goes to: > http://localhost/sayHi(); > and the page says: Hunchentoot Default page. > Where is the problem now ? > > ------------------------------------------------------------------------------------------------------ > > (defpackage :ajax (:use :cl :hunchentoot :cl-who :parenscript > :ht-simple-ajax)) > (in-package ajax) > > (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") > (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") > > (setf *js-string-delimiter* #\") > > (defparameter *ajax-processor* > ?(make-instance 'ajax-processor :server-uri "/ajax")) > > (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) > > (defun-ajax say-hi (name) (*ajax-processor*) > ?(concatenate 'string "Hi " name)) > > (define-easy-handler (main-page :uri "/") () > ?(with-html-output-to-string (*standard-output* nil :prologue t :indent t) > ? ?(:html :xmlns "http://www.w3.org/1999/xhtml" > ? ? (:head > ? ? ?(:title "ht-simple-ajax demo") > ? ? ?(princ (generate-prologue *ajax-processor*)) > ? ? ?(:script :type "text/javascript" > ? ? ? (str > ? ? ? ?(ps > ? ? ? ? ?(defun callback (response) > ? ? ? ? ? ?(alert (@ response first-child first-child node-value))) > > ? ? ? ?(defun say-hi () > ? ? ? ? ?(ajax_say_hi (chain document (get-element-by-id "name") value) > callback)))))) > > ? ? (:body > ? ? ?(:p "Please enter your name: " > ? ? ? ? ?(:input :id "name" :type "text")) > ? ? ?(:p (:a :href (ps (say-hi)) "Say Hi!")))))) > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From fbogdanovic at xnet.hr Sun Apr 3 23:10:22 2011 From: fbogdanovic at xnet.hr (Haris) Date: Mon, 4 Apr 2011 01:10:22 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp><3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: > Use the parenscript function ps-inline instead of ps > (:a :href (ps-inline (say-hi)) "Say Hi!") I did that and now when I click Say hi link I just get Error on page on the bottom of the page, javascript error I guess. Here is html generated from my code, maybe the error is more obvious this way --------------------------------------------------------------------------------- ht-simple-ajax demo

Please enter your name:

Say Hi!

From jetmonk at gmail.com Mon Apr 4 00:51:11 2011 From: jetmonk at gmail.com (JTK) Date: Sun, 3 Apr 2011 14:51:11 -1000 Subject: [hunchentoot-devel] ssl crashing in hunchentoot. ssl patch works in CCL, but not SBCL on mac In-Reply-To: <20110403132626.GB15221@radon> References: <5A4213B9-FC24-4C46-9FB6-437AAF382E59@gmail.com> <11FF5BD7-BDB0-4B8B-838B-B5C6AAB572F0@gmail.com> <20110401123854.GA15221@radon> <20110403132626.GB15221@radon> Message-ID: <5C17BF6E-1F63-4B5C-A1C0-1D08B148EA1F@gmail.com> [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 at lichteblau.com): >> Quoting JTK (jetmonk at 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 at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel From andy.arvid at gmail.com Mon Apr 4 01:21:01 2011 From: andy.arvid at gmail.com (Andy Peterson) Date: Sun, 3 Apr 2011 21:21:01 -0400 Subject: [hunchentoot-devel] ht-simple-ajax In-Reply-To: References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> <3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: Your html is correct and works. I used hunchentoot to dispatch it as a static html file and it communicates with the ajax-processor I created from your previous code. The problem is probably with your ajax response. If using chrome, developer tools will show the ajax request/response. If using Firefox, use firebug. andy On Sun, Apr 3, 2011 at 7:10 PM, Haris wrote: >> Use the parenscript function ps-inline instead of ps >> (:a :href (ps-inline (say-hi)) "Say Hi!") > > I did that and now when I click Say hi link I just get Error on page on the > bottom of the page, javascript error I guess. > Here is html generated from my code, maybe the error is more obvious this > way > > --------------------------------------------------------------------------------- > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > > ? > ? ? > ? ? ?ht-simple-ajax demo > ? ? > ? ? > ? > ? > ? ?

> ? ? ?Please enter your name: > ? ? ? > ? ?

> ? ?

> ? ? ? > ? ? ? ?Say Hi! > ? ? ? > ? ?

> ? > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From iperminov at dwavesys.com Mon Apr 4 06:08:21 2011 From: iperminov at dwavesys.com (Ilya Perminov) Date: Sun, 03 Apr 2011 23:08:21 -0700 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: ("Hans =?iso-8859-1?Q?H=FCbner=22's?= message of "Sun\, 3 Apr 2011 15\:26\:52 +0200") References: Message-ID: <8739lyim5m.fsf@dwavesys.com> Hi Hans, I think changing FINISH-OUTPUT back to FORCE-OUTPUT is wrong. It reintroduces the bug I reported a couple of months ago: http://common-lisp.net/pipermail/tbnl-devel/2011-February/005411.html Using (FORCE-OUTPUT S) in conjunction with (CLOSE S :ABORT T) does not guarantee all buffered output is sent to the socket before the socket is closed. That is probably why replacing FINISH-OUTPUT with FORCE-OUTPUT "fixed" Andrey's problem: the new version simply discards data instead of writing it to the socket. Ilya From hans.huebner at gmail.com Mon Apr 4 07:07:10 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 4 Apr 2011 09:07:10 +0200 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: <8739lyim5m.fsf@dwavesys.com> References: <8739lyim5m.fsf@dwavesys.com> Message-ID: Hi Ilya, thank you for the heads-up and sorry for the improper fix, which I will be backing out. I made the change after having discussed with David Lichteblau, and I have wrongly got the impression that FORCE-OUTPUT and FINISH-OUTPUT without any other keyword parameters should be basically equivalent. I have been pondering whether the FINISH-OUTPUT, with waiting for the flush to have finished, is the right thing. What is really required at this point is making sure that the data eventually arrives at the client, not neccessarily waiting for that to have happened. I am not quite sure what do do now. I personally don't use SBCL so I am not affected by the problem. It seems that neither of the two approaches that have been tried properly work for SBCL - FORCE-OUTPUT potentially loses data, and FINISH-OUTPUT potentially hangs the server. Any suggestions? Thanks, Hans On Mon, Apr 4, 2011 at 8:08 AM, Ilya Perminov wrote: > Hi Hans, > > I think changing FINISH-OUTPUT back to FORCE-OUTPUT is wrong. It > reintroduces the bug I reported a couple of months ago: > http://common-lisp.net/pipermail/tbnl-devel/2011-February/005411.html > > Using (FORCE-OUTPUT S) in conjunction with (CLOSE S :ABORT T) does not > guarantee all buffered output is sent to the socket before the socket > is closed. That is probably why replacing FINISH-OUTPUT with > FORCE-OUTPUT "fixed" Andrey's problem: the new version simply discards > data instead of writing it to the socket. > > Ilya > > _______________________________________________ > 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 Apr 4 08:17:56 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 4 Apr 2011 10:17:56 +0200 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection In-Reply-To: <87y63qh1qr.fsf@dwavesys.com> References: <8739lyim5m.fsf@dwavesys.com> <87y63qh1qr.fsf@dwavesys.com> Message-ID: Hi Ilya, please Cc the list in all emails concerning Hunchentoot. Reply below. On Mon, Apr 4, 2011 at 10:14 AM, Ilya Perminov wrote: > Hi Hans, > > Why is CLOSE always called with :ABORT T? It seems to me it is only > necessary when an IO error occurs and the connection have to be dropped. > If it is possible to change the code to use CLOSE without :ABORT T in > normal cases, it will be completely safe to use FORCE-OUTPUT inside of > the loop. I am not sure the change will resolve the "hanging in > FINISH-OUTPUT" problem, but it will make debugging easier. Ah, now I see what you mean. I will look at the code to find out why :ABORT is used later, but I suspect that there is no good reason to do that in non-error cases. > It would be really useful to find a simple way to reproduce the "hanging > in FINISH-OUTPUT" problem. If it is a SBCL bug, getting it fixed in SBCL > will be better than implementing a workaround. I agree with both points made. If there is a suitable workaround for older SBCL versions, it'd be even better. -Hans From archimag at gmail.com Mon Apr 4 15:59:21 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Mon, 4 Apr 2011 19:59:21 +0400 Subject: [hunchentoot-devel] Garbage in REPL Message-ID: Hi, For ACCESS-LOG-DESIGNATION default value is *ERROR-OUTPUT*. It is the cause of littering REPL for SLIME users. Maybe better use NIL as default and for suppress logging use a keyword :suppress? (defmethod acceptor-access-log-destination ((acceptor acceptor)) (let ((destination (slot-value acceptor 'access-log-destination))) (case destination ((nil) *error-output*) (:suppress nil) (otherwise destination)))) In this case, the logging will be sent to *inferior-lisp* and will not interfere with. Andrey From fbogdanovic at xnet.hr Mon Apr 4 18:15:11 2011 From: fbogdanovic at xnet.hr (Haris) Date: Mon, 4 Apr 2011 20:15:11 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp><3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: It works correctly in Firefox. I used Interenet Explorer before. What does that mean; Internet Explorer doesn't support ajax correctly ? Anyway, thanks for all the help. From daniel at dbrunner.de Mon Apr 4 18:51:11 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Mon, 04 Apr 2011 20:51:11 +0200 Subject: [hunchentoot-devel] [cl-plus-ssl-devel] ssl crashing in hunchentoot. A solution? In-Reply-To: <4D998F64.6080606@dbrunner.de> References: <5A4213B9-FC24-4C46-9FB6-437AAF382E59@gmail.com> <11FF5BD7-BDB0-4B8B-838B-B5C6AAB572F0@gmail.com> <20110401123854.GA15221@radon> <20110403132626.GB15221@radon> <993711301903694@web134.yandex.ru> <4D998F64.6080606@dbrunner.de> Message-ID: <4D9A131F.6060903@dbrunner.de> Hi, the patch crashes my CCL on Windows XP (32 Bit) as well. Sometimes with the first request, sometimes after 10 or 20 requests. But it seems not very stable on Windows. Kind regards, Daniel Am 04.04.2011 11:29, schrieb Daniel Brunner: > Hello, > > I started testing the patch. > > On Linux (X8664) it runs without any problems using CCL and SBCL. > > On Windows 7 (64 Bit) CCL crashes my application after a while without > any notice. But I have not figured out what is going wrong. > > Kind regards, Daniel. > > Am 04.04.2011 09:54, schrieb Anton Vodonosov: >> >> Hello. >> >> 03.04.2011, 17:26, "David Lichteblau" : >> >>> I have committed an updated version of the patch to CL+SSL CVS now. >> >> BTW, from your patch I saw you are using git. Haven't you thought to move CL+SSL >> repository to some git hosting? >> >>>> 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. >> >> IMHO the Lisp solution is better, because it frees end user from compiling >> C code. Before developing a C version, we should be sure that performance >> is really somehow significantly affected by the fact that the locking and thread-id >> callbacks are in Lisp. Anyway, cl+ssl is embedded into systems where everything >> is in Lisp. >> >> (I wander, why OpenSSL does not include these locking and thread-id functions >> itself and require users to copy/paste the C code from the examples.) >> >> Best regards, >> - Anton >> >> _______________________________________________ >> cl-plus-ssl-devel mailing list >> cl-plus-ssl-devel at common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel > > From olegsivokon at gmail.com Mon Apr 4 21:37:34 2011 From: olegsivokon at gmail.com (Oleg Sivokon) Date: Tue, 5 Apr 2011 00:37:34 +0300 Subject: [hunchentoot-devel] ht-simple-ajax In-Reply-To: References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> <3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: When you are testing in IE, you could really use MSVS, it has a free version. The free version has limited debugging capabilities less templates / documentation. But, at least, you could have a debugger for JavaScript, and that would help you find, not only this, but other JavaScript related problems in IE. http://www.microsoft.com/express/Web/ >From what I can tell, there are strange places in your code. For example, returning alert() doesn't make sense because alert() returns undefined. You don't really have to call request.send(null), you could do request.send(), but if you wanted to encode name-value pairs, this function is the right place to do it (when sending POST requests). http://www.w3.org/TR/XMLHttpRequest/#the-send-method http://msdn.microsoft.com/en-us/library/ms536736%28v=vs.85%29.aspx In your example, you are sending a GET request, therefore, you don't need any arguments. Also, there may be subtle differences in how browsers will treat non-significant white space in XML, so response.firstChild.firstChild.nodeValue may be just a couple of blanks, depending on how your XML looks like, or it may give you an error, if the response.firstChild is a text node. delete request; - is a useless line, JavaScript is a managed runtime, so any local variable will seize to exist once the function returns, unless it was referenced outside the function's scope (in which case "deleting" it will have no effect). It is different, from, for example, C++ where delete would free memory. In JavaScript it is used to remove dynamic references from where they existed (essentially, someObject.someProperty = undefined is the same as delete someObject.someProperty). HTH. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch-tbnl at bobobeach.com Tue Apr 5 00:37:21 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 4 Apr 2011 17:37:21 -0700 Subject: [hunchentoot-devel] Hunchentoot Errors (e.g. Couldn't write to #) Message-ID: Hello tbnl-folk, So, I've been seeing transient problems with hunchentoot for as long as I can remember, and I haven't had the chance to try to track down the problems until now. It seems there are a couple of classes of problems. In order of severity, the are: 1. things that crash hunchentoot/SBCL (or, in some cases, the host OS) 2. things that throw "unexpected" errors 3. things that throw "expected" errors (e.g. 404) As for class 1, these are tough to track down as the server is usually crashed by the time I get to it, but some causes I consider plausible are: * running out of some limited resource such as RAM, threads, or network sockets * possible SBCL bug in, say, signal handling or dealing with lots of threads I don't have any data to present on this class, at the moment, so let's move on to the next class. I often see errors such as this in the log: [2011-04-05 00:04:52 [ERROR]] Couldn't write to #: Broken pipe 0: (SB-DEBUG::MAP-BACKTRACE # :START 0 :COUNT 536870911) 1: (BACKTRACE 536870911 #) 2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM #) 3: (HUNCHENTOOT::GET-BACKTRACE) 4: ((FLET #:LAMBDA271) #" {B71EA51}>) 5: (SIGNAL #" {B71EA51}>) 6: (ERROR SB-INT:SIMPLE-STREAM-ERROR :STREAM # :FORMAT-CONTROL "~@<~?: ~2I~_~A~:>" :FORMAT-ARGUMENTS ("Couldn't write to ~S" (#) "Broken pipe")) 7: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~S" # 32) 8: (SB-IMPL::WRITE-OUTPUT-FROM-QUEUE #) 9: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL) 10: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL) 11: (SB-SYS:SERVE-ALL-EVENTS NIL) 12: (SB-IMPL::FINISH-FD-STREAM-OUTPUT #) 13: (FINISH-OUTPUT #) 14: (HUNCHENTOOT:HANDLE-STATIC-FILE #P"/home/sly/projects/www-cyrusharmon-org/static/images/fish-clusters.png" NIL) 15: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-REQUEST (HUNCHENTOOT:ACCEPTOR HUNCHENTOOT:REQUEST)) # # # #) 16: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) # # #) 17: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) # # # #) 18: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) # #) 19: ((LAMBDA ())) 20: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK353]358)) 21: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 22: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300)) 23: (SB-THREAD::CALL-WITH-MUTEX # #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER # :STATE 1) # T) 24: (SB-THREAD::INITIAL-THREAD-FUNCTION) 25: ("foreign function: call_into_lisp") 26: ("foreign function: funcall0") 27: ("foreign function: new_thread_trampoline") 28: ("foreign function: #xB7FC5506") What does this whole "broken pipe" mean? Is this more of an "expected error" or is something going wrong here? On a slightly different note, I'd like to be able to run a relatively reliable hunchentoot server that can serve a modest traffic load without having to resort to caching proxy servers and the like. I recall some discussion of thread pools, epoll, etc... Has the state of the art for high-reliability hunchentoot instances changed in the last couple years? Any suggestions on improving it? thanks! Cyrus From fbogdanovic at xnet.hr Wed Apr 6 12:05:21 2011 From: fbogdanovic at xnet.hr (Haris) Date: Wed, 6 Apr 2011 14:05:21 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp><3D73C9880A5C455C873FDA2F7ED7CA93@komp> Message-ID: <51A2D13DFA3F492BAFB1B81FA222E5A2@komp> I removed some of the code but it doesn't work anymore. What's the minimum code I have to add to make it works ? I don't really get response and callback terms in ajax ? I'm only interested in ajax now to be able to work with session values with javascript. Now when I click on Say hi link, I only get messagge box with value "undefined". ------------------------------------------------------------------------------- (defpackage :sessions (:use :cl :hunchentoot :cl-who :parenscript :ht-simple-ajax)) (in-package sessions) (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") (setf *js-string-delimiter* #\") (defparameter *ajax-processor* (make-instance 'ajax-processor :server-uri "/ajax")) (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) (defun-ajax say-hi () (*ajax-processor*) (write-to-string (incf (session-value 'x)))) (define-easy-handler (main-page :uri "/") () (start-session) (setf (session-value 'x) 10) (with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" (:head (:title "ht-simple-ajax demo") (princ (generate-prologue *ajax-processor*)) (:script :type "text/javascript" (str (ps (defun say-hi () (alert (ajax_say_hi))))))) (:body (:p "Please enter your name: " (:input :id "name" :type "text")) (:p (:a :href (ps-inline (say-hi)) "Say Hi!")))))) From fbogdanovic at xnet.hr Wed Apr 6 14:21:30 2011 From: fbogdanovic at xnet.hr (Haris) Date: Wed, 6 Apr 2011 16:21:30 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp><3D73C9880A5C455C873FDA2F7ED7CA93@komp> <51A2D13DFA3F492BAFB1B81FA222E5A2@komp> Message-ID: <5540D4252E594AD3ACEDF77D08F3F5D0@komp> Here I changed the function names to reflect the code: ------------------------------------------------------------------------------- (defpackage :sessions (:use :cl :hunchentoot :cl-who :parenscript :ht-simple-ajax)) (in-package sessions) (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") (setf *js-string-delimiter* #\") (defparameter *ajax-processor* (make-instance 'ajax-processor :server-uri "/ajax")) (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) (defun-ajax show-x () (*ajax-processor*) (write-to-string (incf (session-value 'x)))) (define-easy-handler (main-page :uri "/") () (start-session) (setf (session-value 'x) 10) (with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" (:head (princ (generate-prologue *ajax-processor*)) (:script :type "text/javascript" (str (ps (defun show-x () (alert (ajax_show_x)))))) (:body (:p (:a :href (ps-inline (show-x)) "Show X")))))) From lou.vanek at gmail.com Wed Apr 6 18:32:40 2011 From: lou.vanek at gmail.com (Lou Vanek) Date: Wed, 6 Apr 2011 14:32:40 -0400 Subject: [hunchentoot-devel] ht-simple-ajax In-Reply-To: <5540D4252E594AD3ACEDF77D08F3F5D0@komp> References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp> <3D73C9880A5C455C873FDA2F7ED7CA93@komp> <51A2D13DFA3F492BAFB1B81FA222E5A2@komp> <5540D4252E594AD3ACEDF77D08F3F5D0@komp> Message-ID: I know this isn't exactly what you've requested, but it does show how to get a session value and display it in the browser. It's been tested in the latest Chrome, IE, and Firefox, and uses Hunchentoot. http://paste.lisp.org/display/121215 Sometimes simpler is better. On Wed, Apr 6, 2011 at 10:21 AM, Haris wrote: > Here I changed the function names to reflect the code: > > ------------------------------------------------------------------------------- > > (defpackage :sessions (:use :cl :hunchentoot :cl-who :parenscript > :ht-simple-ajax)) > > (in-package sessions) > > (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") > (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") > > (setf *js-string-delimiter* #\") > > > (defparameter *ajax-processor* > ?(make-instance 'ajax-processor :server-uri "/ajax")) > > (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) > > (defun-ajax show-x () (*ajax-processor*) > ?(write-to-string (incf (session-value 'x)))) > > > (define-easy-handler (main-page :uri "/") () > ?(start-session) > ?(setf (session-value 'x) 10) > ?(with-html-output-to-string (*standard-output* nil :prologue t :indent t) > ? ?(:html :xmlns "http://www.w3.org/1999/xhtml" > ? ? (:head > ? ? ?(princ (generate-prologue *ajax-processor*)) > ? ? ?(:script :type "text/javascript" > ? ? ? (str > ? ? ? ?(ps > > ? ? ? ?(defun show-x () > ? ? ? ? ?(alert (ajax_show_x)))))) > > ? ? (:body > ? ? ?(:p (:a :href (ps-inline (show-x)) "Show X")))))) > > > > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From fbogdanovic at xnet.hr Thu Apr 7 16:44:13 2011 From: fbogdanovic at xnet.hr (Haris) Date: Thu, 7 Apr 2011 18:44:13 +0200 Subject: [hunchentoot-devel] ht-simple-ajax References: <8F39E27DD05B4ED0AAE3914290C52EFD@komp><3D73C9880A5C455C873FDA2F7ED7CA93@komp><51A2D13DFA3F492BAFB1B81FA222E5A2@komp> <5540D4252E594AD3ACEDF77D08F3F5D0@komp> Message-ID: <20725D5C86D54F31BF8DD2D532C88F32@komp> I had to move to Internet Explorer again because it stopped working in Firefox. I started to debug javascript and on alert (response.firstNode.firstNode.nodcValue) it says that firstNode.firstNode is not an object ? --------------------------------------------------------------------------------------------------------------- (defpackage ajax (:use :cl :hunchentoot :cl-who :parenscript :ht-simple-ajax)) (in-package ajax) (setf *access-log-pathname* "c:/lisp/hunchentoot-log/access.log") (setf *message-log-pathname* "c:/lisp/hunchentoot-log/message.log") (setf *js-string-delimiter* #\") (defparameter *ajax-processor* (make-instance 'ajax-processor :server-uri "/ajax")) (push (create-ajax-dispatcher *ajax-processor*) *dispatch-table*) (push (create-prefix-dispatcher "/" 'index) *dispatch-table*) (defun-ajax show-number () (*ajax-processor*) "10") (defun index () (with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" (:head (:title "ht-simple-ajax demo") (princ (generate-prologue *ajax-processor*)) (:script :type "text/javascript" (str (ps (defun callback (response) (alert (chain response first-node first-node node-value)) ; ERROR: firstNode.firstNode 0))))) ; is not an object (:body (:p (:a :href (ps-inline (ajax_show_nuimber callback)) "Show number")))))) From ch-tbnl at bobobeach.com Fri Apr 8 00:00:41 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 7 Apr 2011 17:00:41 -0700 Subject: [hunchentoot-devel] recent-ish hunchentoot changes Message-ID: <07F97DD7-9E52-44A7-A7AC-A85CA088C858@bobobeach.com> So, I see that way requests are handled has changed a bit in the last couple months. This leads me to a couple questions: 1. This is still only in the svn (and various mirrors) versions, not yet in a released version, right? Any idea when we should expect a release with these changes? 2. default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing? 3. is the "new" way to handle requests to subclass acceptor, as easy-acceptor does? How is this supposed to play with the ssl-acceptor? Should we define regular (non-ssl) acceptors and ssl-acceptors for our code? I think of http vs. https as more of a transport issue than an application logic issue. It seems a little odd to be using subclassing, along one axis, for http vs. https and for application-logic, along another axis. Am I missing something? In case anyone's curious, I'm trying to bring my hunchentoot-vhost forward to work with the new hunchentoot, and it's requiring a bit of a rethinking of how I handle requests. I'm happy to make a hunchentoot-vhost-acceptor, if that's the way to go, but I'm a little less thrilled about having to make a hunchentoot-vhost-ssl-acceptor too. I think the new design generally looks nice, but it's still taking some getting used to. thanks! Cyrus From hans.huebner at gmail.com Fri Apr 8 04:16:51 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 8 Apr 2011 06:16:51 +0200 Subject: [hunchentoot-devel] recent-ish hunchentoot changes In-Reply-To: <07F97DD7-9E52-44A7-A7AC-A85CA088C858@bobobeach.com> References: <07F97DD7-9E52-44A7-A7AC-A85CA088C858@bobobeach.com> Message-ID: Hi Cyrus, thanks for your feedback! On Fri, Apr 8, 2011 at 2:00 AM, Cyrus Harmon wrote: > 1. This is still only in the svn (and various mirrors) versions, not yet in a released version, right? Any idea when we should expect a release with these changes? No date has been set for a release, and I'd really like to wait with this until all known major problems are gone. > 2. default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing? Right. > 3. is the "new" way to handle requests to subclass acceptor, as easy-acceptor does? How is this supposed to play with the ssl-acceptor? Should we define regular (non-ssl) acceptors and ssl-acceptors for our code? I think of http vs. https as more of a transport issue than an application logic issue. It seems a little odd to be using subclassing, along one axis, for http vs. https and for application-logic, along another axis. Am I missing something? You are right, and that problem has bothered me for a bit. What I really want to do is fold SSL into Hunchentoot in a way that does not collide with the interface that is being exposed for general application program. I've not thought through this thoroughly, but I'm thinking that a new REQUEST-PROCESSOR class is needed that does the actual request handling and is separate from ACCEPTOR, which does the connection management. Multiple ACCEPTOR instances could then share one REQUEST-PROCESSOR, or - in the virtual host case - there could be a M:N relationship between instances of the two classes. REQUEST-PROCESSOR would then be the class that applications would often subclass, whereas ACCEPTOR would rarely need change. Does that generally make sense to you? -Hans From ch-tbnl at bobobeach.com Tue Apr 12 05:34:07 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 11 Apr 2011 22:34:07 -0700 Subject: [hunchentoot-devel] recent-ish hunchentoot changes In-Reply-To: References: <07F97DD7-9E52-44A7-A7AC-A85CA088C858@bobobeach.com> Message-ID: <0599B9E3-2DF9-47D1-9059-EB0888E6D3F3@bobobeach.com> On Apr 7, 2011, at 9:16 PM, Hans H?bner wrote: > Hi Cyrus, > > thanks for your feedback! By all means. Thanks to you (and Edi et al.) for continuing to improve hunchentoot! > > On Fri, Apr 8, 2011 at 2:00 AM, Cyrus Harmon wrote: >> 1. This is still only in the svn (and various mirrors) versions, not yet in a released version, right? Any idea when we should expect a release with these changes? > > No date has been set for a release, and I'd really like to wait with > this until all known major problems are gone. Fair enough, but there can be a bit of a chicken-and-egg problem here in that folks will be reluctant to adopt the new ways unless they see the train approaching quickly. >> 2. default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing? > > Right. Ok, I think this is good. Things like *default-foo* occasionally suggest that there might be a way to better restructure the code such that defaults aren't hardcoded in special variables like that -- and I think that may be the case here. >> 3. is the "new" way to handle requests to subclass acceptor, as easy-acceptor does? How is this supposed to play with the ssl-acceptor? Should we define regular (non-ssl) acceptors and ssl-acceptors for our code? I think of http vs. https as more of a transport issue than an application logic issue. It seems a little odd to be using subclassing, along one axis, for http vs. https and for application-logic, along another axis. Am I missing something? > > You are right, and that problem has bothered me for a bit. What I > really want to do is fold SSL into Hunchentoot in a way that does not > collide with the interface that is being exposed for general > application program. I've not thought through this thoroughly, but > I'm thinking that a new REQUEST-PROCESSOR class is needed that does > the actual request handling and is separate from ACCEPTOR, which does > the connection management. Multiple ACCEPTOR instances could then > share one REQUEST-PROCESSOR, or - in the virtual host case - there > could be a M:N relationship between instances of the two classes. > > REQUEST-PROCESSOR would then be the class that applications would > often subclass, whereas ACCEPTOR would rarely need change. > > Does that generally make sense to you? Not only does it make sense to me, it echoes what I was thinking about a couple of days ago, after I sent my previous message. I think something like a request-processor (I was thinking of request-handler, but that's the same thing) might be in order. I'm working on thinking through how this might work and will follow up with another email in the next few days. Thanks for taking the time to discuss these issues. Cyrus > > -Hans From fbogdanovic at xnet.hr Fri Apr 15 21:41:08 2011 From: fbogdanovic at xnet.hr (Haris) Date: Fri, 15 Apr 2011 23:41:08 +0200 Subject: [hunchentoot-devel] post Message-ID: <89A1894AB73E43AA824A038BF4312694@komp> Hi. Can Hunchentoot page automaticaly post parameters when fetched from some other page's javascript code to get an ajax effect ? Thanks From ch-tbnl at bobobeach.com Sun Apr 17 16:25:38 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sun, 17 Apr 2011 09:25:38 -0700 Subject: [hunchentoot-devel] Hunchentoot Request Processing Message-ID: [Before diving in to try to "fix" some things in the way hunchentoot handles requests, I figured it would be good to try to more fully understand how hunchentoot handles incoming requests, so I decided to take some notes on the whole process. I thought these might be food for thought or discussion for the list, so here they are - cyrus] Hunchentoot has a flexible and extensible model for managing connections between the hunchentoot server and its clients. In olden times, there was a hunchentoot SERVER class which received incoming requests and dispatched these requests to handlers that would produce the appropriate responses. In recent versions of hunchentoot, this functionality has been split into a few different classes, or families of classes. The ACCEPTOR and TASKMASTER classes (or, more precisely, they and their subclasses) now work together to listen for incoming connections and to dispatch them appropriately. The logic of the TASKMASTER and ACCEPTOR classes is somewhat baroque, although this is probably not without good reason. Let's walk through a typical process of starting up hunchentoot. * Initializing the Server 1. Create an Acceptor and a Taskmaster Usually, this is done in one fell swoop with a call such as: (make-instance 'hunchentoot:acceptor) This creates an acceptor that listens for incoming connections on a given port, 80 by default. There's an important detail here that can usually be ignored by the user, which is that the acceptor needs a taskmaster to manage the process of actually receiving connections from the lower level networking infrastructure. The reference to the taskmaster is stored in the ACCEPTOR's TASKMASTER slot and the value of this slot is usually provided directly by the default-initargs section of the ACCEPTOR class definition which reads: :taskmaster (make-instance (cond (*supports-threads-p* 'one-thread-per-connection-taskmaster) (t 'single-threaded-taskmaster))) So, when running on a suitably threaded lisp implementation, a ONE-THREAD-PER-CONNECTION-TASKMASTER is created, or on a single-threaded lisp a SINGLE-THREADED-TASKMASTER is created, and this value is stored in the TASKMASTER slot of the ACCEPTOR. 2. ACCEPTOR / START method Once the ACCEPTOR has been created and its TASKMASTER slot suitably initialized, the START method of the ACCEPTOR is called. START then calls the ACCEPTOR's START-LISTENING method. 3. ACCEPTOR / START-LISTENING method The START-LISTENING method tells the underlying networking infrastructure to listen for incoming connections on a (single) port. On lispworks, the acceptor starts a "server" process with comm:startup-server and then stops this process, with it ready to be restarted in ACCEPT-CONNECTIONS. On non-lispworks lisps, this method sets the LISTEN-SOCKET slot to a USOCKET:STREAM-SERVER-USOCKET as returned by USOCKET:SOCKET-LISTEN. 4. Establish reciprocal connection from TASKMASTER back to ACCEPTOR Back in the ACCEPTOR's START method, and now that the ACCEPTOR is listening for traffic, we establish the link from the TASKMASTER back to this ACCEPTOR (notice that there is a tight 1:1 coupling between ACCEPTORs and TASKMASTERs, although the decoupling of the two classes allows for subclassing of one independently from the other -- a good thing!). 5. TASKMASTER / EXECUTE-ACCEPTOR method The TASKMASTER's EXECUTE-ACCEPTOR doesn't do a lot of work -- it turns around and calls the ACCEPTOR's ACCEPT-CONNECTIONS method, but the critical bit here is that the (particular subclass of) TASKMASTER is free to spawn a new thread in which to call ACCEPT-CONNECTIONS (as is done in the ONE-THREAD-PER-CONNECTION-TASKMASTER), or it can call it in its (the TASKMASTER's and, presumably, the ACCEPTOR's) own thread (as in the SINGLE-THREADED-TASKMASTER). 6. ACCEPTOR / ACCEPT-CONNECTIONS ACCEPT-CONNECTIONS either listens for input using USOCKET:WAIT-FOR-INPUT on non-lispworks lisps, or, on lispworks, wakes the server process using MP:PROCESS-UNSTOP. On non-lispworks lisps, once the stream is ready for input, ACCEPT-CONNECTIONS calls its TASKMASTER's HANDLE-INCOMING-CONNECTION method. On Lispworks, the ACCEPTOR's TASKMASTER's HANDLE-INCOMING-CONNECTION method is called from the callback provided to COMM:START-UP-SERVER. In either case, we transfer control back to the taskmaster once we have a connection ready to provide input. * Processing Requests 7a. TASKMASTER / HANDLE-INCOMING-CONNECTION Once again, the TASKMASTER comes into play, as we have different behavior for single- and multi-threaded taskmasters, and, of course, different behavior for lispworks and non-lispworks lisps. [n.b. The reader conditionals for lispworks/non-lispworks seem a bit bogus to me. Is there any reason the bordeaux/usocket code couldn't be run on lispworks? If the bordeaux/usocket can run on lispworks, are there advantages to the lispworks-specific code? Could/should the lispworks specific code be split off into, say, LISPWORKS-ONE-THREAD-PER-CONNECTION-TASKMASTER and the usocket version into USOCKET-ONE-THREAD-PER-CONNECTION-TASKMASTER? Clearly, the lispworks-specific stuff shouldn't be compiled on non-lispworks implementations (and maybe vice versa), but it seems that a more flexible mechanism for deciding to use the lispworks-stuff or the usocket-stuff on lispworks would be a nice feature.] 7b. (with ONE-THREAD-PER-CONNECTION-TASKMASTER taskmasters) TASKMASTER / CREATE-REQUEST-HANDLER-THREAD The ONE-THREAD-PER-CONNECTION-TASKMASTER's CREATE-REQUEST-HANDLER-THREAD spawns a new thread and calls its ACCEPTOR's PROCESS-CONNECTION method. With SINGLE-THREADED-TASKMASTER, HANDLE-INCOMING-CONNECTION calls process-connection directly. 8. ACCEPTOR / PROCESS-CONNECTION Now control switches back to the ACCEPTOR which initializes the connection stream and calls PROCESS-REQUEST on a newly created instance of the ACCEPTOR's REQUEST-CLASS. One important thing that happens in PROCESS-CONNECTION is that INITIALIZE-CONNECTION-STREAM is called with the acceptorand USOCKET:SOCKET-STREAM (as provided by the compatibility function make-socket-stream). One reason that this is important is that this is the "hook" that the SSL-ACCEPTOR uses to make the connection stream a CL+SSL:SSL-SERVER-STREAM. In fact, this (and ACCEPTOR-SSL-P) are the only methods specialized by the SSL-ACCEPTOR. This seems to be a pretty clean place to try to break the SSL functionality off into another class that is not a subclass of ACCEPTOR. Whether or not this is a good idea remains to be seen. Q: Why do we set *CLOSE-HUNCHENTOOT-STREAM* to T inside the loop here? Q: If we created a new class to implement INITIALIZE-CONNECTION-STREAM, what would it be called? 9. REQUEST / PROCESS-REQUEST Having initialized the connection stream (usually a no-op, except for SSL connections), we now move to the next task at hand, processing the actual request. This is done via an unspecialized method on the PROCESS-REQUEST generic function, which happens to live in the request.lisp file, but doesn't actually specialize on request. PROCESS-REQUEST sets up some error handlers, calls HANDLE-REQUEST and then starts (and maybe finishes) sending the HTTP reply. 10. ACCEPTOR / HANDLE-REQUEST The HANDLE-REQUEST method specializes on acceptor and request as the first two arguments and, with the appropriate error handling forms in place, turns around calls the ACCEPTOR's ACCEPTOR-DISPATCH-REQUEST method. 11. ACCEPTOR / ACCEPTOR-DISPATCH-REQUEST The ACCEPTOR-DISPATCH-REQUEST method is the one place in the new hunchentoot source were user-extensible request handling is demonstrated. The new, so-called, easy-handler extends the ACCEPTOR class as EASY-ACCEPTOR and defines an ACCEPTOR-DISPATCH-REQUEST specialized on EASY-ACCEPTOR as its first argument. This method is called in preference to the ACCEPTOR's version (for EASY-ACCEPTOR's anyway) and, in this case, loops over the values in the *dispatch-table* special variable and funcalls each function on the list with the request as the single argument to the function. * Some final comments While this entire process is modularized, somewhat flexible and extensible, in practice it's a bit baroque and a bit challenging to figure out exactly where and how to extend the functionality of the core server. As a case in point, how is one supposed to create an acceptor that is both an easy-acceptor and works over SSL connections? Make a new ACCEPTOR subclass that extends both EASY-ACCEPTOR and SSL-ACCEPTOR? I don't see why that wouldn't work, but it also seems somehow wrong. It seems to me that there should be a way to compose these kinds of functionalities without triggering a combinatorial subclass explosion. The initialization of the connection stream and the actual process of handling the request seem like they might be components for somehow being further modularized. The challenge is to figure out a nice way to do this. * Some ideas for new classes 1. REQUEST-PROCESSOR 2. SOCKET-CONNECTOR From edi at weitz.de Sun Apr 17 17:44:03 2011 From: edi at weitz.de (Edi Weitz) Date: Sun, 17 Apr 2011 19:44:03 +0200 Subject: [hunchentoot-devel] Hunchentoot Request Processing In-Reply-To: References: Message-ID: On Sun, Apr 17, 2011 at 6:25 PM, Cyrus Harmon wrote: > n.b. The reader conditionals for lispworks/non-lispworks seem a bit bogus to me. Is there any reason the bordeaux/usocket code couldn't be run on lispworks? I've recently explained this here: http://common-lisp.net/pipermail/drakma-devel/2011-March/000877.html From ch-tbnl at bobobeach.com Sun Apr 17 22:13:53 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sun, 17 Apr 2011 15:13:53 -0700 Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector? Message-ID: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com> I've been playing around with some changes to ACCEPTOR and friends that introduce the new classes SOCKET-CONNECTOR and SSL-SOCKET-CONNECTOR. The purpose of these changes are to take the specialized socket handling behavior out of the acceptor and into another class, such that subclassing acceptor isn't required to, say, use SSL streams. As a motivating example, consider the following: (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4243 :socket-connector (make-instance 'hunchentoot::ssl-socket-connector :ssl-certificate-file (asdf:system-relative-pathname :hunchentoot "ssl/certificate.pem") :ssl-privatekey-file (asdf:system-relative-pathname :hunchentoot "ssl/key.pem")))) (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name) (setf (hunchentoot:content-type*) "text/plain") (format nil "Hey~@[ ~A~]!" name)) Without these changes, one would have to subclass both easy-acceptor and ssl-acceptor in order to have an SSL-using easy acceptor. Comments/suggestions greatly appreciated. The changes can be found in the git repo at: https://github.com/slyrus/hunchentoot/tree/socket-connector and in the attached patch. Cyrus -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-socket-connector.patch Type: application/octet-stream Size: 14978 bytes Desc: not available URL: From ch-tbnl at bobobeach.com Mon Apr 18 05:11:09 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sun, 17 Apr 2011 22:11:09 -0700 Subject: [hunchentoot-devel] dispatcher class Message-ID: <653DE3C8-F6F6-49A4-A8BE-776C471ED283@bobobeach.com> Continuing my efforts to solve the problem of wanting, for instance, an SSL-accepting easy-acceptor without creating a subclass of both SSL-ACCEPTOR and EASY-ACCEPTOR, I've created a new class called DISPATCHER which implements the dispatch-request generic function. The advantage of this class is that one can add custom dispatching behavior without needing to subclass the acceptor. For instance, the EASY-ACCEPTOR is now an EASY-DISPATCHER and can be invoked as: (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4243 :dispatcher (make-instance 'hunchentoot:easy-dispatcher))) New dispatching behavior can be implemented by subclassing DISPATCHER and setting the dispatcher slot of the acceptor to point to an instance of the subclass. The changes can be found in git at: https://github.com/slyrus/hunchentoot/tree/dispatcher and in the attached patch. Cyrus -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-dispatcher.patch Type: application/octet-stream Size: 9516 bytes Desc: not available URL: From hans.huebner at gmail.com Mon Apr 18 05:48:05 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 18 Apr 2011 07:48:05 +0200 Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector? In-Reply-To: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com> References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com> Message-ID: Hi Cyrus, without having looked at your patches thoroughly, a question: Why does it make sense to have an extra socket-connector class? I'd put the connection type specific functionality into acceptor, and just add the dispatcher class that you've proposed, although I would like to call it request-handler. It may make sense to add an umbrella "server" class that holds one or more acceptors. The goal that I see is: - It should be possible to have one server serve multiple ports, e.g. SSL and non-SLL, but share one object that the application can attach things to. - It should be possible to have multiple request handler instances. They should be attached to a server and be tried in a well-defined order to handle incoming requests. Hunchentoot would provide two request handler classes, easy-handlers and file-handlers. Thoughts? -Hans On Mon, Apr 18, 2011 at 12:13 AM, Cyrus Harmon wrote: > I've been playing around with some changes to ACCEPTOR and friends that introduce the new classes SOCKET-CONNECTOR and SSL-SOCKET-CONNECTOR. The purpose of these changes are to take the specialized socket handling behavior out of the acceptor and into another class, such that subclassing acceptor isn't required to, say, use SSL streams. > > As a motivating example, consider the following: > > (hunchentoot:start > ?(make-instance > ?'hunchentoot:easy-acceptor > ?:port 4243 > ?:socket-connector > ?(make-instance > ? 'hunchentoot::ssl-socket-connector > ? :ssl-certificate-file (asdf:system-relative-pathname > ? ? ? ? ? ? ? ? ? ? ? ? ?:hunchentoot "ssl/certificate.pem") > ? :ssl-privatekey-file (asdf:system-relative-pathname > ? ? ? ? ? ? ? ? ? ? ? ? :hunchentoot "ssl/key.pem")))) > > (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name) > ?(setf (hunchentoot:content-type*) "text/plain") > ?(format nil "Hey~@[ ~A~]!" name)) > > > Without these changes, one would have to subclass both easy-acceptor and ssl-acceptor in order to have an SSL-using easy acceptor. Comments/suggestions greatly appreciated. > > The changes can be found in the git repo at: > > https://github.com/slyrus/hunchentoot/tree/socket-connector > > and in the attached patch. > > Cyrus > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From ch-tbnl at bobobeach.com Mon Apr 18 14:56:00 2011 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 18 Apr 2011 07:56:00 -0700 Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector? In-Reply-To: References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com> Message-ID: <436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com> Hi Hans, Well, that's a good question. I think the idea is that someone could both extend ACCEPTOR (and TASKMASTER) (a fancy epoll-using ACCEPTOR perhaps?) and still have said ACCEPTOR-subclass useable with SSL without subclassing. I like the idea of composing in the SSL-based socket functionality at runtime without subclassing -- at least I liked it enough to try out the approach. I'm not certain this is the best approach, but it looked reasonable enough to try it out and it seems to work. If the consensus is that this isn't a good approach, I can live with that. As for the DISPATCHER / REQUEST-HANDLER, sure I'm happy to see it renamed to REQUEST-HANDLER. I think a SERVER class that holds one or more acceptors would be a fine thing. I seem to end up coding something like that by hand when I need it (the ability to do so should remain, of course) but it would be nice to have a standard way to wrap those servers as I think that's a pretty common use case. And, yes, I think a way of associating multiple request handlers with acceptors would be a good thing. I guess the question is should the ACCEPTOR do that or should we delegate to something like a DISPATCHER which would call each REQUEST-HANDLER? Thanks for taking a look at my patches. Cyrus On Apr 17, 2011, at 10:48 PM, Hans H?bner wrote: > Hi Cyrus, > > without having looked at your patches thoroughly, a question: Why > does it make sense to have an extra socket-connector class? I'd put > the connection type specific functionality into acceptor, and just add > the dispatcher class that you've proposed, although I would like to > call it request-handler. It may make sense to add an umbrella > "server" class that holds one or more acceptors. > > The goal that I see is: > > - It should be possible to have one server serve multiple ports, e.g. > SSL and non-SLL, but share one object that the application can attach > things to. > - It should be possible to have multiple request handler instances. > They should be attached to a server and be tried in a well-defined > order to handle incoming requests. Hunchentoot would provide two > request handler classes, easy-handlers and file-handlers. > > Thoughts? > -Hans > > On Mon, Apr 18, 2011 at 12:13 AM, Cyrus Harmon wrote: >> I've been playing around with some changes to ACCEPTOR and friends that introduce the new classes SOCKET-CONNECTOR and SSL-SOCKET-CONNECTOR. The purpose of these changes are to take the specialized socket handling behavior out of the acceptor and into another class, such that subclassing acceptor isn't required to, say, use SSL streams. >> >> As a motivating example, consider the following: >> >> (hunchentoot:start >> (make-instance >> 'hunchentoot:easy-acceptor >> :port 4243 >> :socket-connector >> (make-instance >> 'hunchentoot::ssl-socket-connector >> :ssl-certificate-file (asdf:system-relative-pathname >> :hunchentoot "ssl/certificate.pem") >> :ssl-privatekey-file (asdf:system-relative-pathname >> :hunchentoot "ssl/key.pem")))) >> >> (hunchentoot:define-easy-handler (say-yo :uri "/yo") (name) >> (setf (hunchentoot:content-type*) "text/plain") >> (format nil "Hey~@[ ~A~]!" name)) >> >> >> Without these changes, one would have to subclass both easy-acceptor and ssl-acceptor in order to have an SSL-using easy acceptor. Comments/suggestions greatly appreciated. >> >> The changes can be found in the git repo at: >> >> https://github.com/slyrus/hunchentoot/tree/socket-connector >> >> and in the attached patch. >> >> Cyrus >> >> >> _______________________________________________ >> 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 hans.huebner at gmail.com Wed Apr 20 08:01:11 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 20 Apr 2011 10:01:11 +0200 Subject: [hunchentoot-devel] socket-connector and ssl-socket-connector? In-Reply-To: <436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com> References: <3381C0B6-2044-447E-8117-0634CFDFED78@bobobeach.com> <436257D2-D1F7-42C4-968F-3764108AD102@bobobeach.com> Message-ID: On Mon, Apr 18, 2011 at 4:56 PM, Cyrus Harmon wrote: > I think the idea is that someone could both extend ACCEPTOR (and TASKMASTER) (a fancy epoll-using ACCEPTOR perhaps?) and still have said ACCEPTOR-subclass useable with SSL without subclassing. I like the idea of composing in the SSL-based socket functionality at runtime without subclassing -- at least I liked it enough to try out the approach. I'm not certain this is the best approach, but it looked reasonable enough to try it out and it seems to work. If the consensus is that this isn't a good approach, I can live with that. At this point, I'd prefer not to add new classes unless they really fulfill a need. I have been pondering whether/if Hunchentoot can be converted to an event oriented web server somehow, but that would require much more than separating out the connector functionality. The real issue, I think, is that the underlying streams are not event oriented. The flow of control would need to be basically reverted, and that is something that I'm not up to doing. Maybe using Hunchentoot as a start is a bad idea anyway. Anyway, I'd like to keep things as simple as possible. > I think a SERVER class that holds one or more acceptors would be a fine thing. I seem to end up coding something like that by hand when I need it (the ability to do so should remain, of course) but it would be nice to have a standard way to wrap those servers as I think that's a pretty common use case. The task of a SERVER class would be to read a configuration specification and instantiate the required objects that make up the server. In the simple case, this would be one ACCEPTOR, one TASKMASTER and one REQUEST-HANDLER. In more complex cases, more ACCEPTOR instances would be present (to listen on multiple ports) or more REQUEST-HANDLERS would exist to, say, serve multiple virtual hosts. I will need a few more weeks until I can really put effort into reviewing the patches and implement the new mechanisms. I also hope that the SSL problems are sorted out until then, as the upcoming release should certainly support SSL. -Hans From evenson at panix.com Thu Apr 28 04:58:13 2011 From: evenson at panix.com (Mark Evenson) Date: Thu, 28 Apr 2011 06:58:13 +0200 Subject: [hunchentoot-devel] Patch for ABCL SET-TIMEOUTS Message-ID: The attached patch provides an implementation for Hunchentoot's SET-TIMEOUTS running on ABCL. Please consider it for inclusion in the Hunchentoot source. With this patch, [the development versions of ABCL is now able to run Hunchentoot with small additional patches to Quicklisp bordeaux-threads and usocket][1]. Currently one has to add :HUNCHENTOOT-NO-SSL to *FEATURES* for Hunchentoot to work as CFFI doesn't implement the necessary callbacks for CL+SSL to work (but [progress in rectifying this has been made][2]. And testing via Drakma needs trivial-garbage for which we [only recently implemented the necessary finalizers][3] but haven't wrestled out a suitable patch. [1]: http://detroit.slack.net/~evenson/abcl/hunchentoot [2]: http://detroit.slack.net/~evenson/abcl/cffi-abcl-20101231a.diff [3]: http://trac.common-lisp.net/armedbear/changeset/13250 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hunchentoot-abcl-20110427a.diff URL: