June 2011 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] Hunchentoot support for ECL
by Olivier Dumont 30 Oct '11

30 Oct '11

Hi, the attached patch allows hunchentoot to function properly with the latest release of ECL (11.1.1). best regards, Olivier

2 1

[hunchentoot-devel] Hunchentoot Errors (e.g. Couldn't write to #<SB-SYS:FD-STREAM for "socket ..." ...>)
by Cyrus Harmon 30 Oct '11

30 Oct '11

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 #<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}>: Broken pipe 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {B71EC4D}> :START 0 :COUNT 536870911) 1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {B71EBE9}>) 2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM #<SB-IMPL::STRING-OUTPUT-STREAM {B71EBE9}>) 3: (HUNCHENTOOT::GET-BACKTRACE) 4: ((FLET #:LAMBDA271) #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {B71EA51}>) 5: (SIGNAL #<SB-INT:SIMPLE-STREAM-ERROR "~@<~?: ~2I~_~A~:>" {B71EA51}>) 6: (ERROR SB-INT:SIMPLE-STREAM-ERROR :STREAM #<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}> :FORMAT-CONTROL "~@<~?: ~2I~_~A~:>" :FORMAT-ARGUMENTS ("Couldn't write to ~S" (#<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}>) "Broken pipe")) 7: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~S" #<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}> 32) 8: (SB-IMPL::WRITE-OUTPUT-FROM-QUEUE #<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}>) 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 #<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}>) 13: (FINISH-OUTPUT #<SB-SYS:FD-STREAM for "socket 74.115.254.12:80, peer: 217.72.218.248:2741" {B6FB859}>) 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)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 80)> #<HUNCHENTOOT:REQUEST {B701D09}>) 16: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:REQUEST {B701D09}>) 17: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) #<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 80)> #<USOCKET:STREAM-USOCKET {B6FB8F1}>) 18: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<HUNCHENTOOT:ACCEPTOR (host *, port 80)> #<USOCKET:STREAM-USOCKET {B6FB8F1}>) 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 #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B0E14235}> #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client: 217.72.218.248:2741)" RUNNING {B6FCE39}> :STATE 1) #<SB-THREAD:THREAD "Hunchentoot worker (client: 217.72.218.248:2741)" RUNNING {B6FCE39}> 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

2 1

[hunchentoot-devel] Garbage in REPL
by Andrey Moskvitin 30 Oct '11

30 Oct '11

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

2 1

[hunchentoot-devel] socket-connector and ssl-socket-connector?
by Cyrus Harmon 29 Sep '11

29 Sep '11

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

3 9

[hunchentoot-devel] The question of new release
by Andrey Moskvitin 29 Jun '11

29 Jun '11

Hi, When do expect a new release of Hunchentoot? In my opinion, the HEAD version works fine. Andrey

3 2

[hunchentoot-devel] hunchentoot:*default-content-type* & hunchentoot:*hunchentoot-default-external-format*
by Thibault Langlois 15 Jun '11

15 Jun '11

*Hi, If I want to serve web pages encoded in UTF-8, I should set these two variables : (setf hunchentoot:*default-content-type* "text/html; charset=UTF-8") (setf hunchentoot:*hunchentoot-default-external-format* hunchentoot::+utf-8+) Am I correct ? Is it ok to use an internal symbol (+utf-8+) or is there another way ? Thanks, * -- Thibault Langlois FCUL / DI

3 3

[hunchentoot-devel] Invitation to connect on LinkedIn
by Andrea Massimo Chiumenti 13 Jun '11

13 Jun '11

LinkedIn ------------ General, I'd like to add you to my professional network on LinkedIn. - Andrea Massimo Andrea Massimo Chiumenti Owner at Wings Tech Milan Area, Italy Confirm that you know Andrea Massimo Chiumenti https://www.linkedin.com/e/bxhy9y-gov4ghry-11/isd/3192087151/LoQitsoO/ -- (c) 2011, LinkedIn Corporation

1 0

Re: [hunchentoot-devel] Hunchentootin in the quicklisp repository?
by Zach Beane 11 Jun '11

11 Jun '11

Paul Harper <pauljharper(a)gmail.com> writes: > Thanks guys > it does seem to be there.. Thing is I was trying system-apropos with > "hunchentoot", also with "http" and got nothing. > Of course on windows I get the following messages (when trying to download > cl+ssl) and it seems I must download a libssl32.dll from 'shining light' .. Is > this the recommended way to go? (ql:system-apropos "hunchentoot") should return several items - maybe you had a typo? If you don't want SSL support, you can do this before loading Hunchentoot: (pushnew :hunchentoot-no-ssl *features*) Zach

1 0

Re: [hunchentoot-devel] Hunchentootin in the quicklisp repository?
by Edi Weitz 11 Jun '11

11 Jun '11

Hi, Please send questions related to Hunchentoot to the mailing list - see Cc. As to your question, to my knowledge Hunchentoot is already installable via Quicklisp. Cheers, Edi. On Sat, Jun 11, 2011 at 9:51 AM, Paul Harper <pauljharper(a)gmail.com> wrote: > Hi Edi > Am just getting going in lisp and busy checking out your Hunchentoot > webserver. Do you have any plans to add it to quicklisp repository? or do i > just use quicklisp to download the required libraries? > regards > Paul Harper

2 1

[hunchentoot-devel] Fwd: Intermittent problem with codequarterly website (chunked coding glitch?)
by Peter Seibel 10 Jun '11

10 Jun '11

I have no particular reason to believe Hunchentoot is at fault here but I figured I'd ask in case anyone had seen anything like this. The codequarterly.com website is being served by Apache proxying to Hunchentoot (via ProxyPass and ProxyPassReverse directives in the Apache config) and this user reports occasionally getting back some hinky chunked-coded responses. Any ideas of the top of anyone's head? -Peter ---------- Forwarded message ---------- From: Thomas (AWS), Chris <ccthomas(a)amazon.com> Date: Thu, Jun 9, 2011 at 6:14 PM Subject: Intermittent problem with codequarterly website (chunked coding glitch?) To: "editor(a)codequarterly.com" <editor(a)codequarterly.com> Greetings, This may not be the appropriate place to report this issue, but I couldn't find any technical contact information on your website. Feel free to forward as necessary. Intermittently (maybe 10-20% of the time), when trying to view pages on the codequarterly website, my browser is displaying what appears to be the text of the raw HTML of the page, instead of the rendered page. When I look closer, I see that the text begins with a hexadecimal number (e.g, '1FED'), followed by the usual HTML <DOCTYPE.... Header. I reproduced the problem with curl & took a packet trace (output at end of email), to better see what is going on: % curl -v http://www.codequarterly.com/2011/rich-hickey/ It shows that the response is coming back with chunked coding, but there are two hexadecimal numbers preceding the actual HTML content, instead of just the single number that one would expect from a chunked-coded response. The remainder of the body shows additional "extra" chunk length prefixes. It is almost as if the HTTP server was sending the response body through two passes of chunked encoding. Anyway, you might want to look into how your website software is set up that might be causing this, or perhaps whether there's a proxy that is inappropriately adding its own chunked coding to the response as it passes through. Best Regards, Chris Thomas -- request -- GET /2011/rich-hickey/ HTTP/1.1 User-Agent: curl/7.18.1 (i686-pc-linux-gnu) libcurl/7.18.1 OpenSSL/0.9.8b zlib/1.2.3 Host: www.codequarterly.com Accept: */* -- response -- HTTP/1.1 200 OK Date: Fri, 10 Jun 2011 00:51:12 GMT Transfer-Encoding: chunked Content-Type: text/plain 1f3e 1FE4<!DOCTYPE html> <HTML lang='en'> <HEAD> <META http-equiv='content-type' content='text/html; charset=UTF-8'> <TITLE>Code Quarterly</TITLE> .... -- Peter Seibel http://www.codequarterly.com/

2 1