tbnl-devel

tbnl-devel@common-lisp.net

865 discussions

Re: [hunchentoot-devel] Periodic socket error
by Edi Weitz 22 Dec '06

22 Dec '06

[Please use the mailing list.] On Fri, 22 Dec 2006 14:18:28 -0700, Daniel Gackle <gackle(a)shaw.ca> wrote: > Just out of curiosity, is this the worker thread that originally > sent the response to the browser? i.e. it's waiting for more > response material and dies after a while when there isn't any? Yes, that's most likely the case. There's a HTTP/1.1 connection between the browser and the server that both sides try to keep alive. The server (in the worker thread) keeps on reading (waiting for the next request) and gets a timeout after some time if the user doesn't do anything. The next request will then start a new worker thread.

1 0

[hunchentoot-devel] Debug messages
by Jonathon McKitrick 22 Dec '06

22 Dec '06

I've noticed that when an error occurs in my code, hunchentoot displays an 'internal server error' page. Obviously this is good for a production environment, but during development, how can I see any debug output produced from the lisp system, perhaps in slime? That would be easier than checking log files. Jonathon McKitrick -- My other computer is your Windows box.

3 3

[hunchentoot-devel] Preferred method for login?
by Jonathon McKitrick 20 Dec '06

20 Dec '06

I was searching the mailing list and ran across a couple of ways to set up authorized handlers. Is there an 'official' or recommended way of doing this that works best in practice? Or is there really no wrong way to do it as long as it works? I just want to separate a group of uri's that should have authorization before they can allow access. Jonathon McKitrick -- My other computer is your Windows box.

1 0

[hunchentoot-devel] Starting a server hangs
by Jonathon McKitrick 20 Dec '06

20 Dec '06

Hi all, I'm experimenting with hunchentoot with a view to porting my web app. I have 0.4.11 running on SBCL-1.0 and Ubuntu Linux. I have a default handler set up, and call: (hunchentoot:start-server :port 8888) and it works fine. However, when I call the above function from inside the startup sequence of the asdf system that loads the app, it hangs. What am I doing wrong here? Jonathon McKitrick -- My other computer is your Windows box.

4 10

[hunchentoot-devel] Other http methods allowed?
by Jonathon McKitrick 19 Dec '06

19 Dec '06

I did not see specifically if the other http methods PUT and DELETE are supported. If not, is it correct to assume they could be easily added? Jonathon McKitrick -- My other computer is your Windows box.

2 3

[hunchentoot-devel] I/O timeout error (SBCL)
by vedm 16 Dec '06

16 Dec '06

When I set *catch-errors-p* to nil I often see this error in the debugger: == I/O timeout reading #<SB-SYS:FD-STREAM for "a constant string" {B3E4CA1}> [Condition of type SB-SYS:IO-TIMEOUT] == even though I still get my pages in the browser. Any idea why this happens? -- vedm

2 5

[hunchentoot-devel] tbnl-worker threads
by quasi 07 Dec '06

07 Dec '06

Hey, We are using Apache+mod_lisp2+TBNL for our website. The load has sorta spiked of late, we serve approx 4-5 concurrent pages (which are heavy, computationally and in size). We are using Allegro CL. The thing observed is that there are about 70-100 tbnl-worker threads which I dont think are doing anything much. There is a limit of 230 threads on the Allegro CL and this 100 threads becomes worrysome. I think they have a timeout and the die eventually, but I wonder at their existance and if they could be made to die an early death (I could give them some cig's but ...). :) BTW is it good time to move from TBNL -> Hunchentoot ? Because it's a live system and 'if it aint broke dont fix it' comes to me mind. Any ideas about the performance etc. ? I did some initial benchmarks and seems to be a tad slower than apache+mod_lisp2+TBNL ... but the benchmarks were not serious. I will do them again. thanks, -- quasi Utopia Unlimited!

2 1

[hunchentoot-devel] Problems with create-folder-dispatcher-and-handler
by Rafał Strzaliński 07 Dec '06

07 Dec '06

Hi, I've tried to serve files from 'public' directory under '/' base URL: (hunchentoot::create-folder-dispatcher-and-handler "/" #p"public/") and always got 403 HTTP error. When I've changed base url to for example '/public/' everything works fine. I've tried to fix it, but i'm don't understand pathnames well :-( Any ideas? IMHO (with-chroot (directory) ...) would be an ideal solution :-) Environment: SBCL 1.0 Debian Etch Hunchentoot 0.4.10 -- Best regards, Rafal Strzalinski (nabla) http://rafal.strzalinski.pl

2 1

[hunchentoot-devel] global dispatch-table
by Cyrus Harmon 05 Dec '06

05 Dec '06

What's the rationale behind a global dispatch table? It seems like it might be nicer to have a per-server dispatch table. I can't imagine that there would be a good reason not have access to the server object when accessing *dispatch-table*, although as currently structured process-request should probably take an additional argument for the server. Thanks, Cyrus

2 2

[hunchentoot-devel] dispatch-table request
by Cyrus Harmon 04 Dec '06

04 Dec '06

Edi, First of all, thanks for hunchentoot! I'm still getting used to it, but it seems great so far. But I do have a request. Would it be possible (and advisable) to extend the dispatch table to provide some metadata for each dispatcher? this could even be done in a backward compatible way by allowing the dispatchers in *dispatch-table* to be conses (or objects of an appropriately defined class) which would be examined as necessary, or just funcalled as they are presently, in the event that the dispatcher is just a lambda. This would facilitate debugging and modifying the dispatch table. Thanks, Cyrus

6 7

← Newer
1
...
59
60
61
62
63
64
65
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel