My log is full of messages like: [2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O timeout reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}>
If I trap the error stack it's like this:
0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {CFFA47D}>)[:EXTERNAL] 1: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {CFB5DA1}>) 2: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE-TO-STREAM #<SB-IMPL::STRING-OUTPUT-STREAM {CFB5DA1}>) 3: (TRIVIAL-BACKTRACE:PRINT-BACKTRACE 0)[:EXTERNAL] 4: (MY-API::MY-MESSAGE-LOGGER :ERROR "Error while processing connection: ~A" #<SB-SYS:IO-TIMEOUT {CF67F81}>) 5: ((FLET #:LAMBDA121) #<SB-SYS:IO-TIMEOUT {CF67F81}>) 6: (SIGNAL #<SB-SYS:IO-TIMEOUT {CF67F81}>)[:EXTERNAL] 7: (ERROR SB-SYS:IO-TIMEOUT)[:EXTERNAL] 8: (SB-IMPL::SIGNAL-TIMEOUT SB-SYS:IO-TIMEOUT)[:EXTERNAL] 9: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>) 10: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL NIL) 11: (CHUNGA:READ-CHAR* #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL NIL) 12: (CHUNGA:READ-LINE* #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}> NIL) 13: (HUNCHENTOOT::READ-INITIAL-REQUEST-LINE #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>) 14: (HUNCHENTOOT::GET-REQUEST-DATA #<SB-SYS:FD-STREAM for "a socket" {C3DEF69}>) 15: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) #<unavailable argument> #<unavailable argument> #<MY-API::MY-ACCEPTOR (host *, port 3003)> #<USOCKET:STREAM-USOCKET {C3DFF69}>) 16: ((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)) #<MY-API::MY-ACCEPTOR (host *, port 3003)> #<USOCKET:STREAM-USOCKET {C3DFF69}>) 17: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK353]358)) 18: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 19: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267)) 20: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6D20245}> #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER #<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:44453)" RUNNING {C436EA9}> :STATE 1) #<SB-THREAD:THREAD "Hunchentoot worker (client: 127.0.0.1:44453)" RUNNING {C436EA9}>
What could be the reason for the errors?
Thank you, Andrei
On Wed, May 6, 2009 at 01:50, Andrei Stebakov lispercat@gmail.com wrote:
My log is full of messages like: [2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O timeout reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}> What could be the reason for the errors?
These messages are (wrongly) generated by Hunchentoot when an incoming HTTP connection times out. This is a normal operating condition and no error should be generated. It is safe to ignore the log entries. Are you running a recent version of Hunchentoot? I thought that I have fixed this problem a while ago.
-Hans
Yes, I am running Hunchentoot 1.0 which I downloaded from http://weitz.de/files/hunchentoot.tar.gz Where can I get the newer version with the fixed timeout error?
Thank you, Andrei
On Wed, May 6, 2009 at 12:00 AM, Hans Hübner hans.huebner@gmail.com wrote:
On Wed, May 6, 2009 at 01:50, Andrei Stebakov lispercat@gmail.com wrote:
My log is full of messages like: [2009-05-05 19:29:29 [ERROR]] Error while processing connection: I/O
timeout
reading #<SB-SYS:FD-STREAM for "a socket" {D0CDBA9}> What could be the reason for the errors?
These messages are (wrongly) generated by Hunchentoot when an incoming HTTP connection times out. This is a normal operating condition and no error should be generated. It is safe to ignore the log entries. Are you running a recent version of Hunchentoot? I thought that I have fixed this problem a while ago.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, May 6, 2009 at 4:21 PM, Andrei Stebakov lispercat@gmail.com wrote:
Yes, I am running Hunchentoot 1.0 which I downloaded from http://weitz.de/files/hunchentoot.tar.gz Where can I get the newer version with the fixed timeout error?
Sorry for the late reply. I think Hans was actually referring to the latest release version. Failing that, you could try the dev version from bknr.net and see if it makes a difference.
Edi.
Hi Edi
What's the link to dev version of hunchentoot (I don't know how to find it on bknr.net)? Could you be so kind to put instructions how to get the dev version on your main page for Hunchentoot at http://www.weitz.de/hunchentoot/?
Thank you, Andrew
On Thu, May 21, 2009 at 11:08 AM, Edi Weitz edi@agharta.de wrote:
On Wed, May 6, 2009 at 4:21 PM, Andrei Stebakov lispercat@gmail.com wrote:
Yes, I am running Hunchentoot 1.0 which I downloaded from http://weitz.de/files/hunchentoot.tar.gz Where can I get the newer version with the fixed timeout error?
Sorry for the late reply. I think Hans was actually referring to the latest release version. Failing that, you could try the dev version from bknr.net and see if it makes a difference.
Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, May 21, 2009 at 5:40 PM, Andrei Stebakov lispercat@gmail.com wrote:
What's the link to dev version of hunchentoot (I don't know how to find it on bknr.net)?
Start here
and then either look at "trunk/thirdware" or at "ediware".
Could you be so kind to put instructions how to get the dev version on your main page for Hunchentoot at http://www.weitz.de/hunchentoot/?
I'm reluctant to do that. I think that someone who wants to work with the "cutting edge" version should also be prepared to subscribe to the dev mailing list where this link has been mentioned a couple of times. I don't really want to encourage unsuspecting users to use the dev version.
Edi.
I tried the development version from svn:// bknr.net/svn/trunk/thirdparty/hunchentoot Actually, read-initial-request-line has the condition:
(handler-case (let ((*current-error-message* "While reading initial request line:")) (with-mapped-conditions () (read-line* stream))) ((or end-of-file #-:lispworks usocket:timeout-error) () nil))))
Only it doesn't cover the sbcl type error that I have. If I add #+sbcl sb-sys:io-timeout to the handler-case error list, the error is suppressed, but I am not sure it it's the proper fix for everyone. Basically the function that works for me is following: (defun read-initial-request-line (stream) "Reads and returns the initial HTTP request line, catching permitted errors and handling *BREAK-EVEN-WHILE-READING-REQUEST-TYPE-P*. If no request could be read, returns NIL. At this point, both an end-of-file as well as a timeout condition are normal. end-of-file will occur when the client has decided to not send another request but close the connection. A timeout indicates that the connection timeout established by Hunchentoot has expired and we do not want to wait for another request any longer." (let ((*break-on-signals* (and *break-even-while-reading-request-type-p* *break-on-signals*))) (handler-case (let ((*current-error-message* "While reading initial request line:")) (with-mapped-conditions () (read-line* stream))) ((or end-of-file #-:lispworks usocket:timeout-error #+sbcl sb-sys:io-timeout) () nil))))
Thank you, Andrei
On Thu, May 21, 2009 at 12:10 PM, Edi Weitz edi@agharta.de wrote:
On Thu, May 21, 2009 at 5:40 PM, Andrei Stebakov lispercat@gmail.com wrote:
What's the link to dev version of hunchentoot (I don't know how to find
it
on bknr.net)?
Start here
and then either look at "trunk/thirdware" or at "ediware".
Could you be so kind to put instructions how to get the dev version on
your
main page for Hunchentoot at http://www.weitz.de/hunchentoot/?
I'm reluctant to do that. I think that someone who wants to work with the "cutting edge" version should also be prepared to subscribe to the dev mailing list where this link has been mentioned a couple of times. I don't really want to encourage unsuspecting users to use the dev version.
Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, May 21, 2009 at 21:44, Andrei Stebakov lispercat@gmail.com wrote:
Only it doesn't cover the sbcl type error that I have. If I add #+sbcl sb-sys:io-timeout to the handler-case error list, the error is suppressed,
This is actually an usocket error - It should convert the SBCL-specific condition to a portable usocket condition. Can you try to add (sb-sys:io-timeout . timeout-error) to +sbcl-error-map+ in usocket/backend/sbcl.lisp and see if that cures the problem? If it does, I can commit a context diff that you send to the usocket repository.
-Hans
Yes, it works. Thank you, Andrei
On Thu, May 21, 2009 at 4:40 PM, Hans Hübner hans.huebner@gmail.com wrote:
On Thu, May 21, 2009 at 21:44, Andrei Stebakov lispercat@gmail.com wrote:
Only it doesn't cover the sbcl type error that I have. If I add #+sbcl sb-sys:io-timeout to the handler-case error list, the error is
suppressed,
This is actually an usocket error - It should convert the SBCL-specific condition to a portable usocket condition. Can you try to add (sb-sys:io-timeout . timeout-error) to +sbcl-error-map+ in usocket/backend/sbcl.lisp and see if that cures the problem? If it does, I can commit a context diff that you send to the usocket repository.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, May 21, 2009 at 23:07, Andrei Stebakov lispercat@gmail.com wrote:
Yes, it works. Thank you,
Can you send a context diff so that I can fix usocket for everyone?
Thanks, Hans