We just ran into a problem regarding Hunchntoot's handling of unexpected conditions.
Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition.
I'd like to have a way to do something like this in Hunchentoot. I see that the latest version goes further in this direction by having a handler-bind for "error" in the handle-request method. Unfortunately, in our case, the problem occurs before that is in effect.
Are there any plans regarding this, or advice about it? Thanks.
-- Dan
On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb dlw@itasoftware.com wrote:
Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition.
[...]
Are there any plans regarding this, or advice about it?
I do not think that Hunchentoot should continue as if nothing happened when usocket:socket-accept signals an unknown condition. After all, something bad could have happened to the socket, making the following select hang forever or the following accept just signal the same error again, both being undesireable (hanging vs. busy looping).
The real question is: What is the original error that was converted into an unsocket:unknown-error? The condition has a real-error slot that can be examined to find out (and the print method prints it using "The condition ~A occured."). Once the original error is known, it can be decided how usocket must be fixed to map the platform specific error to a usocket condition class and if Hunchentoot can safely ignore this error when it occurs during an accept. Please let us know what you find out.
-Hans
Hans Hübner wrote:
On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb dlw@itasoftware.com wrote:
Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition.
[...]
Are there any plans regarding this, or advice about it?
I do not think that Hunchentoot should continue as if nothing happened when usocket:socket-accept signals an unknown condition.
Yes, I agree. I was thinking in terms of providing a way for the application using Hunchentoot to have a way of controlling what happens next in such a circumstance, such as logging, notifying some other process, etc.
After all, something bad could have happened to the socket, making the following select hang forever or the following accept just signal the same error again, both being undesireable (hanging vs. busy looping).
The real question is: What is the original error that was converted into an unsocket:unknown-error?
In this case, it was an errno 24, which is EMFILE, "too many open files". Yes, ideally usocket would have a generic condition for this. But from my point of view, the most important thing is to have some way to control what happens in the face of a condition that we cannot anticipate.
It would be something like the existing handle-message's handler-bind, but "closer to the base of the stack" so that it would handle conditions signaled within, e.g., accept-connection.
Thanks.
-- Dan
The condition has a real-error slot that can be examined to find out (and the print method prints it using "The condition ~A occured."). Once the original error is known, it can be decided how usocket must be fixed to map the platform specific error to a usocket condition class and if Hunchentoot can safely ignore this error when it occurs during an accept. Please let us know what you find out.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, Mar 2, 2010 at 16:01, Daniel Weinreb dlw@itasoftware.com wrote:
Hans Hübner wrote:
I do not think that Hunchentoot should continue as if nothing happened when usocket:socket-accept signals an unknown condition.
Yes, I agree. I was thinking in terms of providing a way for the application using Hunchentoot to have a way of controlling what happens next in such a circumstance, such as logging, notifying some other process, etc.
I am assuming that you are still running Hunchentoot in single-threaded mode: I would wrap the call to hunchentoot:start in an appropriate error handler and process any unhandled errors as desired. If Hunchentoot does not clean up properly in such an event, I'd consider that to be a bug in Hunchentoot or usocket. Beyond that, I do not think it makes sense to special-case errors coming from usocket (i.e. file system problems can also result in conditions that Hunchentoot does not handle itself and that'd require handling by the caller).
Does that make sense? If not, what exactly are you looking for? Maybe you can just send a patch that we can examine.
Thanks, Hans
-
Daniel Weinreb -
Hans Hübner