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

[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] slime foreground buffer for hunchentoot
by Mark H. David 25 May '11

25 May '11

I'm interested in having the ability to break, trace, etc., all the functions running in Hunchentoot. Is there any trick for this? I'd really like to ideally have a SLIME REPL buffer dedicated to it. Has anyone accomplished such a thing? I know Hunchentoot is not running in my main REPL thread. I'm assuming it's just running in one other thread, or mainly in one other thread, making this seem manageable. I'm mostly using CCL and SBCL for devel currently. Thanks, Mark

3 5

[hunchentoot-devel] "start" does not return the acceptor
by Matus Kmit 25 May '11

25 May '11

Hi i installed hunchentoot in clisp via quickload. it seems working well except for the following: The function "start" does not return the acceptor. It creates own, so that the http-server works but it keeps on hanging on the command and does not return to REPL so that i have to break manually. Any help would be appreciated Matus

2 2

Re: [hunchentoot-devel] static files in hunchtentoot 1.1.1
by Edi Weitz 25 May '11

25 May '11

Hi Mark, The URL needs to look like "/exp/...something", i.e. you need a slash after "exp" so that the browser knows how to interpret your GIF URLs. If you write src="foo.gif", the image is looked up relative to the "current directory". So, if the page you're looking at has "/exp/" in it, "exp" is the current directory. But if it only has "/exp" in it (no slash at the end), the current directory is the root directory. If you don't want to change your base URL, you can either use a different relative URL for your images like src="exp/foo.gif" or you can use an absolute URL like src "/exp/foo.gif". This is the way HTML works and it's obviously modeled after similar concepts like the Unix file system. If you don't get the image you're expecting to see, just look at what the browser is actually trying to retrieve from the server. In your original example I bet it tried to retrieve "http://127.0.0.1/leaf.gif" and not "http://127.0.0.1/exp/leaf.gif" as you expected. HTH, Edi. On Tue, May 24, 2011 at 4:23 PM, Mark H. David <mhd(a)yv.org> wrote: > Sorry, Edi, I'm just really lost. Could I ask you to clarify: > > Is your sentence saying what should be done to fix things, or what is wrong currently? > > And, which URL does your sentence refer to, the url-prefix arg to create-folder-..., or the example URL I gave (http://127.0.0.1:1234/exp?default-categorizer*)? > > And, while we're at it, I'm not that sure which direction is "behind"? Does "exp" have a slash behind it in the following string? "/exp" > > I've various things based on various interpretations, but I feel I'm thrashing. :( > > Thanks, > > Mark > > > ----- Original message ----- > From: "Edi Weitz" <edi(a)weitz.de> > To: "General interest list for Hunchentoot and CL-WEBDAV" <tbnl-devel(a)common-lisp.net> > Date: Tue, 24 May 2011 08:29:09 +0200 > Subject: Re: [hunchentoot-devel] static files in hunchtentoot 1.1.1 > > There's no slash behind "exp" in your URL. > > Edi. > > On Tue, May 24, 2011 at 7:49 AM, Mark H. David <mhd(a)yv.org> wrote: >> I cannot figure out how to serve static files (e.g., blah.gif) in Hunchentoot 1.1.1. >> >> I do >> >> (hunchentoot:create-folder-dispatcher-and-handler "/exp/" "c:\\hunchentoot\\") >> >> and then have a URL >> >> http://127.0.0.1:1234/exp?default-categorizer* >> >> that generates lots of >> >> <img src="leaf.gif"> >> >> and the like. The file "leaf.gif" is in the directory "c:\hunchentoot". >> >> However, the GIF file is not being served. I get the standard substitution image. >> >> What's the solution? >> >> Thanks, >> >> Mark >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel(a)common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> > > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > >

1 0

[hunchentoot-devel] Output a XML file as a Response
by Colin 24 May '11

24 May '11

I want to get a xml response to browser, for example: I have a xml string such as: <person> <name>nick</name> <age>20</age> </person> and I have a request such as: http://localhost:8080/person it will output the xml to browser. Please give me some prompts. Thanks.

1 1

[hunchentoot-devel] static files in hunchtentoot 1.1.1
by Mark H. David 24 May '11

24 May '11

I cannot figure out how to serve static files (e.g., blah.gif) in Hunchentoot 1.1.1. I do (hunchentoot:create-folder-dispatcher-and-handler "/exp/" "c:\\hunchentoot\\") and then have a URL http://127.0.0.1:1234/exp?default-categorizer* that generates lots of <img src="leaf.gif"> and the like. The file "leaf.gif" is in the directory "c:\hunchentoot". However, the GIF file is not being served. I get the standard substitution image. What's the solution? Thanks, Mark

2 1

[hunchentoot-devel] Why doesn't *show-lisp-backtraces-p* work?
by Colin 20 May '11

20 May '11

Hi, Who can give me a help ? I did this: (setf *show-lisp-errors-p* T) (setf *show-lisp-backtraces-p* T) But the *show-lisp-backtraces-p* seems that it does not work. I can't see any backtraces on the page. Did I use it by a wrong way? Thanks.

2 1

[hunchentoot-devel] How to use redirect
by Colin 12 May '11

12 May '11

Hi, I want to use 301 to redirect the request, but I don't know how to do. e.g.: Some one visit my app: http://www.xxxx.com, I want it redirect it to xxx.com I thinks I should use function redirect, but I don't know how. Thanks.

2 4