[hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS brakes ACCEPT-CONNECTIONS loop
Hello, On one server running hunchentoot quite often the following error occurs: 23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 24: (INVOKE-DEBUGGER #) 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL] 26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername") 27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) # # #) 28: ((SB-PCL::FAST-METHOD USOCKET:GET-PEER-ADDRESS (USOCKET:STREAM-USOCKET)) # # #) 29: (HUNCHENTOOT::CLIENT-AS-STRING #) 30: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..) 31: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) # # #) 32: ((LAMBDA ())) As you see, it happens in USOCKET:GET-PEER-ADDRESS called in HANDLE-INCOMING-CONNECTION before the request handling thread is started. This exception breaks the main loop in ACCEPT-CONNECTIONS and server doesn't handle HTTP requests anymore. Most probably these errors are very rare in general, but on this particular machine they happen constantly. Adding ignore-errors to the loop helps - the server doesn't hang anymore. Best regard, - Anton P.S. The problem and the fix suggested are discovered by Andrey Moskvitin, I am just reporting it here.
On Mon, Jan 25, 2010 at 21:25, Anton Vodonosov <avodonosov@yandex.ru> wrote:
On one server running hunchentoot quite often the following error occurs:
23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 24: (INVOKE-DEBUGGER #) 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL] 26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername") 27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) # # #)
I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order to prevent the debugger from being entered when an error is signaled. To me, this looks right: #-:lispworks (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) ;; we are handling all conditions here as we want to make sure that ;; the acceptor process never crashes while trying to create a ;; worker thread; one such problem exists in ;; GET-PEER-ADDRESS-AND-PORT which can signal socket conditions on ;; some platforms in certain situations. (handler-case* (bt:make-thread (lambda () (process-connection (taskmaster-acceptor taskmaster) socket)) :name (format nil "Hunchentoot worker \(client: ~A)" (client-as-string socket))) (error (cond) ;; need to bind *ACCEPTOR* so that LOG-MESSAGE can do its work. (let ((*acceptor* (taskmaster-acceptor taskmaster))) (log-message *lisp-errors-log-level* "Error while creating worker thread for new incoming connection: ~A" cond))))) I might certainly be missing something, so please let me know if this is the case. For production installations, it is not advisable to have *CATCH-ERRORS-P* to be set to NIL. -Hans
I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order to prevent the debugger from being entered when an error is signaled.
Of course, this is a working server and * catch-errors-p * is set to T. The problem arises not because of this. Andrey 26 января 2010 г. 13:16 пользователь Hans Hübner <hans.huebner@gmail.com>написал:
On Mon, Jan 25, 2010 at 21:25, Anton Vodonosov <avodonosov@yandex.ru> wrote:
On one server running hunchentoot quite often the following error occurs:
23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 24: (INVOKE-DEBUGGER #) 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL] 26: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername") 27: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME (SB-BSD-SOCKETS:SOCKET)) # # #)
I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order to prevent the debugger from being entered when an error is signaled. To me, this looks right:
#-:lispworks (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) ;; we are handling all conditions here as we want to make sure that ;; the acceptor process never crashes while trying to create a ;; worker thread; one such problem exists in ;; GET-PEER-ADDRESS-AND-PORT which can signal socket conditions on ;; some platforms in certain situations. (handler-case* (bt:make-thread (lambda () (process-connection (taskmaster-acceptor taskmaster) socket)) :name (format nil "Hunchentoot worker \(client: ~A)" (client-as-string socket)))
(error (cond) ;; need to bind *ACCEPTOR* so that LOG-MESSAGE can do its work. (let ((*acceptor* (taskmaster-acceptor taskmaster))) (log-message *lisp-errors-log-level* "Error while creating worker thread for new incoming connection: ~A" cond)))))
I might certainly be missing something, so please let me know if this is the case. For production installations, it is not advisable to have *CATCH-ERRORS-P* to be set to NIL.
-Hans
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, Jan 26, 2010 at 11:29, Andrey Moskvitin <archimag@gmail.com> wrote:
I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order to prevent the debugger from being entered when an error is signaled. Of course, this is a working server and * catch-errors-p * is set to T. The problem arises not because of this.
[...]
23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 24: (INVOKE-DEBUGGER #) 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
Can you then please explain why INVOKE-DEBUGGER is called? From my reading of the source code, it would only be called if *CATCH-ERRORS-P* is NIL, but I may be missing something. -Hans
I realized I had this problem with hunchentoot-1.0. I corrected it for myself, tested within a month and wrote up in my blog on January 9. This happened before the release of version 1.1. In hunchentoot-1.0 is the following code: #-:lispworks (defmethod handle-incoming-connection ((taskmaster one-thread-per-connection-taskmaster) socket) (bt:make-thread (lambda () (process-connection (taskmaster-acceptor taskmaster) socket)) :name (format nil "Hunchentoot worker \(client: ~A)" (client-as-string socket)))) Which is now fixed, but it seems there was no special message about it:) Andrey 2010/1/26 Hans Hübner <hans.huebner@gmail.com>
On Tue, Jan 26, 2010 at 11:29, Andrey Moskvitin <archimag@gmail.com> wrote:
I think you need to set *CATCH-ERRORS-P* to a non-NIL value in order to prevent the debugger from being entered when an error is signaled. Of course, this is a working server and * catch-errors-p * is set to T. The problem arises not because of this.
[...]
23: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 24: (INVOKE-DEBUGGER #) 25: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
Can you then please explain why INVOKE-DEBUGGER is called? From my reading of the source code, it would only be called if *CATCH-ERRORS-P* is NIL, but I may be missing something.
-Hans
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
participants (3)
-
Andrey Moskvitin -
Anton Vodonosov -
Hans Hübner