From woudshoo at xs4all.nl  Sun Mar  3 17:05:47 2013
From: woudshoo at xs4all.nl (Willem Rein Oudshoorn)
Date: Sun, 03 Mar 2013 18:05:47 +0100
Subject: [hunchentoot-devel] Reload in browser seems not to work right
Message-ID: <m1ip581kic.fsf@xs4all.nl>


I have some issues when I try to reload a page which is served by
hunchentoot. 

Note that this only happens with Safari.  Firefox and Chrome seem 
to behave correctly.

I first observed an issue with weblocks and afterwards I tried plain
hunchentoot.  The plain hunchentoot exhibits different behaviour, but
also a behaviour which seems wrong.

1. Plain hunchentoot
--------------------

I did the following with both SBCL and CCL on MacOSX:

 - start Common Lisp
 - do:  (ql:quickload "hunchentoot")
 - do:  
    (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4242))
   which is copied from the documantation.
 - Point my browser to http://localhost:4242
 - Observation 1:  Everything looks fine
 - do: Reload in browser
 - Observation 2:  The 'made with lisp image' is not visible anymore.
 
Now it seems an additional reload brings the image back.  In fact,
reload in the browser toggles the visibility of the image.

The developer console of safari seems to indicate that 1/2 the times the
request image never arrives.  


