- tbnl-devel@common-lisp.net - mailman3.common-lisp.net

Re: [hunchentoot-devel] [hunchentoot] start thread (#52)
by Hans Hübner 22 Mar '13

22 Mar '13

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(a)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 > >

1 0

[hunchentoot-devel] spawning threads
by Faré 21 Mar '13

21 Mar '13

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!

1 1

[hunchentoot-devel] Race condition in stop
by Faré 17 Mar '13

17 Mar '13

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

2 3

[hunchentoot-devel] If you ever wanted to access multiple uploaded files...
by Hans Hübner 06 Mar '13

06 Mar '13

See this Stackoverflow thread if you wonder how to access them: http://stackoverflow.com/questions/15249921/how-to-handle-multiple-file-upl… -Hans

1 0

[hunchentoot-devel] Reload in browser seems not to work right
by Willem Rein Oudshoorn 03 Mar '13

03 Mar '13

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.

2 2

[hunchentoot-devel] Need help with basic dispatch
by Gerry Weaver 13 Feb '13

13 Feb '13

Hello All, I am new to Lisp and I have been playing around with Hunchentoot. I don't seem to be able to get dispatch to work. I've tried several things, but to no avail. Should the following code work or have I missed something? (defparameter *httpsd* (hunchentoot:start (make-instance 'hunchentoot:ssl-acceptor :port 4443 :ssl-certificate-file #p"/build/hunchentoot/server.crt" :ssl-privatekey-file #p"/build/hunchentoot/server.key" :document-root #p"/build/"))) (defun upload-message () (princ "Upload")) (push (hunchentoot:create-prefix-dispatcher "/upload" 'upload-message) hunchentoot:*dispatch-table*) A pointer in the right direction would be much appreciated. Thanks, Gerry

3 5

[hunchentoot-devel] Need some help figuring out what I'm doing wrong trying to get post parameters passed properly
by Jim Barrows 11 Feb '13

11 Feb '13

I'm a Lisp newbie trying to use the jquery ui sortable widget ( http://api.jqueryui.com/sortable/) to sort a list of tasks. The plugin posts the list of tasks as: 1. task[]: 37 2. task[]: 36 3. task[]: 38 Which Hunchentoot sees as: [2013-02-09 11:15:34 [DEBUG]] parameters ((task[] . 37) (task[] . 36) (task[] . 38)) However, when I use this handler: (define-easy-handler (task-prioritize-url-handler :uri *task-prioritize*) (tasks) (task-prioritize tasks)) I get: [2013-02-09 11:38:52 [DEBUG]] task-prioritize NIL [2013-02-09 11:38:52 [DEBUG]] parameters ((task[] . 36) (task[] . 38) (task[] . 37)) If I use: (define-easy-handler (task-prioritize-url-handler :uri *task-prioritize*) ((tasks :parameter-type 'array)) (task-prioritize tasks)) I get: [2013-02-09 11:36:07 [DEBUG]] task-prioritize #() [2013-02-09 11:36:07 [DEBUG]] parameters ((task[] . 37) (task[] . 36) (task[] . 38)) If I use: (define-easy-handler (task-prioritize-url-handler :uri *task-prioritize*) ((tasks :parameter-type 'list)) (task-prioritize tasks)) I get: [2013-02-09 11:37:32 [DEBUG]] task-prioritize NIL [2013-02-09 11:37:32 [DEBUG]] parameters ((task[] . 37) (task[] . 36) (task[] . 38)) My understanding from the documentation is that I should end up with a list of id's in the var task when is all said and done. Could someone tell me what I'm doing wrong that that isn't happening? Or help clarify my understanding? Thanks so much! -- James A Barrows

5 8

[hunchentoot-devel] When hunchetoot is listening on multiple addresses how can I find on which address was a specific request received?
by Vassilis Radis 19 Jan '13

19 Jan '13

My acceptor listens on *:80 . I have two interfaces on my machine and I would like to know for each request the specific ip on which it came through. Is that possible and how? Thanks.

4 10

[hunchentoot-devel] Bug (+ fix) in (maybe-handle-range-header ...)
by PL Hayes 18 Jan '13

18 Jan '13

Hi, I've found that <audio> elements won't play (except in Firefox, for some reason) when served by Hunchentoot and that it's because of a small error in the function 'maybe-handle-range-header' in the file 'misc.lisp': (setf (return-code*) +http-partial-content+ bytes-to-send (- end start) ... should be: (setf (return-code*) +http-partial-content+ bytes-to-send (1+ (- end start)) ... Cheers, Paul. PS. While investigating this I also noticed that my version of Hunchentoot is 1.2.7 but it's reported as 1.2.5 in the http headers it sends.

2 3

[hunchentoot-devel] Calculating size of the uploaded file
by Andrei Stebakov 16 Jan '13

16 Jan '13

Hi It's been discussed before (even prior Hunchentoot 1.0.0) that there has to be some way to allow the developer to calculate size of the file being uploaded and act upon that (maybe cancel the upload if the file is too big). Before I did it using a hack into parse-multipart-form-data function where I provided a callback to my own function which calculated the size of (header-in :content-length request) and if it was too big, aborted the request. I wonder if there is a better way to do it with the new architecture? Also if I put my own hacks into the ht code it would be difficult for me to update. Thank you, Andrei

3 6