tbnl-devel November 2008

tbnl-devel@common-lisp.net

20 participants
7 discussions

[hunchentoot-devel] Deployment
by Ken Harris 05 Dec '08

05 Dec '08

Hi, all, OK, this maybe isn't 100% Hunchentoot-specific, but it's kind of relevant... I can't find any information about actually deploying a Hunchentoot web app (or any other Lisp server process). So far I've just been running it under SLIME in Emacs on my dev box. With *other platforms* (ugh, I know I'm not supposed to say that), there's often a utility for deploying, or a script you can drop in /etc/init.d, or whatever. I haven't found one for SBCL/Hunchentoot/... yet. How do people typically run these? Just ssh to the server and "sbcl --load myfile.lisp &", where the end of myfile.lisp has a (hunchentoot:start-server ...) call? Something clever with ASDF? (N.b., I barely understand ASDF.) Thanks! - Ken

7 6

[hunchentoot-devel] different sessions in different tabs
by franks-muc＠web.de 02 Dec '08

02 Dec '08

If I start two "sessions" at a hunchentoot page from two different tabs in firefox, the *session* object accessible in the handler is the same for requests from both tabs. I would want to track the sessions separately. In a next step I would introduce user authentication, and hope that only one authentication is necessary to start plural sessions from different tabs. Is there a standard way to achieve these functionalities ? Thank you for your comments. Frank _________________________________________________________________________ Sensationsangebot nur bis 30.11: WEB.DE FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K13805B7069a

3 2

[hunchentoot-devel] Hunchentoot Ecl port
by Marko Kocić 26 Nov '08

26 Nov '08

Some time ago someone Geo tried to port hunchentoot to ecl. Since all current hunchentoot dependencies now work with Ecl, his port now works. Here's a slightly modified version of his port attached. Using it I succeded in running hunchentoot test. There are still some problems with utf-8, but tests basically works. Regards, Marko

2 1

[hunchentoot-devel] Help
by Harrison Maseko 21 Nov '08

21 Nov '08

Hi all, I am learning to program and I am currently trying SBCL 1.0.6. via Cusp v0.8.174 on Windows Vista. The first time I started the server on port 4242 to sample the test page everything seemed to work just fine. Any later try to access the test page, however, gives me the following message in both IE7 and Chrome: "Hunchentoot Default Page This the Hunchentoot default page. You're most likely seeing it because the server administrator hasn't set up a custom default page yet. Hunchentoot is a web server written in Common <http://www.lisp.org/> Lisp. More info about Hunchentoot can be found at http://weitz.de/hunchentoot/. _____ Hunchentoot 0.11.1 <http://weitz.de/hunchentoot/> (SBCL 1.0.6) <http://www.sbcl.org/> at localhost:4242" and it ends there. But before trying to access the page, I get the following error messages when loading hunchentoot of which messages I have no idea what they mean: Unable to load foreign library (LIBSSL). Error opening shared object "libssl32.dll": 126. [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR] 0: [RETRY] Try loading the foreign library again. 1: [USE-VALUE] Use another library instead. 2: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "reload" {A70BD89}>. 3: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "reload" {A70BD89}> as having been successful. 4: [ABORT] Return to SLIME's top level. 5: [CLOSE-CONNECTION] Close SLIME connection 6: [ABORT] Exit debugger, returning to top level. ]> 3 Undefined alien: "SSL_get_version" [Condition of type UNDEFINED-ALIEN-ERROR] 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "ffi" {A70BDA9}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "ffi" {A70BDA9}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. ]> 1 Undefined alien: "SSL_read" [Condition of type UNDEFINED-ALIEN-ERROR] 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "streams" {A70BDD9}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {A70BD69}> on #<ASDF:CL-SOURCE-FILE "streams" {A70BDD9}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. Then when I do (asdf:oos 'asdf:load-op :hunchentoot-test) I get the following: ; loading system definition from ; C:\Program Files\eclipse\plugins\jasko.tim.lisp.libs_1.0.0\libs\hunchentoot-0.11.1\hunc hentoot-test.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM :HUNCHENTOOT-TEST {B6AD791}> as HUNCHENTOOT-TEST error opening #P"C:\\Users\\hmaseko\\Desktop\\eclipse\\plugins\\jasko.tim.lisp.libs_1.0.0\ \libs\\hunchentoot-0.11.1\\test\\fz.jpg": No such file or directory [Condition of type SB-INT:SIMPLE-FILE-ERROR] 0: [RETRY] Retry performing #<ASDF:LOAD-OP NIL {B535AF1}> on #<ASDF:CL-SOURCE-FILE "test" {B6F3DE1}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {B535AF1}> on #<ASDF:CL-SOURCE-FILE "test" {B6F3DE1}> as having been successful. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. ]> 1 I am wondering why at some point the path is pointing to my desktop. True, I kept my Eclipse SDK there for a while before moving it to it's permanent location in c:/program files/ but why is the error occuring? There is something I am doing wrong. What is it? Regards, Harrison.

