[hunchentoot-devel] usocket:timeout-errors and *catch-errors-p*

[Peter Seibel]

I seem to be able to reproduce it like this:

  - Load a page.

  - Reload twice in quick succession. (I hit Command-R twice as fast as I
can.)

  - Wait about 15-20 seconds.

At that point, three debugger buffers will pop up, all with the same socket
timeout error. I've tried this on Chrome and Firefox, with SBCL 1.0.41 as my
Lisp. I've had the server on both OS X and Debian.

-Peter


On Mon, Aug 23, 2010 at 9:42 PM, Hans Hübner <hans.huebner at gmail.com> wrote:

> Peter,
>
> before moving forward with your patch, I tried to reproduce the wrong
> behavior and failed.  From your report, I would have expected that if
> I set *CATCH-ERRORS-P* to NIL, open a connection to Hunchentoot and
> then wait, I'd be sent to the debugger.  This does not seem to be the
> case, even when I send the initial request line.
>
> Even though I'd think that errors should be intercepted only while
> reading the initial request line, the current behavior seems to be
> acceptable.  Could it be that the timeouts that you see and find
> disturbing are coming from somewhere else?  Can you provide a way to
> reproduce the issue?
>
> Thanks,
> Hans
>
> On Tue, Aug 24, 2010 at 01:45, Peter Seibel <peter at gigamonkeys.com> wrote:
> > So the problem seems to be in READ-INITIAL-REQUEST-LINE where
> HANDLER-CASE*
> > lets MAYBE-INVOKE-DEBUGGER handle the condition before the cases of the
> > HANDLER-CASE.
> > I may well be missing something, but it seems like mabye HANDLER-CASE*
> > should be changed as in the following patch so MAYBE-INVOKE-DEBUGGER is
> only
> > invoked for unhandled conditions.
> > -Peter
> > --- conditions.lisp 2010-08-23 16:29:48.000000000 -0700
> > +++ fixed-conditions.lisp 2010-08-23 16:43:26.000000000 -0700
> > @@ -112,8 +112,8 @@
> >
> >  (defmacro handler-case* (expression &rest clauses)
> >    "Like HANDLER-CASE, but observes *CATCH-ERRORS-P*."
> > -  `(handler-case (with-debugger ,expression)
> > -     , at clauses))
> > +  `(with-debugger
> > +     (handler-case ,expression , at clauses)))
> >
> >  (defun get-backtrace ()
> >    "Returns a string with a backtrace of what the Lisp system thinks is
> >
> > On Sun, Aug 22, 2010 at 11:27 PM, Hans Hübner <hans.huebner at gmail.com>
> > wrote:
> >>
> >> On Mon, Aug 23, 2010 at 07:26, Peter Seibel <peter at gigamonkeys.com>
> wrote:
> >> > If I set *CATCH-ERRORS-P* to NIL, is it expected/desired behavior that
> >> > the
> >> > timeout-errors generated when (I think) the client disconnects without
> >> > making a full request or some such, will land you in the debugger?
> >>
> >> This is a bug.  Timeouts that occur while Hunchentoot is waiting for a
> >> new request should always be ignored.  Timeouts that occur when a
> >> partial request has been request has been received _should_ be
> >> intercepted, though, as those are not part of a normal exchange.
> >>
> >> I've added the issue to our bug tracker.
> >>
> >> -Hans
> >>
> >> _______________________________________________
> >> tbnl-devel site list
> >> tbnl-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> >
> >
> > --
> > Peter Seibel
> > http://www.codequarterly.com/
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
Peter Seibel
http://www.codequarterly.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100823/b8db645f/attachment.html>