tbnl-devel December 2006

tbnl-devel@common-lisp.net

20 participants
24 discussions

[hunchentoot-devel] Idle thread messages
by Jonathon McKitrick 04 Jan '07

04 Jan '07

I searched the docs for 'idle' and 'thread' and google didn't turn up anything pertinent... is there any reason to be concerned about the idle thread messages that appear from time to time from hunchentoot? During debugging, they can pop up rather frequently in SLIME, and otherwise they are just logged to the console. Does this have anything to do with *cleanup-interval*? Jonathon McKitrick -- My other computer is your Windows box.

5 15

[hunchentoot-devel] Hunchentoot crashing behind mod_lisp with SSL
by Jeffrey Cunningham 28 Dec '06

28 Dec '06

I'm probably doing something dumb but I haven't been able to figure this out. My understanding of Apache is pretty limited. Both apache and my Hunchentoot servers work fine w/o SSL. My Hunchentoot server works fine *with* SSL standalone (not behind mod_lisp). But when I try put it behind mod_lisp and hit the domain with a browser (https://makewavs.com/) the Hunchentoot server goes into debug with the following message: The variable HUNCHENTOOT:*REPLY* is unbound. [Condition of type UNBOUND-VARIABLE] Restarts: 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-worker-305" {D41F4B9}>) Backtrace: 0: ((SB-PCL::FAST-METHOD HUNCHENTOOT:LOG-MESSAGE (T #1="#<...>" . #1#)) #<unused argument> #<unused argument> :ERROR "Error while processing connection: ~A" #<CL+SSL::SSL-ERROR-INITIALIZE {D43AE31}>) Locals: HUNCHENTOOT::ARGS = (#<CL+SSL::SSL-ERROR-INITIALIZE {D43AE31}>) HUNCHENTOOT::FMT = "Error while processing connection: ~A" HUNCHENTOOT::LOG-LEVEL = :ERROR 1: ((LAMBDA (COND)) #<CL+SSL::SSL-ERROR-INITIALIZE {D43AE31}>) 2: ((LAMBDA (COND)) #<CL+SSL::SSL-ERROR-INITIALIZE {D43AE31}>) 3: (SIGNAL #<CL+SSL::SSL-ERROR-INITIALIZE {D43AE31}>) 4: (ERROR CL+SSL::SSL-ERROR-INITIALIZE) 5: (CL+SSL:MAKE-SSL-SERVER-STREAM #<unavailable lambda list>) 6: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {D03E4B1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 7 {CCFAA79}>) 7: ((LAMBDA NIL)) 8: ("foreign function: call_into_lisp") 9: ("foreign function: funcall0") 10: ("foreign function: new_thread_trampoline") 11: ("foreign function: #xB7FB8604") I have apache listening on port 443 and using mod_lisp to talk to a Hunchentoot server on port 4433. The relevant vhosts setup in apache is: <VirtualHost *:443> ServerName makewavs.com ServerAlias makewavs.com *.makewavs.com ServerAdmin webmaster(a)makewavs.com DocumentRoot "/domains/makewavs.com/htdocs" CustomLog /domains/makewavs.com/logs/ssl_access_log combined ErrorLog /domains/makewavs.com/logs/ssl_error_log LogLevel debug <IfDefine SSL> SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /domains/makewavs.com/htdocs/CA/ca-cert.pem SSLCertificateKeyFile /domains/makewavs.com/htdocs/CA/private/ca-key.pem <Directory "/domains/makewavs.com/htdocs"> Options Indexes FollowSymLinks Order allow,deny Allow from all </Directory> <FilesMatch "\.(gif|jpe?g|png|wav|mp3|ogg)$"> Options Indexes FollowSymLinks Order allow,deny Allow from all </FilesMatch> <LocationMatch ^/$> LispServer 127.0.0.1 4433 "makewavs-ssl" SetHandler lisp-handler SSLOptions +StdEnvVars </LocationMatch> <LocationMatch ^/.+\.htm.*> LispServer 127.0.0.1 4433 "makewavs-ssl" SetHandler lisp-handler SSLOptions +StdEnvVars </LocationMatch> </IfDefine> </VirtualHost> The log ends up saying: [Thu Dec 28 12:33:31 2006] [info] Initial (No.1) HTTPS request received for child 65 (server makewavs.com:443) [Thu Dec 28 12:34:31 2006] [error] (70007)The timeout specified has expired: error reading from Lisp I'm running apache-2.0.58-r2, hunchentoot-0.4.12/, SBCL 1.0 on a gentoo system, and I've read through the last 3 months of the devel-list without seeing anything relevant. Any help would be appreciated. Regards, --Jeff

2 4

Re: [hunchentoot-devel] How to distinguish between two servers running same dispatch functions
by Edi Weitz 27 Dec '06

27 Dec '06

[Please use the mailing list.] On Tue, 26 Dec 2006 08:58:28 -0800, Jeffrey Cunningham <jeffrey(a)cunningham.net> wrote: > I must be missing something. From the handler, isn't one server > object indistinguishable from another? Huh? If you call START-SERVER, a SERVER object is returned, and you should better keep it anyway as you'll need it for STOP-SERVER. You can use EQ to compare this object with the contents of *SERVER*, can't you? > It can't access, say, the SERVER-PORT to tell which server has > called it. http://weitz.de/hunchentoot/#server-local-port http://weitz.de/hunchentoot/#server-address

2 1

[hunchentoot-devel] hunchentoot file upload performance
by Mac Chan 27 Dec '06

27 Dec '06

Hi all, I've been using tbnl behind mod_lisp2 for quite a while. After Edi merged tbnl with hunchentoot I wanted to get rid of apache and run hunchentoot in standalone mode for easier deployment (not to mention the coolness factor of running everything in lisp). However, I've found that the file upload performance of hunchentoot is 4-10 times slower than tbnl (standalone or behind mod_lisp). I tested this by uploading a 30mb file in the test upload page. I'm guessing that Chunga might be the reason, since this is the only new component introduced. [ Chunga is currently not optimized towards performance - it is rather intended to be easy to use and (if possible) to behave correctly.] On a side note, while the file is being uploaded the cpu will go up to 90-100% (This happens to both tbnl and hunchentoot). This is not the case when I upload the same file to a php script w/ apache. Again, my guess is that rfc2388 repeatedly call read-char instead of grabbing a buffer with read-sequence and decode it as a chunk. These two issues make migrating to hunchentoot particular painful because if one of the users uploads a huge file the whole site will become very unresponsive (in tbnl the cpu spike goes away a lot faster, but improving the i/o routine is still a big win). I don't want to blindly guess, but I don't know how to use lispworks' profiler to profile a multi-threaded server app. The lispworks profiler requires you to run (profile <forms>) and it will return the profiling data after running the <form>. Is there a way to profile hunchentoot without writing individual test case that simulates uploading a 30 mb file? What about people using sbcl? How do you go about profiling apps like hunchentoot? Thanks.

2 5

[hunchentoot-devel] logo
by Jeffrey Cunningham 27 Dec '06

27 Dec '06

Does anyone know an artist who can come up with a small Hunchentoot logo we can put on the bottom of websites? I tried to come up with one, but it was embarrasing (I'm no artist). It would be cool. I'm just using the lisp lizard for now linked back to Edi's site. --Jeff

5 6

[hunchentoot-devel] How to distinguish between two servers running same dispatch functions
by Jeffrey Cunningham 26 Dec '06

26 Dec '06

If I'm running two servers, each on a different port, but each running the same handler code, is there a way for a handler to tell which server has called it? --Jeff

2 1

Re: [hunchentoot-devel] Problems with create-folder-dispatcher-and-handler
by Edi Weitz 24 Dec '06

24 Dec '06

[Please use the mailing list if you're interested in timely replies.] On Thu, 7 Dec 2006 19:02:55 +0100, "Rafał Strzaliński" <nablaone(a)gmail.com> wrote: > (defun cfdah-dont-work () > (setf *dispatch-table* > (list > (x-create-folder-dispatcher-and-handler > "/" > #p"/" "text/plain")))) > > (defun cfdah-ok () > (setf *dispatch-table* > (list > (x-create-folder-dispatcher-and-handler > "/etc/" > #p"/etc/" "text/plain")))) I /think/ this is a bug in SBCL. I'll send a bug report to them. Cheers, Edi.

1 1

[hunchentoot-devel] Odd messages, then hang
by Jonathon McKitrick 23 Dec '06

23 Dec '06

I'm seeing these odd messages after merging some code that calls a lot of XMLHttpRequest. That shouldn't matter, but it seems to have appeared suddenly since then. After the message, the server becomes unresponsive. message type 0x54 arrived from server while idle message type 0x44 arrived from server while idle message type 0x43 arrived from server while idle message type 0x5a arrived from server while idle I can't find this in the hunchentoot source, so I'm not sure where to look now. I'm running SBCL 1.0 on Linux. Jonathon McKitrick -- My other computer is your Windows box.

2 2

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

22 Dec '06

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

1 0

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

22 Dec '06

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

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel December 2006