2 3

[hunchentoot-devel] Hunchentoot and threads
by Cyrus Harmon 20 Nov '08

20 Nov '08

I seem to recall that, a long time ago, TBNL/hunchentoot required threads. At some point Edi rigged up a singled threaded version but claimed that that was just for development/testing work and shouldn't be used in the real world. Now I understand that Hans has an aversion to threads as the multiplexing abstraction for webservers and that single threaded is "the one true way." I bring this up as background to me real problem, which is that, at least on FreeBSD, I seem to have a number of zombie threads that stick around after requests are made. Before I dig into the problem, I'd be curious to hear what folks' recommendations for running a low-traffic, but nevertheless hopefully reliable, site are. I had reasonably good luck with SBCL+threads and hunchentoot before the big rewrite, but since then, it has been reliable refusing to accept new connections after a week or two of use. Everything starts out fine and I can field some traffic and all is good: CL-USER> (sb-thread:list-all-threads) (#<SB-THREAD:THREAD "reader-thread" RUNNING {59B6B241}> #<SB-THREAD:THREAD "repl-thread" RUNNING {59B6B0F1}> #<SB-THREAD:THREAD "control-thread" RUNNING {59B60359}> #<SB-THREAD:THREAD "auto-flush-thread" RUNNING {59B601D9}> #<SB-THREAD:THREAD "initial thread" RUNNING {598D79B1}>) However, after some period, I see an accumulation of worker threads that won't die and eventually I'm unable to start a new thread to field the request. Who knows where the problem is... Could be in hunchentoot proper, in usocket, in SBCL's FreeBSD threads, etc... At the moment I don't have any debugging info on the problem, as all seems to be working ok since I restarted the web server a few minutes ago. The next time the problem crops up, I'll reply to this with some debugging information. This seems to be the one major "regression" from the old hunchentoot that has me considering going back to the stable release (although I've already ported my code forward for the new API, so I'd hate to have to do that). Better yet would be to either track down and fix the problem or to be convinced that this is just broken and is never going to work and figure out how to make my stuff work in a single threaded lisp. One more question regarding threads, is it possible to use a threaded lisp to act like the single threaded server does? That is to use threads, but to only have one thread doing the hard work, using serve- event for the multiplexing? My initialization code relies on setting some state after starting to listen for requests, so I can't just flip the switch to single-threaded mode and have everything work out of the box. Thanks for all of the hunchentoot rewrite efforts! On the whole it seems like a good thing, but fixing this issue would make me a much happier hunchentoot user. Cyrus

6 10

[hunchentoot-devel] Can we control the number of worker-threads/per-session?
by Matthew Lamari 13 Nov '08

13 Nov '08

(I'm on lispworks/win32) Aside from questions of the wisdom of controlling this. . . >From my observations, I've seen Hunchentoot limit the number of worker threads within a session (deliberately put "sleep"s into ajax request handlers, then stacked them up). It seemed to limit per-session, another session caused the creation of new threads. I could not find it in the documentation - but is there a way to control the number of workers available for handling requests in total, or per-session? Thanks, Matt

6 11

[hunchentoot-devel] blinking hunchentoot logo
by Jeff Cunningham 10 Nov '08

10 Nov '08

My daughter was looking at the Hunchentoot logo this morning and said she thought someone ought to make it animated so that one the eyes blinks every so often, and then another one - randomly. I don't know how to do that. Does anyone know how to do that? It would be really cool. I suppose it would have to be a GIF though. Jeff

7 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel November 2008