[hunchentoot-devel] usocket:timeout-errors and *catch-errors-p*
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? I gather I can define a method on MAYBE-INVOKE-DEBUGGER to surpress that but I just wanted to make sure that's The Right Thing. -Peter -- Peter Seibel http://www.codequarterly.com/
On Mon, Aug 23, 2010 at 07:26, Peter Seibel <peter@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
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) - ,@clauses)) + `(with-debugger + (handler-case ,expression ,@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@gmail.com>wrote:
If I set *CATCH-ERRORS-P* to NIL, is it expected/desired behavior that
On Mon, Aug 23, 2010 at 07:26, Peter Seibel <peter@gigamonkeys.com> wrote: 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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Peter Seibel http://www.codequarterly.com/
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@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) - ,@clauses)) + `(with-debugger + (handler-case ,expression ,@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@gmail.com> wrote:
On Mon, Aug 23, 2010 at 07:26, Peter Seibel <peter@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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Peter Seibel http://www.codequarterly.com/
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
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@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@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) - ,@clauses)) + `(with-debugger + (handler-case ,expression ,@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@gmail.com> wrote:
On Mon, Aug 23, 2010 at 07:26, Peter Seibel <peter@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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Peter Seibel http://www.codequarterly.com/
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- Peter Seibel http://www.codequarterly.com/
On Tue, Aug 24, 2010 at 1:45 AM, Peter Seibel <peter@gigamonkeys.com> wrote:
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.
No, the point of handler-case* is exactly that it should call maybe-invoke-debugger for /all/ conditions before they can be handled. Otherwise, the source code uses the standard handler-case (without asterisk). I think the question in the case of the problem you report is whether there's some handler-case* that should rather be handler-case or whether we're seeing some behavior we think is acceptable if *catch-errors-p* is nil. Cheers, Edi. PS: Hey Peter, you're hacking Lisp again?
On Tue, Aug 24, 2010 at 8:44 AM, edi <edi@agharta.de> wrote:
I think the question in the case of the problem you report is whether there's some handler-case* that should rather be handler-case or whether we're seeing some behavior we think is acceptable if *catch-errors-p* is nil.
Eek! I now see what the problem is. You're talking about the release version of Hunchentoot while Hans and I are talking about the dev version in the BKNR repository where this problem has been resolved already. I was meaning to make a new release but didn't get around to actually doing it. Maybe I should just do it now... Sorry for the confusion, Edi.
participants (3)
-
Edi Weitz -
Hans Hübner -
Peter Seibel