From jeffrey at cunningham.net Sun Nov 9 03:30:31 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sat, 08 Nov 2008 19:30:31 -0800 Subject: [hunchentoot-devel] blinking hunchentoot logo Message-ID: <49165957.7080902@cunningham.net> 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 From sky at viridian-project.de Sun Nov 9 13:27:46 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 9 Nov 2008 14:27:46 +0100 (CET) Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <49165957.7080902@cunningham.net> References: <49165957.7080902@cunningham.net> Message-ID: <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> > 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. Sounds cool! GIF is a suitable image format, although it's technically possible with MNG too. You can achieve a non-random effect with Gimp, for example. If you build in enough frames you can make it look random enough. Or you can generate the image yourself with Skippy: http://www.xach.com/lisp/skippy/ This method also allows you to generate random transitions on the fly. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From sky at viridian-project.de Sun Nov 9 15:28:34 2008 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 9 Nov 2008 16:28:34 +0100 (CET) Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> Message-ID: <63095.88.73.238.128.1226244514.squirrel@mail.stardawn.org> > no gif please, they are dead! What's wrong with GIF? > this can be easily done with very little js code and a bit of css,and png! Using JS would have the advantage that you could get straight random intervals. But also two disadvantages: cpu overhead (with the current state of JS engines) and non-compatibility with JS-incapable browsers (or just JS turned off). Leslie From stesch at no-spoon.de Sun Nov 9 15:36:02 2008 From: stesch at no-spoon.de (Stefan Scholl) Date: Sun, 9 Nov 2008 16:36:02 +0100 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <49165957.7080902@cunningham.net> References: <49165957.7080902@cunningham.net> Message-ID: <20081109153602.GV21439@parsec.no-spoon.de> On 2008-11-08 19:30:31, Jeff Cunningham wrote: > 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 For her MySpace page? -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ From stesch at no-spoon.de Sun Nov 9 15:35:25 2008 From: stesch at no-spoon.de (Stefan Scholl) Date: Sun, 9 Nov 2008 16:35:25 +0100 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <63095.88.73.238.128.1226244514.squirrel@mail.stardawn.org> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <63095.88.73.238.128.1226244514.squirrel@mail.stardawn.org> Message-ID: <20081109153525.GU21439@parsec.no-spoon.de> On 2008-11-09 16:28:34, Leslie P. Polzer wrote: > random intervals. But also two disadvantages: cpu overhead (with > the current state of JS engines) and non-compatibility with > JS-incapable browsers (or just JS turned off). People with JavaScript turned off mostly don't like any blinking elements on a web page. So, that's OK. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ From jeffrey at cunningham.net Sun Nov 9 16:46:12 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sun, 09 Nov 2008 08:46:12 -0800 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <20081109153602.GV21439@parsec.no-spoon.de> References: <49165957.7080902@cunningham.net> <20081109153602.GV21439@parsec.no-spoon.de> Message-ID: <491713D4.1080603@cunningham.net> Stefan Scholl wrote: > On 2008-11-08 19:30:31, Jeff Cunningham wrote: > >> 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 >> > > For her MySpace page? > > No - she was watching me troubleshoot my website when I had an error page up and was just making an idle comment. From kiuma72 at gmail.com Sun Nov 9 14:44:57 2008 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Sun, 9 Nov 2008 15:44:57 +0100 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> Message-ID: <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> no gif please, they are dead! this can be easily done with very little js code and a bit of css,and png! kiuma On Sun, Nov 9, 2008 at 2:27 PM, Leslie P. Polzer wrote: > >> 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. > > Sounds cool! > > GIF is a suitable image format, although it's technically possible > with MNG too. > > You can achieve a non-random effect with Gimp, for example. > If you build in enough frames you can make it look random enough. > > Or you can generate the image yourself with Skippy: > > http://www.xach.com/lisp/skippy/ > > This method also allows you to generate random transitions on > the fly. > > Leslie > > -- > LinkedIn Profile: http://www.linkedin.com/in/polzer > Xing Profile: https://www.xing.com/profile/LeslieP_Polzer > Blog: http://blog.viridian-project.de/ > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From jeffrey at cunningham.net Sun Nov 9 19:11:38 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sun, 09 Nov 2008 11:11:38 -0800 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> Message-ID: <491735EA.5080901@cunningham.net> Leslie P. Polzer wrote: >> 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. >> > > Sounds cool! > > GIF is a suitable image format, although it's technically possible > with MNG too. > > You can achieve a non-random effect with Gimp, for example. > If you build in enough frames you can make it look random enough. > > Or you can generate the image yourself with Skippy: > > http://www.xach.com/lisp/skippy/ > > This method also allows you to generate random transitions on > the fly. > > Leslie > > The skippy idea is pretty neat - doing it to the spider would make a great little demo. Maybe one of the eyes should be bloodshot once in a while - like he's been up all night on a binge - and then - blink - they're back to normal and people aren't sure they really saw it or not. From pjm at spe.com Sun Nov 9 19:10:30 2008 From: pjm at spe.com (Patrick May) Date: Sun, 9 Nov 2008 14:10:30 -0500 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> Message-ID: <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> Here's a quick hack to display a blinking logo. Put this JavaScript in the head element of your page: Put a named image tag in the body of your page like this: That's it. I've attached the images hacked from the Hunchentoot logo on the website. Hopefully they'll get through the mail list software. Now to modify this to use parenscript.... Regards, Patrick ---- pjm at spe.com S P Engineering, Inc. Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA) -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-logos.tar.gz Type: application/x-gzip Size: 5451 bytes Desc: not available URL: -------------- next part -------------- From jeffrey at cunningham.net Sun Nov 9 20:40:31 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sun, 09 Nov 2008 12:40:31 -0800 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> Message-ID: <49174ABF.1040303@cunningham.net> Patrick May wrote: > Here's a quick hack to display a blinking logo. Put this > JavaScript in the head element of your page: > > > > Put a named image tag in the body of your page like this: > > > > > That's it. I've attached the images hacked from the Hunchentoot > logo on the website. Hopefully they'll get through the mail list > software. Now to modify this to use parenscript.... > > Regards, > > Patrick > The images came through just fine. Thanks, Patrick. I'll see if I can make it work this afternoon. (I wonder how long it will take her to notice...?) Jeff From jeffrey at cunningham.net Sun Nov 9 22:12:34 2008 From: jeffrey at cunningham.net (Jeff Cunningham) Date: Sun, 09 Nov 2008 14:12:34 -0800 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <49174ABF.1040303@cunningham.net> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> Message-ID: <49176052.1060301@cunningham.net> Jeff Cunningham wrote: > Patrick May wrote: > >> Here's a quick hack to display a blinking logo. Put this >> JavaScript in the head element of your page: >> >> hunchentoot logo Jeff From kiuma72 at gmail.com Sun Nov 9 22:43:52 2008 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Sun, 9 Nov 2008 23:43:52 +0100 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <49174ABF.1040303@cunningham.net> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> Message-ID: <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> argh! you need only two imeages one with eyes open and the other with eyes closed, then you have a div with background-image (eyes-open.png); and you can put inside one dive with eyes-closed.png then shape and position the close eyes div accordingly. cheers, kiuma On Sun, Nov 9, 2008 at 9:40 PM, Jeff Cunningham wrote: > > Patrick May wrote: >> Here's a quick hack to display a blinking logo. Put this >> JavaScript in the head element of your page: >> >> >> >> Put a named image tag in the body of your page like this: >> >> >> >> >> That's it. I've attached the images hacked from the Hunchentoot >> logo on the website. Hopefully they'll get through the mail list >> software. Now to modify this to use parenscript.... >> >> Regards, >> >> Patrick >> > The images came through just fine. Thanks, Patrick. I'll see if I can > make it work this afternoon. > (I wonder how long it will take her to notice...?) > > Jeff > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From pjm at spe.com Sun Nov 9 23:40:09 2008 From: pjm at spe.com (Patrick May) Date: Sun, 9 Nov 2008 18:40:09 -0500 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <49176052.1060301@cunningham.net> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> <49176052.1060301@cunningham.net> Message-ID: <0C36D134-F4D5-4E52-9855-6E41831FCB02@spe.com> On 9 Nov 2008, at 17:12, Jeff Cunningham wrote: > I modified the javascript slightly so it would find the images on my > server (in /images/) like this: > But it doesn't work and I have no clue how Javascript works. Is > there a > way to debug it when you hit the page? maybe make it write out what > the > state is of the variables? You can turn on debugging in most browsers. In Safari, doing so gives me a "Develop" menu with a number of items including "Show Error Console" that helps chasing down problems like this. Regards, Patrick ---- pjm at spe.com S P Engineering, Inc. Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA) From pjm at spe.com Sun Nov 9 23:41:41 2008 From: pjm at spe.com (Patrick May) Date: Sun, 9 Nov 2008 18:41:41 -0500 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> Message-ID: <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> On 9 Nov 2008, at 17:43, Andrea Chiumenti wrote: > argh! > > you need only two imeages > one with eyes open and the other with eyes closed, > then you have a div with background-image (eyes-open.png); > and you can put inside one dive with eyes-closed.png > then shape and position the close eyes div accordingly. If it causes you such consternation, please feel free to modify the code I provided. Your textual description fails to compile. ;-) Regards, Patrick ---- pjm at spe.com S P Engineering, Inc. Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA) From rsynnott at gmail.com Mon Nov 10 00:35:31 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Mon, 10 Nov 2008 00:35:31 +0000 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> Message-ID: <24f203480811091635n775153b6ic7dab277958fb3fa@mail.gmail.com> I'm a little puzzled about this; why? Where would it go? On Edi Weitz's Hunchentoot page? Rob From pjm at spe.com Mon Nov 10 01:20:01 2008 From: pjm at spe.com (Patrick May) Date: Sun, 9 Nov 2008 20:20:01 -0500 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <24f203480811091635n775153b6ic7dab277958fb3fa@mail.gmail.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> <24f203480811091635n775153b6ic7dab277958fb3fa@mail.gmail.com> Message-ID: <1CF4B202-D886-4619-A509-6DB22581CF45@spe.com> On 9 Nov 2008, at 19:35, Robert Synnott wrote: > I'm a little puzzled about this; why? Where would it go? On Edi > Weitz's Hunchentoot page? Why? What a strange question. Post hoc, I could say that I did it because I, too, have daughters and wanted to help Jeff mess with his girl's mind. Alternatively, I could say I did it because I had 15 minutes to kill while waiting to play taxi for said daughters. The real reason is probably that it amused me more to make the logo blink than to groom the cat or do a Sudoku. I didn't actually try all that hard to justify the urge. Regards, Patrick ---- pjm at spe.com S P Engineering, Inc. Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA) From kiuma72 at gmail.com Mon Nov 10 10:10:08 2008 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Mon, 10 Nov 2008 11:10:08 +0100 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> Message-ID: <4d3bc9370811100210o72aa3f73ide6f494250bfdd0@mail.gmail.com> Ok :) I didn't see it didn't compile ;p here it is the compiling sample. cheers, kiuma On Mon, Nov 10, 2008 at 12:41 AM, Patrick May wrote: > On 9 Nov 2008, at 17:43, Andrea Chiumenti wrote: >> argh! >> >> you need only two imeages >> one with eyes open and the other with eyes closed, >> then you have a div with background-image (eyes-open.png); >> and you can put inside one dive with eyes-closed.png >> then shape and position the close eyes div accordingly. > > > If it causes you such consternation, please feel free to modify the > code I provided. Your textual description fails to compile. ;-) > > Regards, > > Patrick > > ---- > pjm at spe.com > S P Engineering, Inc. > Large scale, mission-critical, distributed OO systems design and > implementation. > (C++, Java, Common Lisp, Jini, middleware, SOA) > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-ani-logo.tar.gz Type: application/x-gzip Size: 1352 bytes Desc: not available URL: From hans at huebner.org Mon Nov 10 11:40:01 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 10 Nov 2008 12:40:01 +0100 Subject: [hunchentoot-devel] blinking hunchentoot logo In-Reply-To: <4d3bc9370811100210o72aa3f73ide6f494250bfdd0@mail.gmail.com> References: <49165957.7080902@cunningham.net> <64709.88.73.238.128.1226237266.squirrel@mail.stardawn.org> <4d3bc9370811090644o2f1fec7fqd6f5839e5b56f803@mail.gmail.com> <3E4BA46B-63D0-4B6C-A0C1-A2834FE5FE18@spe.com> <49174ABF.1040303@cunningham.net> <4d3bc9370811091443r3eeebc8cp667df2cd20d0385@mail.gmail.com> <70A5C1FE-6D43-4228-9B1B-556DB1093382@spe.com> <4d3bc9370811100210o72aa3f73ide6f494250bfdd0@mail.gmail.com> Message-ID: Yeah, I know it is silly, but I could not resists. 1514 bytes for the animated GIF, no deployment hassle at all (just replace the image). See attached. -Hans On Mon, Nov 10, 2008 at 11:10, Andrea Chiumenti wrote: > Ok :) > I didn't see it didn't compile ;p > > here it is the compiling sample. > cheers, > kiuma > > On Mon, Nov 10, 2008 at 12:41 AM, Patrick May wrote: >> On 9 Nov 2008, at 17:43, Andrea Chiumenti wrote: >>> argh! >>> >>> you need only two imeages >>> one with eyes open and the other with eyes closed, >>> then you have a div with background-image (eyes-open.png); >>> and you can put inside one dive with eyes-closed.png >>> then shape and position the close eyes div accordingly. >> >> >> If it causes you such consternation, please feel free to modify the >> code I provided. Your textual description fails to compile. ;-) >> >> Regards, >> >> Patrick >> >> ---- >> pjm at spe.com >> S P Engineering, Inc. >> Large scale, mission-critical, distributed OO systems design and >> implementation. >> (C++, Java, Common Lisp, Jini, middleware, SOA) >> >> >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: hunchentoot.gif Type: image/gif Size: 1514 bytes Desc: not available URL: From matt.lamari at gmail.com Wed Nov 12 22:08:47 2008 From: matt.lamari at gmail.com (Matthew Lamari) Date: Wed, 12 Nov 2008 16:08:47 -0600 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? Message-ID: (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 From hans at huebner.org Thu Nov 13 11:50:51 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 13 Nov 2008 06:50:51 -0500 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: Message-ID: On Wed, Nov 12, 2008 at 17:08, Matthew Lamari wrote: > 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? No, Hunchentoot currently provides for no control over the number of threads that it creates. In multi threaded mode, a new thread is created for each incoming connection. There may be limits in Lispworks and/or Windows that create the apparent limitation that you observe, but they are not under Hunchentoots control. -Hans From rsynnott at gmail.com Thu Nov 13 12:55:12 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Thu, 13 Nov 2008 12:55:12 +0000 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: Message-ID: <24f203480811130455j390d1d88qa6619e6b08debc51@mail.gmail.com> 2008/11/13 Hans H?bner : > On Wed, Nov 12, 2008 at 17:08, Matthew Lamari wrote: >> 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? > > No, Hunchentoot currently provides for no control over the number of > threads that it creates. In multi threaded mode, a new thread is > created for each incoming connection. There may be limits in > Lispworks and/or Windows that create the apparent limitation that you > observe, but they are not under Hunchentoots control. > Isn't Lispworks limited to one Lisp thread operating at a time? Rob From hans at huebner.org Thu Nov 13 13:39:32 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 13 Nov 2008 08:39:32 -0500 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: <24f203480811130455j390d1d88qa6619e6b08debc51@mail.gmail.com> References: <24f203480811130455j390d1d88qa6619e6b08debc51@mail.gmail.com> Message-ID: On Thu, Nov 13, 2008 at 07:55, Robert Synnott wrote: > Isn't Lispworks limited to one Lisp thread operating at a time? Could be, but Hunchentoot also does not control how many inactive threads it creates. Erm. ? -Hans From stesch at no-spoon.de Thu Nov 13 13:51:10 2008 From: stesch at no-spoon.de (Stefan Scholl) Date: Thu, 13 Nov 2008 14:51:10 +0100 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: Message-ID: <20081113135110.GG21439@parsec.no-spoon.de> On 2008-11-13 06:50:51, Hans H?bner wrote: > No, Hunchentoot currently provides for no control over the number of > threads that it creates. In multi threaded mode, a new thread is > created for each incoming connection. There may be limits in > Lispworks and/or Windows that create the apparent limitation that you > observe, but they are not under Hunchentoots control. As posted here 2005: SBCL can be crashed because of this. http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ From hans at huebner.org Thu Nov 13 14:08:56 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 13 Nov 2008 09:08:56 -0500 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: <20081113135110.GG21439@parsec.no-spoon.de> References: <20081113135110.GG21439@parsec.no-spoon.de> Message-ID: On Thu, Nov 13, 2008 at 08:51, Stefan Scholl wrote: > On 2008-11-13 06:50:51, Hans H?bner wrote: >> No, Hunchentoot currently provides for no control over the number of >> threads that it creates. In multi threaded mode, a new thread is >> created for each incoming connection. There may be limits in >> Lispworks and/or Windows that create the apparent limitation that you >> observe, but they are not under Hunchentoots control. > > As posted here 2005: SBCL can be crashed because of this. > > http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html I recommend running Hunchentoot in single threaded mode behind a caching proxy for that reason. -Hans From matt.lamari at gmail.com Thu Nov 13 14:10:01 2008 From: matt.lamari at gmail.com (Matthew Lamari) Date: Thu, 13 Nov 2008 08:10:01 -0600 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: <24f203480811130455j390d1d88qa6619e6b08debc51@mail.gmail.com> Message-ID: On Thu, Nov 13, 2008 at 7:39 AM, Hans H?bner wrote: > On Thu, Nov 13, 2008 at 07:55, Robert Synnott wrote: >> Isn't Lispworks limited to one Lisp thread operating at a time? > > Could be, but Hunchentoot also does not control how many inactive > threads it creates. Erm. ? > > -Hans > Thanks - your answer has helped me understand what is going on - what I am observing is a legitimate artifact of the number of connections that the browser creates, not a characteristic of hunchentoot (which is satisfying all requests as they are made) - and in my canned example, the browser, not hunchentoot, is controlling the action. From rsynnott at gmail.com Thu Nov 13 14:13:44 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Thu, 13 Nov 2008 14:13:44 +0000 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: <20081113135110.GG21439@parsec.no-spoon.de> References: <20081113135110.GG21439@parsec.no-spoon.de> Message-ID: <24f203480811130613h42503886k63fca461a803bfb@mail.gmail.com> 2008/11/13 Stefan Scholl : > On 2008-11-13 06:50:51, Hans H?bner wrote: >> No, Hunchentoot currently provides for no control over the number of >> threads that it creates. In multi threaded mode, a new thread is >> created for each incoming connection. There may be limits in >> Lispworks and/or Windows that create the apparent limitation that you >> observe, but they are not under Hunchentoots control. > > As posted here 2005: SBCL can be crashed because of this. > > http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html > > I deal with this by first only allowing a certain number of requests to get to the webapp at a time, and second actually throwing away requests as soon as they come in if they hit a higher number. (This no longer happens due to a better webapp; at most I generally have about 10 requests on each of three servers). It's not ideal, and a better solution would probably involve request queueing in a proxy. Running more than one instance per machine and load balancing across them can actually work, as well; it doesn't seem to get overwhelmed as easily. Rob From rsynnott at gmail.com Thu Nov 13 14:15:40 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Thu, 13 Nov 2008 14:15:40 +0000 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: <24f203480811130613h42503886k63fca461a803bfb@mail.gmail.com> References: <20081113135110.GG21439@parsec.no-spoon.de> <24f203480811130613h42503886k63fca461a803bfb@mail.gmail.com> Message-ID: <24f203480811130615s2bc40dffvd790c1bd7bea1e75@mail.gmail.com> 2008/11/13 Robert Synnott : > 2008/11/13 Stefan Scholl : >> On 2008-11-13 06:50:51, Hans H?bner wrote: >>> No, Hunchentoot currently provides for no control over the number of >>> threads that it creates. In multi threaded mode, a new thread is >>> created for each incoming connection. There may be limits in >>> Lispworks and/or Windows that create the apparent limitation that you >>> observe, but they are not under Hunchentoots control. >> >> As posted here 2005: SBCL can be crashed because of this. >> >> http://common-lisp.net/pipermail/tbnl-devel/2005-August/002577.html >> >> > > I deal with this by first only allowing a certain number of requests > to get to the webapp at a time, and second actually throwing away > requests as soon as they come in if they hit a higher number. (This no > longer happens due to a better webapp; at most I generally have about > 10 requests on each of three servers). It's not ideal, and a better > solution would probably involve request queueing in a proxy. > > Running more than one instance per machine and load balancing across > them can actually work, as well; it doesn't seem to get overwhelmed as > easily. > > > Rob > Also, if your webapp is largely processor-bound (no external database etc.), running single-threaded hunchentoot might actually be a viable option. Rob From amalawi at gmail.com Thu Nov 13 15:51:29 2008 From: amalawi at gmail.com (Abu Abdullah Al Jumaee) Date: Thu, 13 Nov 2008 19:51:29 +0400 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: Message-ID: hello, as i understand it most browsers only allow two connections at one time per domain, which limit the transfer (and do not make use of higher internet connection speeds when exists) a solution would be, if i remember it correctly is to fake many sub domains with wildcard dns and then configure your apache aliases to handle it regards Ala'a (cmo-0) On Thu, Nov 13, 2008 at 2:08 AM, Matthew Lamari wrote: > (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 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- It does not matter how fast your code is, if it does not work! From kiuma72 at gmail.com Thu Nov 13 17:09:42 2008 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Thu, 13 Nov 2008 18:09:42 +0100 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: Message-ID: <4d3bc9370811130909k48d06e72oa608f94eb16ffd2d@mail.gmail.com> You can try JMeter to test your webapp http://jakarta.apache.org/jmeter On Thu, Nov 13, 2008 at 4:51 PM, Abu Abdullah Al Jumaee wrote: > hello, > > as i understand it most browsers only allow two connections at one > time per domain, which limit the > transfer (and do not make use of higher internet connection speeds > when exists) a solution would be, > if i remember it correctly is to fake many sub domains with wildcard > dns and then configure your > apache aliases to handle it > > regards > > Ala'a (cmo-0) > > On Thu, Nov 13, 2008 at 2:08 AM, Matthew Lamari wrote: >> (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 >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > > -- > It does not matter how fast your code is, if it does not work! > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From amalawi at gmail.com Thu Nov 13 18:15:42 2008 From: amalawi at gmail.com (Abu Abdullah Al Jumaee) Date: Thu, 13 Nov 2008 22:15:42 +0400 Subject: [hunchentoot-devel] Can we control the number of worker-threads/per-session? In-Reply-To: References: Message-ID: and there is also the simple tools like httperf and openload regards Ala'a (cmo-0) On Thu, Nov 13, 2008 at 2:08 AM, Matthew Lamari wrote: > (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 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- It does not matter how fast your code is, if it does not work! From kengruven at gmail.com Sat Nov 15 23:27:50 2008 From: kengruven at gmail.com (Ken Harris) Date: Sat, 15 Nov 2008 15:27:50 -0800 Subject: [hunchentoot-devel] Deployment Message-ID: 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 From xach at xach.com Sat Nov 15 23:37:22 2008 From: xach at xach.com (Zach Beane) Date: Sat, 15 Nov 2008 18:37:22 -0500 Subject: [hunchentoot-devel] Deployment In-Reply-To: References: Message-ID: <20081115233722.GN21126@xach.com> On Sat, Nov 15, 2008 at 03:27:50PM -0800, Ken Harris wrote: > 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.) I use GNU screen at boot time to start a detached session with emacs and sbcl running. The sbcl additionally loads a Lisp file that loads everything and starts up the swank and hunchentoot servers. Zach From rsynnott at gmail.com Sat Nov 15 23:38:13 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Sat, 15 Nov 2008 23:38:13 +0000 Subject: [hunchentoot-devel] Deployment In-Reply-To: References: Message-ID: <0F3D01D3-9043-4186-AEAA-FC211EE390F7@gmail.com> On 15 Nov 2008, at 23:27, Ken Harris wrote: > 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 I make a core file and then run it in screen, generally with a swank server running. Probably less than ideal, but works. Rob From yazicivo at ttmail.com Sun Nov 16 08:32:03 2008 From: yazicivo at ttmail.com (Volkan YAZICI) Date: Sun, 16 Nov 2008 10:32:03 +0200 Subject: [hunchentoot-devel] Deployment In-Reply-To: (Ken Harris's message of "Sat\, 15 Nov 2008 15\:27\:50 -0800") References: Message-ID: <871vxccbr0.fsf@alamut.mobiliz.com.tr> Hi, On Sat, 15 Nov 2008, "Ken Harris" writes: > 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.) I use swank-daemon[1] to daemonize hunchentoot under GNU screen using swank. (BTW, ALIW[2] uses swank-daemon too.) Regards. [1] http://www.cliki.net/swank-daemon [2] http://aliw.ce.itu.edu.tr/page/Documents#Daemonize_ALIW From amalawi at gmail.com Sun Nov 16 10:03:55 2008 From: amalawi at gmail.com (Abu Abdullah Al Jumaee) Date: Sun, 16 Nov 2008 14:03:55 +0400 Subject: [hunchentoot-devel] Deployment In-Reply-To: References: Message-ID: check this one: http://boinkor.net/archives/2006/02/starting_daemonized_lisp_image_1.html regards Ala'a (cmo-0) On Sun, Nov 16, 2008 at 3:27 AM, Ken Harris wrote: > 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 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- It does not matter how fast your code is, if it does not work! From ch-tbnl at bobobeach.com Sun Nov 16 17:03:35 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sun, 16 Nov 2008 09:03:35 -0800 Subject: [hunchentoot-devel] Hunchentoot and threads Message-ID: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> 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) (# # # # #) 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 From hans at huebner.org Sun Nov 16 19:08:49 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 16 Nov 2008 20:08:49 +0100 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: Hi Cyrus, when you see worker threads accumulate, do you also see that there is a large number of connections to Hunchentoot that are not being closed? Or are there just threads, but no connections? Are you running Hunchentoot behind a proxy/frontend, or standalone? How many dead workers did you see? NB: I do certainly think that it is possible to write threaded web servers that work, I just believe that it is hard, in many respects. Threads, in my personal opinion, are not the best hammer to solve the I/O multiplexing problem that needs to be solved in a web server. Certainly, the unbounded worker thread creation strategy that Hunchentoot uses is not suitable for servers that see load peaks, which is why I recommend not using threaded Hunchentoot for such sites. That said: I do have stability issues with my non-threaded Hunchentoot installation on FreeBSD, too. I use a multi threaded SBCL, but run Hunchentoot in a single thread behind squid. In some situations, no new connections are being accepted for no apparent reasons, but I failed to properly analyze the problem last time it happened as the customer was already nervous. I have seen this happen two times in the last four months, on a moderately busy site. Thus, the problem may actually not be related to Hunchentoot's threads usage (I'm running non-threaded, you run threaded), but could as well be located in SBCL's thread implementation of FreeBSD, in usocket or somewhere else. Any further data points would help getting down to the bottom of this. As for future work on Hunchentoot: We do have the new connection manager class in place which is meant to support the implementation of thread pools. Thread pools would help putting limits on the number of threads created, helping with getting through load peaks. I do not personally need such a connection manager, but rather want to spend some time on making Hunchentoot be able to use single threaded I/O multiplexing using select/kpoll/whatever. -Hans On Sun, Nov 16, 2008 at 18:03, Cyrus Harmon wrote: > > 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) > (# > # > # > # > #) > > 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 > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From rsynnott at gmail.com Sun Nov 16 19:40:38 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Sun, 16 Nov 2008 19:40:38 +0000 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: On 16 Nov 2008, at 19:08, Hans H?bner wrote: > Hi Cyrus, > > when you see worker threads accumulate, do you also see that there is > a large number of connections to Hunchentoot that are not being > closed? Or are there just threads, but no connections? Are you > running Hunchentoot behind a proxy/frontend, or standalone? How many > dead workers did you see? > > NB: I do certainly think that it is possible to write threaded web > servers that work, I just believe that it is hard, in many respects. > Threads, in my personal opinion, are not the best hammer to solve the > I/O multiplexing problem that needs to be solved in a web server. > Certainly, the unbounded worker thread creation strategy that > Hunchentoot uses is not suitable for servers that see load peaks, > which is why I recommend not using threaded Hunchentoot for such > sites. > > That said: I do have stability issues with my non-threaded > Hunchentoot installation on FreeBSD, too. I use a multi threaded > SBCL, but run Hunchentoot in a single thread behind squid. In some > situations, no new connections are being accepted for no apparent > reasons, but I failed to properly analyze the problem last time it > happened as the customer was already nervous. I have seen this happen > two times in the last four months, on a moderately busy site. Thus, > the problem may actually not be related to Hunchentoot's threads usage > (I'm running non-threaded, you run threaded), but could as well be > located in SBCL's thread implementation of FreeBSD, in usocket or > somewhere else. > > Any further data points would help getting down to the bottom of this. > > As for future work on Hunchentoot: We do have the new connection > manager class in place which is meant to support the implementation of > thread pools. Thread pools would help putting limits on the number of > threads created, helping with getting through load peaks. I do not > personally need such a connection manager, but rather want to spend > some time on making Hunchentoot be able to use single threaded I/O > multiplexing using select/kpoll/whatever. > > -Hans On this, I've had no trouble with multi-threaded Hunchentoot for a moderate traffic site (~10 requests per sec, generally a few threads working at a time), on Linux. Rob From achambers.home at googlemail.com Mon Nov 17 13:02:12 2008 From: achambers.home at googlemail.com (Andy Chambers) Date: Mon, 17 Nov 2008 13:02:12 +0000 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: On Sun, Nov 16, 2008 at 7:08 PM, Hans H?bner wrote: > As for future work on Hunchentoot: We do have the new connection > manager class in place which is meant to support the implementation of > thread pools. Thread pools would help putting limits on the number of > threads created, helping with getting through load peaks. I do not > personally need such a connection manager, but rather want to spend > some time on making Hunchentoot be able to use single threaded I/O > multiplexing using select/kpoll/whatever. Is there an existing webserver which uses this technique? I'm interested in seeing the details. From hans at huebner.org Mon Nov 17 13:40:55 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 17 Nov 2008 14:40:55 +0100 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: On Mon, Nov 17, 2008 at 14:02, Andy Chambers wrote: > On Sun, Nov 16, 2008 at 7:08 PM, Hans H?bner wrote: > >> As for future work on Hunchentoot: We do have the new connection >> manager class in place which is meant to support the implementation of >> thread pools. Thread pools would help putting limits on the number of >> threads created, helping with getting through load peaks. I do not >> personally need such a connection manager, but rather want to spend >> some time on making Hunchentoot be able to use single threaded I/O >> multiplexing using select/kpoll/whatever. > > Is there an existing webserver which uses this technique? I'm interested > in seeing the details. IOLIB (http://common-lisp.net/project/iolib/) has an event based HTTP server and is written in Common Lisp. Twisted (http://twistedmatrix.com/trac/) is an event based communications framework written in Python which includes a HTTP server. xlightweb (http://xlightweb.sourceforge.net/) is a HTTP client/server library written in an event oriented fashion in Java, based on the xsocket library. HTH. -Hans From achambers.home at googlemail.com Mon Nov 17 14:27:23 2008 From: achambers.home at googlemail.com (Andy Chambers) Date: Mon, 17 Nov 2008 14:27:23 +0000 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: On Mon, Nov 17, 2008 at 1:40 PM, Hans H?bner wrote: > On Mon, Nov 17, 2008 at 14:02, Andy Chambers > wrote: >> On Sun, Nov 16, 2008 at 7:08 PM, Hans H?bner wrote: >> >>> As for future work on Hunchentoot: We do have the new connection >>> manager class in place which is meant to support the implementation of >>> thread pools. Thread pools would help putting limits on the number of >>> threads created, helping with getting through load peaks. I do not >>> personally need such a connection manager, but rather want to spend >>> some time on making Hunchentoot be able to use single threaded I/O >>> multiplexing using select/kpoll/whatever. >> >> Is there an existing webserver which uses this technique? I'm interested >> in seeing the details. > > IOLIB (http://common-lisp.net/project/iolib/) has an event based HTTP > server and is written in Common Lisp. Twisted > (http://twistedmatrix.com/trac/) is an event based communications > framework written in Python which includes a HTTP server. xlightweb > (http://xlightweb.sourceforge.net/) is a HTTP client/server library > written in an event oriented fashion in Java, based on the xsocket > library. Cool. I also found this discussion on the subject which provided yet more pointers. http://www.kegel.com/c10k.htm -- Andy From ch-tbnl at bobobeach.com Mon Nov 17 15:17:47 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 17 Nov 2008 07:17:47 -0800 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: <20967F43-8F98-4CAB-BED7-71F18E18439B@bobobeach.com> On Nov 16, 2008, at 11:08 AM, Hans H?bner wrote: > Hi Cyrus, > > when you see worker threads accumulate, do you also see that there is > a large number of connections to Hunchentoot that are not being > closed? Or are there just threads, but no connections? Are you > running Hunchentoot behind a proxy/frontend, or standalone? How many > dead workers did you see? So, how do I see if the connections are still open? It's only two so far, but here's what it looks like: CL-USER> (sb-thread:list-all-threads) (# # # # # # # # # #) Here's a backtrace from thread 4: 0: (SB-DEBUG::MAP-BACKTRACE #)[:EXTERNAL] 1: (BACKTRACE 536870911 #) 2: ((FLET SB-UNIX::INTERRUPTION)) 3: ((FLET #:WITHOUT-INTERRUPTS-BODY-[INVOKE-INTERRUPTION]10)) 4: (SB-SYS:INVOKE-INTERRUPTION #) 5: ("foreign function: call_into_lisp") 6: ("foreign function: post_signal_tramp") 7: ("foreign function: nanosleep") 8: ((LAMBDA ())) 9: (SB-C::INVOKE-WITH-SAVED-FP-AND-PC #) 10: (SB-UNIX:NANOSLEEP 0 150000016) 11: (SLEEP 0.15) 12: (SWANK-BACKEND::FLUSH-STREAMS) 13: (SWANK-BACKEND::FLUSH-STREAMS)[:EXTERNAL] 14: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 15: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) 16: (SB-THREAD::CALL-WITH-MUTEX # #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER # :STATE 1) # T) 17: ((LAMBDA ())) 18: ("foreign function: call_into_lisp") 19: ("foreign function: funcall0") 20: ("foreign function: new_thread_trampoline") 21: ("foreign function: _pthread_create") Also, I don't know if it's related, but I see lots of these messages in the log: [2008-11-17 06:59:47 [ERROR]] Error while processing connection: I/O timeout reading #. Thanks for taking a look at this! Cyrus > > > NB: I do certainly think that it is possible to write threaded web > servers that work, I just believe that it is hard, in many respects. > Threads, in my personal opinion, are not the best hammer to solve the > I/O multiplexing problem that needs to be solved in a web server. > Certainly, the unbounded worker thread creation strategy that > Hunchentoot uses is not suitable for servers that see load peaks, > which is why I recommend not using threaded Hunchentoot for such > sites. > > That said: I do have stability issues with my non-threaded > Hunchentoot installation on FreeBSD, too. I use a multi threaded > SBCL, but run Hunchentoot in a single thread behind squid. In some > situations, no new connections are being accepted for no apparent > reasons, but I failed to properly analyze the problem last time it > happened as the customer was already nervous. I have seen this happen > two times in the last four months, on a moderately busy site. Thus, > the problem may actually not be related to Hunchentoot's threads usage > (I'm running non-threaded, you run threaded), but could as well be > located in SBCL's thread implementation of FreeBSD, in usocket or > somewhere else. > > Any further data points would help getting down to the bottom of this. > > As for future work on Hunchentoot: We do have the new connection > manager class in place which is meant to support the implementation of > thread pools. Thread pools would help putting limits on the number of > threads created, helping with getting through load peaks. I do not > personally need such a connection manager, but rather want to spend > some time on making Hunchentoot be able to use single threaded I/O > multiplexing using select/kpoll/whatever. > > -Hans > > On Sun, Nov 16, 2008 at 18:03, Cyrus Harmon > wrote: >> >> 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) >> (# >> # >> # >> # >> #) >> >> 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 >> >> >> _______________________________________________ >> 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 at huebner.org Mon Nov 17 15:49:12 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 17 Nov 2008 16:49:12 +0100 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: <20967F43-8F98-4CAB-BED7-71F18E18439B@bobobeach.com> References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> <20967F43-8F98-4CAB-BED7-71F18E18439B@bobobeach.com> Message-ID: Hi Cyrus, On Mon, Nov 17, 2008 at 16:17, Cyrus Harmon wrote: > On Nov 16, 2008, at 11:08 AM, Hans H?bner wrote: >> when you see worker threads accumulate, do you also see that there is >> a large number of connections to Hunchentoot that are not being >> closed? Or are there just threads, but no connections? Are you >> running Hunchentoot behind a proxy/frontend, or standalone? How many >> dead workers did you see? > > So, how do I see if the connections are still open? On the shell, use "netstat -nf inet | grep [port]", replacing [port] by the port number that the worker thread is serving (35892 and 34650 are the ports for the two workers in the thread list below). > It's only two so far, but here's what it looks like: So this is the situation in which Hunchentoot does not accept more requests? > > CL-USER> (sb-thread:list-all-threads) > (# > # > # > # 66.255.53.123:35892)" RUNNING {5CDF8E91}> > # 66.255.53.123:34650)" RUNNING {5CD329A1}> > # > # > # > # > #) > > Here's a backtrace from thread 4: I may be missing something, but to me, it seems as if this backtrace is coming straight from a Slime REPL threads. Are you sure that it is the backtrace of one of the workers? > > 0: (SB-DEBUG::MAP-BACKTRACE #)[:EXTERNAL] > 1: (BACKTRACE 536870911 # {5812FA99}>) > 2: ((FLET SB-UNIX::INTERRUPTION)) > 3: ((FLET #:WITHOUT-INTERRUPTS-BODY-[INVOKE-INTERRUPTION]10)) > 4: (SB-SYS:INVOKE-INTERRUPTION > #) > 5: ("foreign function: call_into_lisp") > 6: ("foreign function: post_signal_tramp") > 7: ("foreign function: nanosleep") > 8: ((LAMBDA ())) > 9: (SB-C::INVOKE-WITH-SAVED-FP-AND-PC #) > 10: (SB-UNIX:NANOSLEEP 0 150000016) > 11: (SLEEP 0.15) > 12: (SWANK-BACKEND::FLUSH-STREAMS) > 13: (SWANK-BACKEND::FLUSH-STREAMS)[:EXTERNAL] > 14: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) > 15: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) > 16: (SB-THREAD::CALL-WITH-MUTEX > # > #S(SB-THREAD:MUTEX > :NAME "thread result lock" > :%OWNER # {5CBBFF79}> > :STATE 1) > # > T) > 17: ((LAMBDA ())) > 18: ("foreign function: call_into_lisp") > 19: ("foreign function: funcall0") > 20: ("foreign function: new_thread_trampoline") > 21: ("foreign function: _pthread_create") > > Also, I don't know if it's related, but I see lots of these messages > in the log: > > [2008-11-17 06:59:47 [ERROR]] Error while processing connection: I/O > timeout reading #. This is normal, although it needs fixing, two. Usually, clients leave HTTP connections to servers open and servers close them whenever they deem it be neccessary as a part of their resource management strategy. Hunchentoot does this, too, by setting a timeout on all TCP sockets which results in a "I/O timeout" error being generated if any connection is idle for more than a configurable number of seconds. This timeout error must really be caught and muted, as it is no exceptional situation, but rather the simple form of resource management that Hunchentoot implements. -Hans From ch-tbnl at bobobeach.com Mon Nov 17 16:52:49 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 17 Nov 2008 08:52:49 -0800 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> <20967F43-8F98-4CAB-BED7-71F18E18439B@bobobeach.com> Message-ID: On Nov 17, 2008, at 7:49 AM, Hans H?bner wrote: > Hi Cyrus, > > On Mon, Nov 17, 2008 at 16:17, Cyrus Harmon > wrote: >> On Nov 16, 2008, at 11:08 AM, Hans H?bner wrote: > >>> when you see worker threads accumulate, do you also see that there >>> is >>> a large number of connections to Hunchentoot that are not being >>> closed? Or are there just threads, but no connections? Are you >>> running Hunchentoot behind a proxy/frontend, or standalone? How >>> many >>> dead workers did you see? >> >> So, how do I see if the connections are still open? > > On the shell, use "netstat -nf inet | grep [port]", replacing [port] > by the port number that the worker thread is serving (35892 and 34650 > are the ports for the two workers in the thread list below). Ok, thanks. No, the connections do not seem to be open anymore. >> It's only two so far, but here's what it looks like: > > So this is the situation in which Hunchentoot does not accept more > requests? No, not yet. This is just when one of those threads was sticking around. Indeed, I did have the wrong thread for the backtrace. This is one of the worker threads that is hanging around: 0: (SB-DEBUG::MAP-BACKTRACE #)[:EXTERNAL] 1: (BACKTRACE 536870911 #) 2: ((FLET SB-UNIX::INTERRUPTION)) 3: ((FLET #:WITHOUT-INTERRUPTS-BODY-[INVOKE-INTERRUPTION]10)) 4: (SB-SYS:INVOKE-INTERRUPTION #) 5: ("foreign function: call_into_lisp") 6: ("foreign function: post_signal_tramp") 7: ("foreign function: select") 8: ((LAMBDA ())) 9: (SB-C::INVOKE-WITH-SAVED-FP-AND-PC #) 10: ((FLET SB-UNIX::SELECT) #.(SB-SYS:INT-SAP #X2C3DEEF4)) 11: (SB-IMPL::SUB-SUB-SERVE-EVENT 1 0) 12: (SB-IMPL::SUB-SERVE-EVENT 1 0 NIL) 13: (SB-SYS:SERVE-ALL-EVENTS 1) 14: (PROCESS-WAIT # NIL) 15: (RUN-PROGRAM #P"/usr/home/sly/projects/cyrusharmon.org/www.cyrusharmon.org/hunchy/cgi/gitweb.cgi " NIL)[:EXTERNAL] 16: (HUNCHENTOOT-CGI::HANDLE-CGI-SCRIPT #P"/usr/home/sly/projects/cyrusharmon.org/www.cyrusharmon.org/hunchy/cgi/gitweb.cgi " #) 17: (HUNCHENTOOT::PROCESS-REQUEST #) 18: ((SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION (T T)) # # # #) 19: ((SB-PCL::FAST-METHOD HUNCHENTOOT::PROCESS-CONNECTION :AROUND (T T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) # #) 20: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 21: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) 22: (SB-THREAD::CALL-WITH-MUTEX # #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER # :STATE 1) # T) 23: ((LAMBDA ())) 24: ("foreign function: call_into_lisp") 25: ("foreign function: funcall0") 26: ("foreign function: new_thread_trampoline") 27: ("foreign function: _pthread_create") Hrmm.... this suggests that the problem might be in gitweb.cgi or at least in the way I call it with my HT/CGI interface. Interesting... I'll keep an eye out and see if the rest of the stuck threads are in the same boat. thanks again, Cyrus From gwking at metabang.com Mon Nov 17 13:49:09 2008 From: gwking at metabang.com (Gary King) Date: Mon, 17 Nov 2008 08:49:09 -0500 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: Hi Andy, > > Is there an existing webserver which uses this technique? I'm > interested > in seeing the details. Do you mean the thread pool tech or the select technique. AFAIK, aserve uses thread pools; I think nginx (http://www.nginx.net/) uses the select-style. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From franks-muc at web.de Wed Nov 19 16:41:10 2008 From: franks-muc at web.de (franks-muc at web.de) Date: Wed, 19 Nov 2008 17:41:10 +0100 Subject: [hunchentoot-devel] different sessions in different tabs Message-ID: <1423680295@web.de> 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 From rsynnott at gmail.com Wed Nov 19 18:39:23 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Wed, 19 Nov 2008 18:39:23 +0000 Subject: [hunchentoot-devel] different sessions in different tabs In-Reply-To: <1423680295@web.de> References: <1423680295@web.de> Message-ID: <24f203480811191039x75d7d3a3t7a935889e25c5193@mail.gmail.com> 2008/11/19 : > 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 > > _______ Cookies are usually per-browser, not per window. You could probably do your own sessions and pass around an ID as a GET parameter, though that would be messy. Alternatively, you could have a number of different domains; each domain would then get a different session. Rob From ccalca at essex.ac.uk Thu Nov 20 21:24:04 2008 From: ccalca at essex.ac.uk (Xristos Kalkanis) Date: Thu, 20 Nov 2008 21:24:04 +0000 Subject: [hunchentoot-devel] Hunchentoot and threads In-Reply-To: References: <71B68DE1-6110-427A-BD3F-2EA4C86E393A@bobobeach.com> Message-ID: <0DD4D946-1943-4735-8FF1-42B08556FB80@essex.ac.uk> > > Is there an existing webserver which uses this technique? I'm > interested > in seeing the details. > Lighttpd which is used in lots of high-traffic sites is based on kqueue/epoll/poll/select. From lispmr at gmail.com Thu Nov 20 21:27:47 2008 From: lispmr at gmail.com (Harrison Maseko) Date: Thu, 20 Nov 2008 23:27:47 +0200 Subject: [hunchentoot-devel] Help Message-ID: <4925d668.09a8100a.3f8f.fffff7b4@mx.google.com> 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 Lisp. More info about Hunchentoot can be found at http://weitz.de/hunchentoot/. _____ Hunchentoot 0.11.1 (SBCL 1.0.6) 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 # on #. 3: [ACCEPT] Continue, treating # on # 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 # on #. 1: [ACCEPT] Continue, treating # on # 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 # on #. 1: [ACCEPT] Continue, treating # on # 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 # ; registering # 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 # on #. 1: [ACCEPT] Continue, treating # on # 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From avodonosov at yandex.ru Thu Nov 20 23:03:16 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 21 Nov 2008 01:03:16 +0200 Subject: [hunchentoot-devel] Help In-Reply-To: <4925d668.09a8100a.3f8f.fffff7b4@mx.google.com> References: <4925d668.09a8100a.3f8f.fffff7b4@mx.google.com> Message-ID: <1278020052.20081121010316@yandex.ru> Hello Harrison. on Thursday, November 20, 2008, 11:27:47 PM Harrison wrote: As for the first problem: > 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": This is because you do not have OpenSSL library installed on your computer. But OpenSSL is only necessary if you are using your server via HTTPS. You may recompile hunchentoot so that it will not depend on OpenSSL: (eval-when (:compile-toplevel :load-toplevel :execute) (pushnew :hunchentoot-no-ssl *features*) (asdf:oos 'asdf:load-op :hunchentoot)) The second item: > I am currently trying SBCL 1.0.6. via?Cusp v0.8.174 on Windows Vista. [...] > 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\hunchentoot-test.asd > ; into # > ; registering # 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] [...] > 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? I have not used Cusp and therefore can not answer precisely, but locations, from where asdf loads files, are stored in the asdf:*central-registry* variable. Check it's value and set it to right locations, before doing (asdf:oos 'asdf:load-op :hunchentoot-test). Perhaps Cups has a special .lisp file that configures asdf:*central-registry*. If such a file was created at the moment if installation, when your Eclipse was on desktop, the file may still contain the old locations. Hope that helps. If Cusp has mailing list, it may be also helpful to ask there. Best regards, - Anton From lispmr at gmail.com Fri Nov 21 11:19:22 2008 From: lispmr at gmail.com (Harrison Maseko) Date: Fri, 21 Nov 2008 13:19:22 +0200 Subject: [hunchentoot-devel] Help In-Reply-To: <1278020052.20081121010316@yandex.ru> Message-ID: <4926994e.09a8100a.51f1.24c3@mx.google.com> Thanks for the info. Haven't tried it yet but I am eager to give it a try when I get a moment. However, is that the reason why I cannot see past the hunchentoot default page? Regards, Harrison -----Original Message----- From: Anton Vodonosov [mailto:avodonosov at yandex.ru] Sent: Friday, November 21, 2008 1:03 AM To: Harrison Maseko Cc: tbnl-devel at common-lisp.net Subject: Re: [hunchentoot-devel] Help Hello Harrison. on Thursday, November 20, 2008, 11:27:47 PM Harrison wrote: As for the first problem: > 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": This is because you do not have OpenSSL library installed on your computer. But OpenSSL is only necessary if you are using your server via HTTPS. You may recompile hunchentoot so that it will not depend on OpenSSL: (eval-when (:compile-toplevel :load-toplevel :execute) (pushnew :hunchentoot-no-ssl *features*) (asdf:oos 'asdf:load-op :hunchentoot)) The second item: > I am currently trying SBCL 1.0.6. via?Cusp v0.8.174 on Windows Vista. [...] > 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\hunchentoot-test.asd > ; into # > ; registering # 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] [...] > 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? I have not used Cusp and therefore can not answer precisely, but locations, from where asdf loads files, are stored in the asdf:*central-registry* variable. Check it's value and set it to right locations, before doing (asdf:oos 'asdf:load-op :hunchentoot-test). Perhaps Cups has a special .lisp file that configures asdf:*central-registry*. If such a file was created at the moment if installation, when your Eclipse was on desktop, the file may still contain the old locations. Hope that helps. If Cusp has mailing list, it may be also helpful to ask there. Best regards, - Anton Internal Virus Database is out of date. Checked by AVG. Version: 8.0.169 / Virus Database: 270.9.4/1790 - Release Date: 11/15/2008 9:32 AM From avodonosov at yandex.ru Fri Nov 21 21:33:59 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 21 Nov 2008 23:33:59 +0200 Subject: [hunchentoot-devel] Help In-Reply-To: <4926994e.09a8100a.51f1.24c3@mx.google.com> References: <1278020052.20081121010316@yandex.ru> <4926994e.09a8100a.51f1.24c3@mx.google.com> Message-ID: <194946772.20081121233359@yandex.ru> on Friday, November 21, 2008, 1:19:22 PM Harrison wrote: > However, is that the reason why I cannot see past the > hunchentoot default page? To be honest, I do not understand your explanation about test page that worked fine but later became not working. What test page do you mean? From the hunchentoot-test package? And when it worked? When your Eclipse was on desktop? If both yes, the answer is probably yes too. Best regards, - Anton From marko.kocic at gmail.com Tue Nov 25 12:59:39 2008 From: marko.kocic at gmail.com (=?UTF-8?Q?Marko_Koci=C4=87?=) Date: Tue, 25 Nov 2008 13:59:39 +0100 Subject: [hunchentoot-devel] Hunchentoot Ecl port Message-ID: <9238e8de0811250459m44fcd0b7nabaa0f8c326e3f01@mail.gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: port-ecl.lisp Type: application/octet-stream Size: 7730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecl.patch Type: application/octet-stream Size: 510 bytes Desc: not available URL: From avodonosov at yandex.ru Wed Nov 26 00:05:00 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Wed, 26 Nov 2008 02:05:00 +0200 Subject: [hunchentoot-devel] Hunchentoot Ecl port In-Reply-To: <9238e8de0811250459m44fcd0b7nabaa0f8c326e3f01@mail.gmail.com> References: <9238e8de0811250459m44fcd0b7nabaa0f8c326e3f01@mail.gmail.com> Message-ID: <323783.20081126020500@yandex.ru> on Tuesday, November 25, 2008, 2:59:39 PM Marko wrote: > 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. That's a great news! I've just tried too and it works. ECL is the first free multithreaded lisp on Windows running hunchentoot. Best regards - Anton