[hunchentoot-devel] Exception in USOCKET:GET-PEER-ADDRESS brakes ACCEPT-CONNECTIONS loop

Hans Hübner hans.huebner at gmail.com
Tue Jan 26 10:16:55 UTC 2010


On Mon, Jan 25, 2010 at 21:25, Anton Vodonosov <avodonosov at 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




More information about the Tbnl-devel mailing list