[hunchentoot-devel] Socket errors during requests

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 http://bknr.net/trac/browser 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
participants (3)
-
Andrei Stebakov
-
Edi Weitz
-
Hans Hübner