2. Weblocks
-----------
Now this might be a problem with weblocks or hunchentoot, howver the
following happens:

 - A reload takes about 2.7 minutes (the original page is loaded
   almost instantaneous.
 - For all my static resources (e.g. javascript files etc), 
   the requests take about 25 seconds and return status 304 
   which is:   +http-not-modified+
 - I have 11 static resources (it seems to be doing about 2 requests in
   parallel??)



Has anybody seen something similar?

3. Versions
-----------
Hunchentoot: 1.2.11
SBCL:  "1.1.3.8-3eed775"
CCL: "Version 1.8-r15416M  (DarwinX8664)"
Safari: Version 6.0.2 (8536.26.17)

Kind regards,
Wim Oudshoorn.




From hans.huebner at gmail.com  Sun Mar  3 17:32:37 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 3 Mar 2013 18:32:37 +0100
Subject: [hunchentoot-devel] Reload in browser seems not to work right
In-Reply-To: <m1ip581kic.fsf@xs4all.nl>
References: <m1ip581kic.fsf@xs4all.nl>
Message-ID: <CABj0bw+KirK1VQMBZWA9P5-qp9HfuiYh-Pv9ypmss94tA_k52A@mail.gmail.com>

Wim,

thank you for the bug report.  The problem was a bug in Hunchentoot that
caused it to set the Content-Length header of a static file response before
the incoming If-modified-since header was dealt with.  This apparently
caused Safari to try to read the response body, which did never complete.

I have pushed a corrective change to github (
https://github.com/edicl/hunchentoot.git).  Can you give it a try and also
check whether the problem with Weblocks is solved by the fix as well?

-Hans


On Sun, Mar 3, 2013 at 6:05 PM, Willem Rein Oudshoorn <woudshoo at xs4all.nl>wrote:

>
> I have some issues when I try to reload a page which is served by
> hunchentoot.
>
> Note that this only happens with Safari.  Firefox and Chrome seem
> to behave correctly.
>
> I first observed an issue with weblocks and afterwards I tried plain
> hunchentoot.  The plain hunchentoot exhibits different behaviour, but
> also a behaviour which seems wrong.
>
> 1. Plain hunchentoot
> --------------------
>
> I did the following with both SBCL and CCL on MacOSX:
>
>  - start Common Lisp
>  - do:  (ql:quickload "hunchentoot")
>  - do:
>     (hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port
> 4242))
>    which is copied from the documantation.
>  - Point my browser to http://localhost:4242
>  - Observation 1:  Everything looks fine
>  - do: Reload in browser
>  - Observation 2:  The 'made with lisp image' is not visible anymore.
>
> Now it seems an additional reload brings the image back.  In fact,
> reload in the browser toggles the visibility of the image.
>
> The developer console of safari seems to indicate that 1/2 the times the
> request image never arrives.
>
>
> 2. Weblocks
> -----------
> Now this might be a problem with weblocks or hunchentoot, howver the
> following happens:
>
>  - A reload takes about 2.7 minutes (the original page is loaded
>    almost instantaneous.
>  - For all my static resources (e.g. javascript files etc),
>    the requests take about 25 seconds and return status 304
>    which is:   +http-not-modified+
>  - I have 11 static resources (it seems to be doing about 2 requests in
>    parallel??)
>
>
>
> Has anybody seen something similar?
>
> 3. Versions
> -----------
> Hunchentoot: 1.2.11
> SBCL:  "1.1.3.8-3eed775"
> CCL: "Version 1.8-r15416M  (DarwinX8664)"
> Safari: Version 6.0.2 (8536.26.17)
>
> Kind regards,
> Wim Oudshoorn.
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130303/1c62460f/attachment.html>

From woudshoo at xs4all.nl  Sun Mar  3 19:00:47 2013
From: woudshoo at xs4all.nl (Willem Rein Oudshoorn)
Date: Sun, 03 Mar 2013 20:00:47 +0100
Subject: [hunchentoot-devel] Reload in browser seems not to work right
References: <m1ip581kic.fsf@xs4all.nl>
	<CABj0bw+KirK1VQMBZWA9P5-qp9HfuiYh-Pv9ypmss94tA_k52A@mail.gmail.com>
Message-ID: <m1a9qk1f6o.fsf@xs4all.nl>

Hans H?bner <hans.huebner at gmail.com> writes:

>
> I have pushed a corrective change to github (
> https://github.com/edicl/hunchentoot.git).  Can you give it a try and also
> check whether the problem with Weblocks is solved by the fix as well?

Thank you, it indeed fixes both issues, scenario 1 as well as the
weblocks problem.

That was a quick find!

Kind regards,
Wim Oudshoorn.




From hans.huebner at gmail.com  Wed Mar  6 21:49:52 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 6 Mar 2013 22:49:52 +0100
Subject: [hunchentoot-devel] If you ever wanted to access multiple uploaded
	files...
Message-ID: <CABj0bwLAhrZLG+ZJ0JmCZfaX=bqPffc2ZEf_Lh7t1dvCkKYsxw@mail.gmail.com>

See this Stackoverflow thread if you wonder how to access them:

http://stackoverflow.com/questions/15249921/how-to-handle-multiple-file-upload-in-hunchentoot/15258756#15258756

-Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130306/f79ae764/attachment.html>

From hans.huebner at gmail.com  Fri Mar  8 20:30:10 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 8 Mar 2013 21:30:10 +0100
Subject: [hunchentoot-devel] Hunchentoot 1.2.14
Message-ID: <CABj0bwJmXLLyzxyH38bmsiLHw3WMZyF-cDQ-1Hrzeo=UxKVWqQ@mail.gmail.com>

Hi,

I have just released Hunchentoot 1.2.14.  This release changes how
ACCEPTOR-STATUS-MESSAGE is called.  Previously, ACCEPTOR-STATUS-MESSAGE was
invoked for all requests, after the handler had been invoked.  If it
returned non-NIL, the content returned by the handler was discarded.  This
did not actually make sense, and I have changed it so that
ACCEPTOR-STATUS-MESSAGE is only called when the handler did not return
contents.  That way, handlers are now free to create their own status
message bodies, if desired.

This is a incompatible change, so if you depended on the previous
invocation sequence, please review your code before upgrading.

The work was funded by Ron Garret, thanks for that!

-Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130308/eb3b8316/attachment.html>

From fahree at gmail.com  Mon Mar 11 21:55:50 2013
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Mon, 11 Mar 2013 17:55:50 -0400
Subject: [hunchentoot-devel] Race condition in stop
Message-ID: <CAN7nBXdxFyb0zwfCxewxiaxL4XwquwsUw7fyDQNYHxXacD4w5A@mail.gmail.com>

When we stop an acceptor, we set the stop flag then shutdown the
taskmaster. But the acceptor will only stop accepting after timeout
and/or after the next connection; in the latter case, said connection
will find itself without a taskmaster to process it, and will be
dropped on the floor without being processed, while possibly leaking a
file descriptor, meanwhile the user on the other end waits 5 minutes
for a TCP timeout. That's not very nice, especially if stop is a
normal part of frequent server rollouts.

To make things better, we could do one or both of these:
1- have the acceptor call the shutdown on the taskmaster after it
catches its last request (or lack thereof).
2- have the acceptor use select or poll, so it can be notified of the
stop in a timely fashion.

Would you accept a patch that does one or the other? What libraries
are or aren't OK to pull into hunchentoot to achieve the second? [I
suppose, any library that doesn't require linking a .so wrapper.]

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
The hacker: someone who figured things out and made something cool happen.
        ? Alan Schmitt



From hans.huebner at gmail.com  Mon Mar 11 22:01:05 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 11 Mar 2013 23:01:05 +0100
Subject: [hunchentoot-devel] Race condition in stop
In-Reply-To: <CAN7nBXdxFyb0zwfCxewxiaxL4XwquwsUw7fyDQNYHxXacD4w5A@mail.gmail.com>
References: <CAN7nBXdxFyb0zwfCxewxiaxL4XwquwsUw7fyDQNYHxXacD4w5A@mail.gmail.com>
Message-ID: <CABj0bw+35KkKjp=zQ2+ikzruXdJM2awC4MZ=syDux1nR-uGWDA@mail.gmail.com>

Hunchentoot must run on Windows and with LispWorks, so patches that break
in either of these environments are unlikely to get pulled.  Other than
that, I'm open to fixes to this problem.

-Hans


On Mon, Mar 11, 2013 at 10:55 PM, Far? <fahree at gmail.com> wrote:

> When we stop an acceptor, we set the stop flag then shutdown the
> taskmaster. But the acceptor will only stop accepting after timeout
> and/or after the next connection; in the latter case, said connection
> will find itself without a taskmaster to process it, and will be
> dropped on the floor without being processed, while possibly leaking a
> file descriptor, meanwhile the user on the other end waits 5 minutes
> for a TCP timeout. That's not very nice, especially if stop is a
> normal part of frequent server rollouts.
>
> To make things better, we could do one or both of these:
> 1- have the acceptor call the shutdown on the taskmaster after it
> catches its last request (or lack thereof).
> 2- have the acceptor use select or poll, so it can be notified of the
> stop in a timely fashion.
>
> Would you accept a patch that does one or the other? What libraries
> are or aren't OK to pull into hunchentoot to achieve the second? [I
> suppose, any library that doesn't require linking a .so wrapper.]
>
> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> http://fare.tunes.org
> The hacker: someone who figured things out and made something cool happen.
>         ? Alan Schmitt
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130311/8a2b5999/attachment.html>

From fahree at gmail.com  Sun Mar 17 17:49:22 2013
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Sun, 17 Mar 2013 13:49:22 -0400
Subject: [hunchentoot-devel] Race condition in stop
In-Reply-To: <CABj0bw+35KkKjp=zQ2+ikzruXdJM2awC4MZ=syDux1nR-uGWDA@mail.gmail.com>
References: <CAN7nBXdxFyb0zwfCxewxiaxL4XwquwsUw7fyDQNYHxXacD4w5A@mail.gmail.com>
	<CABj0bw+35KkKjp=zQ2+ikzruXdJM2awC4MZ=syDux1nR-uGWDA@mail.gmail.com>
Message-ID: <CAN7nBXduBbO2gp3ymC0+doHaU0jZmGKz_QszQb9xQt41__G2ig@mail.gmail.com>

Looking back at the code, it looks like the race condition can be avoided simply
by moving the
  (shutdown (acceptor-taskmaster acceptor))
below the
  (when soft ...)

Do you want me to send a patch / merge request for this simple change?

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
An atheist doesn't have to be someone who thinks he has a proof that there
can't be a god. He only has to be someone who believes that the evidence on
the God question is at a similar level to the evidence on the werewolf
question.  ? John McCarthy


On Mon, Mar 11, 2013 at 6:01 PM, Hans H?bner <hans.huebner at gmail.com> wrote:
> Hunchentoot must run on Windows and with LispWorks, so patches that break in
> either of these environments are unlikely to get pulled.  Other than that,
> I'm open to fixes to this problem.
>
> -Hans
>
>
> On Mon, Mar 11, 2013 at 10:55 PM, Far? <fahree at gmail.com> wrote:
>>
>> When we stop an acceptor, we set the stop flag then shutdown the
>> taskmaster. But the acceptor will only stop accepting after timeout
>> and/or after the next connection; in the latter case, said connection
>> will find itself without a taskmaster to process it, and will be
>> dropped on the floor without being processed, while possibly leaking a
>> file descriptor, meanwhile the user on the other end waits 5 minutes
>> for a TCP timeout. That's not very nice, especially if stop is a
>> normal part of frequent server rollouts.
>>
>> To make things better, we could do one or both of these:
>> 1- have the acceptor call the shutdown on the taskmaster after it
>> catches its last request (or lack thereof).
>> 2- have the acceptor use select or poll, so it can be notified of the
>> stop in a timely fashion.
>>
>> Would you accept a patch that does one or the other? What libraries
>> are or aren't OK to pull into hunchentoot to achieve the second? [I
>> suppose, any library that doesn't require linking a .so wrapper.]
>>
>> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
>> http://fare.tunes.org
>> The hacker: someone who figured things out and made something cool happen.
>>         ? Alan Schmitt
>>
>> _______________________________________________
>> 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



From hans.huebner at gmail.com  Sun Mar 17 18:14:16 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 17 Mar 2013 19:14:16 +0100
Subject: [hunchentoot-devel] Race condition in stop
In-Reply-To: <CAN7nBXduBbO2gp3ymC0+doHaU0jZmGKz_QszQb9xQt41__G2ig@mail.gmail.com>
References: <CAN7nBXdxFyb0zwfCxewxiaxL4XwquwsUw7fyDQNYHxXacD4w5A@mail.gmail.com>
	<CABj0bw+35KkKjp=zQ2+ikzruXdJM2awC4MZ=syDux1nR-uGWDA@mail.gmail.com>
	<CAN7nBXduBbO2gp3ymC0+doHaU0jZmGKz_QszQb9xQt41__G2ig@mail.gmail.com>
Message-ID: <CABj0bwKsdkwQ-mUN0csqNHzHkjS0njvTz3XtL+DnEcHH+Dv+Hw@mail.gmail.com>

Sure, send a pull request.

-Hans


On Sun, Mar 17, 2013 at 6:49 PM, Far? <fahree at gmail.com> wrote:

> Looking back at the code, it looks like the race condition can be avoided
> simply
> by moving the
>   (shutdown (acceptor-taskmaster acceptor))
> below the
>   (when soft ...)
>
> Do you want me to send a patch / merge request for this simple change?
>
> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> http://fare.tunes.org
> An atheist doesn't have to be someone who thinks he has a proof that there
> can't be a god. He only has to be someone who believes that the evidence on
> the God question is at a similar level to the evidence on the werewolf
> question.  ? John McCarthy
>
>
> On Mon, Mar 11, 2013 at 6:01 PM, Hans H?bner <hans.huebner at gmail.com>
> wrote:
> > Hunchentoot must run on Windows and with LispWorks, so patches that
> break in
> > either of these environments are unlikely to get pulled.  Other than
> that,
> > I'm open to fixes to this problem.
> >
> > -Hans
> >
> >
> > On Mon, Mar 11, 2013 at 10:55 PM, Far? <fahree at gmail.com> wrote:
> >>
> >> When we stop an acceptor, we set the stop flag then shutdown the
> >> taskmaster. But the acceptor will only stop accepting after timeout
> >> and/or after the next connection; in the latter case, said connection
> >> will find itself without a taskmaster to process it, and will be
> >> dropped on the floor without being processed, while possibly leaking a
> >> file descriptor, meanwhile the user on the other end waits 5 minutes
> >> for a TCP timeout. That's not very nice, especially if stop is a
> >> normal part of frequent server rollouts.
> >>
> >> To make things better, we could do one or both of these:
> >> 1- have the acceptor call the shutdown on the taskmaster after it
> >> catches its last request (or lack thereof).
> >> 2- have the acceptor use select or poll, so it can be notified of the
> >> stop in a timely fashion.
> >>
> >> Would you accept a patch that does one or the other? What libraries
> >> are or aren't OK to pull into hunchentoot to achieve the second? [I
> >> suppose, any library that doesn't require linking a .so wrapper.]
> >>
> >> ??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics?
> >> http://fare.tunes.org
> >> The hacker: someone who figured things out and made something cool
> happen.
> >>         ? Alan Schmitt
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130317/72653ab6/attachment.html>

From fahree at gmail.com  Thu Mar 21 04:14:02 2013
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Thu, 21 Mar 2013 00:14:02 -0400
Subject: [hunchentoot-devel] spawning threads
Message-ID: <CAN7nBXffi4=i_dLbdfdyfa0pNsDUi0L==zKOeEe4ZYEc3tC=oA@mail.gmail.com>

In quux-hunchentoot, I introduce a gf

(defgeneric start-thread (context thunk &key))

with a method

(defmethod start-thread ((taskmaster thread-pooling-taskmaster) thunk &key name)
  (declare (ignorable taskmaster))
  (bt:make-thread thunk :name name))

that offers an extension point so that applications can specify
bindings, handlers, etc.,
around the spawning of threads.

I believe this technique could be advantageously adopted by
hunchentoot in general.

PS: if this reminds you of "interface-passing style", that's not a coincidence.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
You may call yourself athiest, but I'm athier than you are!



From fahree at gmail.com  Thu Mar 21 19:03:41 2013
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Thu, 21 Mar 2013 15:03:41 -0400
Subject: [hunchentoot-devel] spawning threads
In-Reply-To: <CAN7nBXffi4=i_dLbdfdyfa0pNsDUi0L==zKOeEe4ZYEc3tC=oA@mail.gmail.com>
References: <CAN7nBXffi4=i_dLbdfdyfa0pNsDUi0L==zKOeEe4ZYEc3tC=oA@mail.gmail.com>
Message-ID: <CAN7nBXf82=c5qmgTzpSBpfscOS-11TKEJMJJadOkXDwSTTzD9w@mail.gmail.com>

On Thu, Mar 21, 2013 at 12:14 AM, Far? <fahree at gmail.com> wrote:
> In quux-hunchentoot, I introduce a gf
>
> (defgeneric start-thread (context thunk &key))
>
> with a method
>
> (defmethod start-thread ((taskmaster thread-pooling-taskmaster) thunk &key name)
>   (declare (ignorable taskmaster))
>   (bt:make-thread thunk :name name))
>
> that offers an extension point so that applications can specify
> bindings, handlers, etc.,
> around the spawning of threads.
>
> I believe this technique could be advantageously adopted by
> hunchentoot in general.
>
> PS: if this reminds you of "interface-passing style", that's not a coincidence.
>
Here's the code I'd like to see used (with the function exported):

(in-package :quux-hunchentoot)

(defgeneric start-thread (context thunk &key))

(defmethod start-thread (context thunk &key name)
  (declare (ignorable context))
  #-lispworks
  (bt:make-thread thunk :name name)
  #+lispworks
  (mp:process-run-function name nil thunk))


;;; This overrides the default methods from hunchentoot/taskmaster.lisp,
;;; providing the desired extension point, so you can wrap the
hunchentoot-provided thunk
;;; in a set of default bindings, condition handlers, etc.
(defmethod execute-acceptor ((taskmaster one-thread-per-connection-taskmaster))
  (setf (acceptor-process taskmaster)
        (start-thread
         taskmaster
         (lambda ()
           (accept-connections (taskmaster-acceptor taskmaster)))
         :name (format nil "hunchentoot-listener-~A:~A"
                       (or (acceptor-address (taskmaster-acceptor
taskmaster)) "*")
                       (acceptor-port (taskmaster-acceptor taskmaster))))))

(defmethod create-request-handler-thread ((taskmaster
one-thread-per-connection-taskmaster) socket)
  "Create a thread for handling a single request"
  ;; 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*
   (start-thread
    taskmaster
    (lambda () (handle-incoming-connection% taskmaster socket))
    :name (format nil (taskmaster-worker-thread-name-format
taskmaster) (client-as-string socket)))
   (error (cond)
          ;; need to bind *ACCEPTOR* so that LOG-MESSAGE* can do its work.
          (let ((*acceptor* (taskmaster-acceptor taskmaster)))
            (ignore-errors
              (close (make-socket-stream socket *acceptor*) :abort t))
            (log-message* *lisp-errors-log-level*
                         "Error while creating worker thread for new
incoming connection: ~A" cond)))))

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
I discovered a few years ago that happiness was something you put into life,
not something you get out of it ? and I was transformed.



From hans.huebner at gmail.com  Fri Mar 22 06:49:58 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 22 Mar 2013 07:49:58 +0100
Subject: [hunchentoot-devel] [hunchentoot] start thread (#52)
In-Reply-To: <edicl/hunchentoot/pull/52@github.com>
References: <edicl/hunchentoot/pull/52@github.com>
Message-ID: <CABj0bwJJ+ctByAOhPe=QsnBtAOXXJvP2QpA4Oeu9jJCkpmGD9g@mail.gmail.com>

Fare,

I like the general idea, but I think it would be better to encapsulate the
actual thread starting in Hunchentoot.  The patch you proposed puts the
burden of starting threads onto the user.

I would suggest:

(defgeneric make-thread-function (taskmaster thunk)
  (:method ((taskmaster t) thunk)
    thunk)))

I like the general simplification with the introduction of start-thread,
but that GF should not be part of the public interface.  Also, the
arguments should be (taskmaster thunk &key name).  I see no reason to leave
the argument list open as start-thread is meant to be called only from
within Hunchentoot.

Documentation updates are missing.

Let me know what you think.
-Hans


On Thu, Mar 21, 2013 at 8:54 PM, Fran?ois-Ren? Rideau <
notifications at github.com> wrote:

> Introduce start-thread as an entry point so specialized taskmasters
> can wrap bindings and condition handlers around hunchentoot new thread
> thunks.
>
> Note that LispWorks and non-LispWorks should probably do the same thing
> wrt starting a thread for the acceptor or not. I chose to always start a
> thread, as per the non-LispWorks default. That choice could be reversed.
> But it's probably bad practice to let the LW and non-LW versions diverge on
> such a point.
> ------------------------------
> You can merge this Pull Request by running
>
>   git pull https://github.com/fare/hunchentoot master
>
> Or view, comment on, or merge it at:
>
>   https://github.com/edicl/hunchentoot/pull/52
> Commit Summary
>
>    - Introduce start-thread as an entry point so specialized taskmasters
>
> File Changes
>
>    - *M* packages.lisp<https://github.com/edicl/hunchentoot/pull/52/files#diff-0>(2)
>    - *M* taskmaster.lisp<https://github.com/edicl/hunchentoot/pull/52/files#diff-1>(111)
>
> Patch Links:
>
>    - https://github.com/edicl/hunchentoot/pull/52.patch
>    - https://github.com/edicl/hunchentoot/pull/52.diff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130322/7c67d050/attachment.html>

From hans.huebner at gmail.com  Fri Mar 22 09:05:22 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 22 Mar 2013 10:05:22 +0100
Subject: [hunchentoot-devel] [drakma-devel] Error while trying to POST
	some JSON data
In-Reply-To: <CAJVHqnRr2vGgNmfY8Y97Lt3yp6GzPtyOS+CbyiPgyJh0V2h9FA@mail.gmail.com>
References: <CAJVHqnS1ROFcuUsWmUsWUTYoci3jc_6F8q1ngNqpKysiyJzrbw@mail.gmail.com>
	<514B7F4A.8090106@chatsubo.net>
	<CAJVHqnRr2vGgNmfY8Y97Lt3yp6GzPtyOS+CbyiPgyJh0V2h9FA@mail.gmail.com>
Message-ID: <CABj0bwJOHpkXg1oUiVSfwvaGfNUbkHQ35gpzJvPDu88x7O3Oow@mail.gmail.com>

You can check out the latest cl+ssl - which contains a fix for the problem:

cd ~/quicklisp/local-projects/
git clone git://gitorious.org/cl-plus-ssl/cl-plus-ssl.git

Quicklisp will automatically find cl+ssl from that location.  Remember to
remove that checkout after you've upgraded to a newer quicklisp release
that has the fix in the future.

-Hans


On Thu, Mar 21, 2013 at 10:54 PM, Peter Kuchta <peter at kuchta.co.uk> wrote:

> Kevin,
>
> Thank you very much - I was absolutely sure I was doing something wrong!
>
> Could you please show how I can roll back to cl+ssl-20130128-git ? I don't
> know how to do it, I'm a quicklisp newbie.
>
> Many thanks,
> Piotr
>
> On Thu, Mar 21, 2013 at 9:44 PM, Kevin Raison <raison at chatsubo.net> wrote:
>
>> I encountered this same error after upgrading packages via quicklisp.  I
>> rolled back cl+ssl to version cl+ssl-20130128-git and the problem went
>> away.  I have not had time to investigate further yet.
>>
>> -Kevin
>>
>>
>> On 03/21/2013 02:41 PM, Peter Kuchta wrote:
>> > Hi everybody,
>> >
>> > I'm trying to POST some JSON data to a web service:
>> >
>> >         (ql:quickload :st-json)
>> >         (ql:quickload :cl-json)
>> >         (ql:quickload :drakma)
>> >
>> >         (defvar *rc* (merge-pathnames (user-homedir-pathname) ".apirc"))
>> >
>> >         (defvar *user*
>> >           (with-open-file (s *rc*)
>> >             (st-json:read-json s)))
>> >
>> >         (defvar api-url (st-json:getjso "url" *user*))
>> >         (defvar api-key (st-json:getjso "key" *user*))
>> >         (defvar api-email (st-json:getjso "email" *user*))
>> >
>> >         (setf drakma:*header-stream* *standard-output*)
>> >
>> >         (defvar *req* '(("dataset" . "tigge")
>> >                   ("step"    . "24")
>> >                   ("date"    . "20071001")
>> >                   ("time"    . "00")
>> >                   ("origin"  . "all")))
>> >
>> >         (format t "json:~S~%" (json:encode-json-to-string *req*))
>> >
>> >         (defun retrieve (api request)
>> >           (let* ((cookie-jar (make-instance 'drakma:cookie-jar))
>> >                  (extra-headers (list (cons "From" api-email)
>> >                                       (cons "X-API-KEY" api-key)))
>> >                  (url (concatenate 'string api-url api "/requests"))
>> >                  (stream (drakma:http-request url
>> >                                :additional-headers extra-headers
>> >                                :accept "application/json"
>> >                                :method :post
>> >                                :content-type "application/json"
>> >                                :external-format-out :utf-8
>> >                                :external-format-in :utf-8
>> >                                :redirect 100
>> >                                :cookie-jar cookie-jar
>> >                                :content (json:encode-json-to-string
>> request)
>> >                                :want-stream t)))
>> >               (st-json:read-json stream)))
>> >
>> >      (retrieve "/datasets/tigge" *req*)
>> >
>> > Unfortunately, I get an error, although the data seems to be encoded OK
>> > to JSON and the headers generated by drakma too, I think. Apparently
>> > something is wrong with the :content (the list of integers in the errors
>> > message is just the list of ASCII codes of the JSON encoded data).
>> >
>> >
>> >
>> json:"{\"dataset\":\"tigge\",\"step\":\"24\",\"number\":\"all\",\"levtype\":\"sl\",\"date\":\"20071001\",\"time\":\"00\",\"origin\":\"all\",\"type\":\"pf\",\"param\":\"tp\",\"area\":\"70\\/-130\\/30\\/-60\",\"grid\":\"2\\/2\",\"target\":\"data.grib\"}"
>> >
>> >     POST /v1/datasets/tigge/requests HTTP/1.1
>> >     Host: api.service.int <http://api.service.int>
>> >     User-Agent: Drakma/1.3.0 (SBCL 1.1.5; Darwin; 12.2.0;
>> > http://weitz.de/drakma/)
>> >     Accept: application/json
>> >     Connection: close
>> >     From: me at gmail.com <mailto:me at gmail.com>
>> >     X-API-KEY: 19a0edb6d8d8dda1e6a3b21223e4f86a
>> >     Content-Type: application/json
>> >     Content-Length: 193
>> >
>> >
>> >     debugger invoked on a SIMPLE-TYPE-ERROR:
>> >       The value of CL+SSL::THING is #(123 34 100 97 116 97 115 101 116
>> > 34 58 34
>> >                                   ...), which is not of type
>> (SIMPLE-ARRAY
>> >
>> > (UNSIGNED-BYTE 8)
>> >                                                               (*)).
>> >
>> > Any idea what's wrong with this code? Many thanks in advance.
>> >
>> > Best regards,
>> > Piotr
>> >
>> >
>> > _______________________________________________
>> > drakma-devel mailing list
>> > drakma-devel at common-lisp.net
>> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>> >
>>
>
>
> _______________________________________________
> drakma-devel mailing list
> drakma-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130322/4a4aaff8/attachment.html>

From lucas.r.hope at gmail.com  Wed Mar 27 00:12:36 2013
From: lucas.r.hope at gmail.com (Lucas Hope)
Date: Wed, 27 Mar 2013 11:12:36 +1100
Subject: [hunchentoot-devel] CLOSE_WAIT and errcode 24 (too many files) when
	using https
Message-ID: <CAGSguP2jawiRB2XE7aDEp33qZO9F4zAthkLnj0KDXMrsaYsUmw@mail.gmail.com>

Hi there,

This is a bug report. I'm using Hunchentoot 1.2.2 from quicklisp. I
encountered a server resource limit due to (I think) http connections on an
https port.

Cliffs notes:

https server is not hanging up properly when a connection is attempted
using normal http. This eventually causes the process to hit a kernel
socket limit.

Details:

I recently upgraded my hunchentoot webserver from http to full ssl/https.
The webservice runs on a dedicated port, and I left the port the same.

We had a monitoring service running to check the server was alive. However
the monitoring service wasn't updated to use https.

So every half an hour or so, we got:

[2013-03-26 06:49:26 [ERROR]] Error while processing connection: A failure
in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X04B69660) (return
code: 1). SSL error queue:

error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request


Also, if I connect myself using http instead of https, the browser
connection times out. The server certainly doesn't hang up instantly like
I'd expect.

Last night, my webserver listener threw a bsd socket error - code 24 (too
many files). When I ran an lsof of the process, there were a large number
of long term CLOSE_WAIT connections, which my internet research tells me is
due to the server not closing connections properly. I think the connections
piled up, and I thus hit the socket limit for that process.

Anyone else have that issue? Is it an easy fix?

Cheers,

-Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130327/52e248a1/attachment.html>

From hans.huebner at gmail.com  Wed Mar 27 06:15:24 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 27 Mar 2013 07:15:24 +0100
Subject: [hunchentoot-devel] CLOSE_WAIT and errcode 24 (too many files)
 when using https
In-Reply-To: <CAGSguP2jawiRB2XE7aDEp33qZO9F4zAthkLnj0KDXMrsaYsUmw@mail.gmail.com>
References: <CAGSguP2jawiRB2XE7aDEp33qZO9F4zAthkLnj0KDXMrsaYsUmw@mail.gmail.com>
Message-ID: <CABj0bwJj4rpKGPwViFqYU_cTXZoP7De=EsUyz9nBcERmuQ=xnA@mail.gmail.com>

Luke,

unfortunately, I cannot reproduce the problem in on my machine - I do not
see any open file descriptors left over after I connect to Hunchentoot
server with SSL using a non-SSL client, and when I connect to the same
server using a browser, I get an "Empty response" error.

In order to help you with this, I need you to isolate the problem further.
 Some ideas for debugging:

- Can you create a lingering file descriptor when you connect to your
server using telnet, then disconnect?
- Are the CLOSE_WAIT sockets actually connected to your monitoring service?
- Do you see the CLOSE_WAIT in lsof or in netstat?  I see it in netstat for
sockets that have been closed by the application, but for which the FIN TCP
packet has not been acknowledged by the client.  Note that CLOSE_WAIT
sockets are closed in the application and do no longer consume file
descriptors.  The final TCP handshake is performed by the kernel, and there
is nothing that Hunchentoot can do to make these sockets disappear.

I'm not saying that Hunchentoot has no bugs, but from your description, it
appears to me that your problem is related to your kernel configuration
(you're hitting the system-wide limit for sockets, not the process limit
for file descriptors).

-Hans


On Wed, Mar 27, 2013 at 1:12 AM, Lucas Hope <lucas.r.hope at gmail.com> wrote:

> Hi there,
>
> This is a bug report. I'm using Hunchentoot 1.2.2 from quicklisp. I
> encountered a server resource limit due to (I think) http connections on an
> https port.
>
> Cliffs notes:
>
> https server is not hanging up properly when a connection is attempted
> using normal http. This eventually causes the process to hit a kernel
> socket limit.
>
> Details:
>
> I recently upgraded my hunchentoot webserver from http to full ssl/https.
> The webservice runs on a dedicated port, and I left the port the same.
>
> We had a monitoring service running to check the server was alive. However
> the monitoring service wasn't updated to use https.
>
> So every half an hour or so, we got:
>
> [2013-03-26 06:49:26 [ERROR]] Error while processing connection: A failure
> in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X04B69660) (return
> code: 1). SSL error queue:
>
> error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
>
>
> Also, if I connect myself using http instead of https, the browser
> connection times out. The server certainly doesn't hang up instantly like
> I'd expect.
>
> Last night, my webserver listener threw a bsd socket error - code 24 (too
> many files). When I ran an lsof of the process, there were a large number
> of long term CLOSE_WAIT connections, which my internet research tells me is
> due to the server not closing connections properly. I think the connections
> piled up, and I thus hit the socket limit for that process.
>
> Anyone else have that issue? Is it an easy fix?
>
> Cheers,
>
> -Luke
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130327/805864a7/attachment.html>

From sebyte at smolny.plus.com  Sat Mar 30 20:15:30 2013
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sat, 30 Mar 2013 20:15:30 +0000
Subject: [hunchentoot-devel] Hunchentoot 1.2.14
References: <CABj0bwJmXLLyzxyH38bmsiLHw3WMZyF-cDQ-1Hrzeo=UxKVWqQ@mail.gmail.com>
Message-ID: <ip48eja5.fsf@chimera.gnukahvesi.net>

Quoth Hans H?bner <hans.huebner at gmail.com>:
> [...] I have changed it so that ACCEPTOR-STATUS-MESSAGE is only called when
> the handler did not return contents.

Can you be more specific?  For example, must a handler return NIL for
ACCEPTOR-STATUS-MESSAGE to be called, or will ACCEPTOR-STATUS-MESSAGE also be
called if the handler returns the empty string?

Sebastian
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Sat Mar 30 20:36:54 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 30 Mar 2013 21:36:54 +0100
Subject: [hunchentoot-devel] Hunchentoot 1.2.14
In-Reply-To: <ip48eja5.fsf@chimera.gnukahvesi.net>
References: <CABj0bwJmXLLyzxyH38bmsiLHw3WMZyF-cDQ-1Hrzeo=UxKVWqQ@mail.gmail.com>
	<ip48eja5.fsf@chimera.gnukahvesi.net>
Message-ID: <CABj0bwL3CoaWebMs=73T7CLhTPHZpTm22+TBS1_O0MwH4++vSg@mail.gmail.com>

"did not return contents" means NIL.  If you think that the manual needs
clarification, feel free to send a pull request.

-Hans


On Sat, Mar 30, 2013 at 9:15 PM, Sebastian Tennant
<sebyte at smolny.plus.com>wrote:

> Quoth Hans H?bner <hans.huebner at gmail.com>:
> > [...] I have changed it so that ACCEPTOR-STATUS-MESSAGE is only called
> when
> > the handler did not return contents.
>
> Can you be more specific?  For example, must a handler return NIL for
> ACCEPTOR-STATUS-MESSAGE to be called, or will ACCEPTOR-STATUS-MESSAGE also
> be
> called if the handler returns the empty string?
>
> Sebastian
> --
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130330/795df019/attachment.html>

From sebyte at smolny.plus.com  Sun Mar 31 09:07:53 2013
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sun, 31 Mar 2013 09:07:53 +0000
Subject: [hunchentoot-devel] 404 (page not found) leads to 500 (internal
	server error)
Message-ID: <ehewdjit.fsf@chimera.gnukahvesi.net>

Hi Hans,

While investigating the effect of subclassing ACCEPTOR-STATUS-MESSAGE, I came
across this behaviour:

 CL-USER> (load "srv.lisp")

 The value 404 is not of type SEQUENCE.
   [Condition of type TYPE-ERROR]

--8<---------------cut here---------------start------------->8---
;;; srv.lisp

(in-package "CL-USER")

(asdf:load-system :hunchentoot)
(asdf:load-system :drakma)

(setq tbnl:*catch-errors-p* nil)

(tbnl:start (make-instance
             'tbnl:acceptor
             :document-root nil
             :error-template-directory nil
             :address "127.0.0.1"
             :port 50000))

(write (drakma:http-request "http://127.0.0.1:50000"))
--8<---------------cut here---------------end--------------->8---

I've set TBNL:*CATCH-ERRORS-P* to NIL so that you drop into the debugger.  This
shows that the call (START-OUTPUT 404 ...) results in a (LENGTH 404) call,
which is what fails, but it's not obvious (at least not to me) where this
LENGTH call is coming from.

Sebastian
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: srv.lisp
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130331/6f8fa7a4/attachment.ksh>

From rm at seid-online.de  Sun Mar 31 10:40:09 2013
From: rm at seid-online.de (rm at seid-online.de)
Date: Sun, 31 Mar 2013 12:40:09 +0200
Subject: [hunchentoot-devel] 404 (page not found) leads to 500	(internal
	server error)
In-Reply-To: <ehewdjit.fsf@chimera.gnukahvesi.net>
References: <ehewdjit.fsf@chimera.gnukahvesi.net>
Message-ID: <20130331104009.GA1272@seid-online.de>

On Sun, Mar 31, 2013 at 09:07:53AM +0000, Sebastian Tennant wrote:
> Hi Hans,
> 
> While investigating the effect of subclassing ACCEPTOR-STATUS-MESSAGE, I came
> across this behaviour:
> 
[...]
> I've set TBNL:*CATCH-ERRORS-P* to NIL so that you drop into the debugger.  This
> shows that the call (START-OUTPUT 404 ...) results in a (LENGTH 404) call,
> which is what fails, but it's not obvious (at least not to me) where this
> LENGTH call is coming from.

Does this error message really come from the code you posted?
Your code works fine over here (hunchentoot from the latest quicklisp).
BTW, what you mean with "subclassing ACCEPTOR-STATUS-MESSAGE" ? 
Isn't acceptor-status-message a generic function? 
It almost sounds as if your (?) version of a-s-m returns the
http-status-code instead of an error message.

 Cheers, Ralf Mattes

> Sebastian
> -- 
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
> 

> ;;; ~/common-home/workspace/hunchentoot/srv.lisp
> 
> (in-package "CL-USER")
> 
> (asdf:load-system :hunchentoot)
> (asdf:load-system :drakma)
> 
> (setq tbnl:*catch-errors-p* nil)
> 
> (tbnl:start (make-instance
>              'tbnl:acceptor
>              :document-root nil
>              :error-template-directory nil
>              :address "127.0.0.1"
>              :port 50000))
> 
> (write (drakma:http-request "http://127.0.0.1:50000"))

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From rm at seid-online.de  Sun Mar 31 10:47:23 2013
From: rm at seid-online.de (rm at seid-online.de)
Date: Sun, 31 Mar 2013 12:47:23 +0200
Subject: [hunchentoot-devel] 404 (page not found) leads to 500	(internal
	server error)
In-Reply-To: <ehewdjit.fsf@chimera.gnukahvesi.net>
References: <ehewdjit.fsf@chimera.gnukahvesi.net>
Message-ID: <20130331104723.GB1272@seid-online.de>


BTW, the call to '(length 404)' is probably from within start-output
inheaders.lisp.

HTH RalfD




From sebyte at smolny.plus.com  Sun Mar 31 10:12:36 2013
From: sebyte at smolny.plus.com (Sebastian Tennant)
Date: Sun, 31 Mar 2013 10:12:36 +0000
Subject: [hunchentoot-devel] 404 (page not found) leads to 500	(internal
	server error)
References: <ehewdjit.fsf@chimera.gnukahvesi.net>
	<20130331104009.GA1272@seid-online.de>
Message-ID: <a9pjev3f.fsf@chimera.gnukahvesi.net>

Quoth rm at seid-online.de:
> Does this error message really come from the code you posted?

I'm pretty sure it does, yes.

> Your code works fine over here (hunchentoot from the latest quicklisp).

Hmm... odd.  I'm also using an up-to-date Quicklisp (and the latest SBCL).

> BTW, what you mean with "subclassing ACCEPTOR-STATUS-MESSAGE" ?  Isn't
> acceptor-status-message a generic function?

Yes, of course it is.  I meant to say "specialising ACCEPTOR-STATUS-MESSAGE"
(on a subclass of ACCEPTOR).

> It almost sounds as if your (?) version of a-s-m returns the http-status-code
> instead of an error message.

The error has nothing to do with a specialised A-S-M.  This is out-of-the-box
behaviour I'm observing (as the code was intended to show).

Sebastian
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap




From hans.huebner at gmail.com  Sun Mar 31 11:25:18 2013
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 31 Mar 2013 13:25:18 +0200
Subject: [hunchentoot-devel] 404 (page not found) leads to 500 (internal
 server error)
In-Reply-To: <ehewdjit.fsf@chimera.gnukahvesi.net>
References: <ehewdjit.fsf@chimera.gnukahvesi.net>
Message-ID: <CABj0bwJdMQoq_SJx1TsFNQCmf3Qtx3Ac_-JaJi9sq1DPTayJ=A@mail.gmail.com>

This is fixed in Hunchentoot v1.2.16, thank you for the report.

-Hans


On Sun, Mar 31, 2013 at 11:07 AM, Sebastian Tennant
<sebyte at smolny.plus.com>wrote:

> Hi Hans,
>
> While investigating the effect of subclassing ACCEPTOR-STATUS-MESSAGE, I
> came
> across this behaviour:
>
>  CL-USER> (load "srv.lisp")
>
>  The value 404 is not of type SEQUENCE.
>    [Condition of type TYPE-ERROR]
>
> --8<---------------cut here---------------start------------->8---
> ;;; srv.lisp
>
> (in-package "CL-USER")
>
> (asdf:load-system :hunchentoot)
> (asdf:load-system :drakma)
>
> (setq tbnl:*catch-errors-p* nil)
>
> (tbnl:start (make-instance
>              'tbnl:acceptor
>              :document-root nil
>              :error-template-directory nil
>              :address "127.0.0.1"
>              :port 50000))
>
> (write (drakma:http-request "http://127.0.0.1:50000"))
> --8<---------------cut here---------------end--------------->8---
>
> I've set TBNL:*CATCH-ERRORS-P* to NIL so that you drop into the debugger.
>  This
> shows that the call (START-OUTPUT 404 ...) results in a (LENGTH 404) call,
> which is what fails, but it's not obvious (at least not to me) where this
> LENGTH call is coming from.
>
> Sebastian
> --
> Emacs' AlsaPlayer - Music Without Jolts
> Lightweight, full-featured and mindful of your idyllic happiness.
> http://home.gna.org/eap
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130331/886b3a18/attachment.html>

From lucas.r.hope at gmail.com  Sun Mar 31 23:02:08 2013
From: lucas.r.hope at gmail.com (Lucas Hope)
Date: Mon, 1 Apr 2013 10:02:08 +1100
Subject: [hunchentoot-devel] CLOSE_WAIT and errcode 24 (too many files)
 when using https
In-Reply-To: <CABj0bwJj4rpKGPwViFqYU_cTXZoP7De=EsUyz9nBcERmuQ=xnA@mail.gmail.com>
References: <CAGSguP2jawiRB2XE7aDEp33qZO9F4zAthkLnj0KDXMrsaYsUmw@mail.gmail.com>
	<CABj0bwJj4rpKGPwViFqYU_cTXZoP7De=EsUyz9nBcERmuQ=xnA@mail.gmail.com>
Message-ID: <CAGSguP3Hu_bqx3sCmRuH6cGSxvioJs7o1cJFbv1j3S4xofnVVA@mail.gmail.com>

Hi Hans,

Thanks for testing and replying. After a bit more detective work, I can't
isolate this to Hunchentoot either. A colleague accidentally filled the
disk around the same timeframe this occurred. The monitoring service may
have been holding connections over time, but we have disabled it now.

It seems likely that this was a one-off fluke occurrence, and it won't
bother us again. That being the case, I can't justify digging into it any
more. I reported the issue in case it was a simple bug and easy fix to make
Hunchentoot that little bit more robust (it is very robust already! :-) ).

Hunchentoot is an excellent library which I have used over some years.
Thank you for your ongoing maintenance. I hope I haven't wasted your time.

Regards,

-Luke

On Wed, Mar 27, 2013 at 5:15 PM, Hans H?bner <hans.huebner at gmail.com> wrote:

> Luke,
>
> unfortunately, I cannot reproduce the problem in on my machine - I do not
> see any open file descriptors left over after I connect to Hunchentoot
> server with SSL using a non-SSL client, and when I connect to the same
> server using a browser, I get an "Empty response" error.
>
> In order to help you with this, I need you to isolate the problem further.
>  Some ideas for debugging:
>
> - Can you create a lingering file descriptor when you connect to your
> server using telnet, then disconnect?
> - Are the CLOSE_WAIT sockets actually connected to your monitoring service?
> - Do you see the CLOSE_WAIT in lsof or in netstat?  I see it in netstat
> for sockets that have been closed by the application, but for which the FIN
> TCP packet has not been acknowledged by the client.  Note that CLOSE_WAIT
> sockets are closed in the application and do no longer consume file
> descriptors.  The final TCP handshake is performed by the kernel, and there
> is nothing that Hunchentoot can do to make these sockets disappear.
>
> I'm not saying that Hunchentoot has no bugs, but from your description, it
> appears to me that your problem is related to your kernel configuration
> (you're hitting the system-wide limit for sockets, not the process limit
> for file descriptors).
>
> -Hans
>
>
> On Wed, Mar 27, 2013 at 1:12 AM, Lucas Hope <lucas.r.hope at gmail.com>wrote:
>
>> Hi there,
>>
>> This is a bug report. I'm using Hunchentoot 1.2.2 from quicklisp. I
>> encountered a server resource limit due to (I think) http connections on an
>> https port.
>>
>> Cliffs notes:
>>
>> https server is not hanging up properly when a connection is attempted
>> using normal http. This eventually causes the process to hit a kernel
>> socket limit.
>>
>> Details:
>>
>> I recently upgraded my hunchentoot webserver from http to full ssl/https.
>> The webservice runs on a dedicated port, and I left the port the same.
>>
>> We had a monitoring service running to check the server was alive.
>> However the monitoring service wasn't updated to use https.
>>
>> So every half an hour or so, we got:
>>
>> [2013-03-26 06:49:26 [ERROR]] Error while processing connection: A
>> failure in the SSL library occurred on handle #.(SB-SYS:INT-SAP #X04B69660)
>> (return code: 1). SSL error queue:
>>
>> error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
>>
>>
>> Also, if I connect myself using http instead of https, the browser
>> connection times out. The server certainly doesn't hang up instantly like
>> I'd expect.
>>
>> Last night, my webserver listener threw a bsd socket error - code 24 (too
>> many files). When I ran an lsof of the process, there were a large number
>> of long term CLOSE_WAIT connections, which my internet research tells me is
>> due to the server not closing connections properly. I think the connections
>> piled up, and I thus hit the socket limit for that process.
>>
>> Anyone else have that issue? Is it an easy fix?
>>
>> Cheers,
>>
>> -Luke
>>
>> _______________________________________________
>> 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
>



-- 
---------------------------------------------------
Dr Lucas Hope - lucas.r.hope at skype
Machine Learning and Software Engineering Consultant
Melbourne, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20130401/a894ce8e/attachment.html>