tbnl-devel July 2004

tbnl-devel@common-lisp.net

4 participants
24 discussions

[tbnl-devel] New version 0.2.5
by Edi Weitz 20 Jul '04

20 Jul '04

Hi! A new release is available from <http://weitz.de/files/tbnl.tgz>. Here's the relevant part from the changelog: Version 0.2.5 2004-07-21 Added CREATE-STATIC-FILE-DISPATCHER-AND-HANDLER (provided by Stefan Scholl) Improved test suite Enjoy, Edi

1 0

[tbnl-devel] Tip: Don't forget to close your ports!
by Stefan Scholl 20 Jul '04

20 Jul '04

Hi! It's hardcoded into KMRCL to listen on 0.0.0.0. ==> It's possible to reach your lisp server directly from outside your server. Don't forget to close your ports! If you're using Linux, outside interface is eth0 and *apache-port* is 3000 (default), then use the following line: iptables -A INPUT -i eth0 -p tcp --dport 3000 -j REJECT Regards, Stefan

2 1

[tbnl-devel] Odd behavior (socket leak)
by pete-tbnl-dev＠kazmier.com 20 Jul '04

20 Jul '04

I could use a sanity check. I've been trying to track down a problem with either mod_lisp (for apache 2.0) or TBNL. Since I was not able to isolate my problem, I decided to revert back to Apache 1.3 and mod_lisp 2.33 (for Apache 1.x). The problem is that I think I'm seeing some odd behavior and was hoping someone else could confirm. In a nutshell, I added a simple print statement to APACHE-LISTEN in TBNL's modlisp.lisp file so I would know when this function was being invoked. I also added print statements before each significant line in that function so I could see what the heck was going on. Here is my version of that function: (defun apache-listen (*apache-stream* command-processor &rest args) "Listens on *APACHE-STREAM* for commands from mod_lisp. Packages the command using GET-APACHE-COMMAND and passes it to the COMMAND-PROCESSOR function \(which is PROCESS-APACHE-COMMAND). ARGS are ignored. Designed to be called by a KMRCL:LISTENER object." (declare (ignore args)) (format t ">>>>>>> Opening stream~%") (force-output) (let ((*close-apache-stream* t)) (unwind-protect (loop for *apache-socket-usage-counter* from 0 for command = (debug-value *command* (get-apache-command)) while command do (cond ((ignore-errors (format t ">>>>>>> Processing command ~A~%" (subseq command 0 3)) (force-output) (funcall command-processor command)) (ignore-errors (format t ">>>>>>> Flushing stream cuz no errors occurred for ~A~%" (subseq command 0 3)) (force-output) (force-output *apache-stream*))) (t ;; if an error occured during processing of ;; COMMAND we close this particular connection ;; to Apache (ignore-errors (format t ">>>>>>> Closing stream cuz error occurred for ~A~%" (subseq command 0 3)) (force-output) (setq *close-apache-stream* t)))) until *close-apache-stream*) (ignore-errors (format t ">>>>>>> Closing stream - no more commands~%") (force-output) (kmrcl:close-active-socket *apache-stream*))))) Now, back in Apache 1.3 world, I hit a webpage that invokes the mod_lisp handler and thus TBNL. I see the opening, processing, and flushing messages. The next time I hit the page (30 seconds later), I see the same thing again. I never see a closing message, and a look at 'netstat -an | grep 3000' indicates that another socket has been allocated and is in a connected state. I repeated this process for a few minutes and got up to 6 connected sockets without ever seeing a closing message. If a subsequent hit comes close enough, then it will reuse the socket and I'll only see a processing and flusing message (no opening message). I'm using SBCL (with multithreaded support). I'll continue debugging in the meantime and I'm going to start with fresh copies of everything to make sure I have not inadvertently affected things while debugging my original problems with Apache 2.x (which still appear when I use Apache 1.x). I'll summarize those problems as well (as I think they may be related), essentially, I have a web page that has three stylesheets included in it (and are processed by TBNL as well), so basically, TBNL receives 4 requests in a fairly short amount of time. After adding debugging code to the mod-lisp.c Apache module, I've confirmed that mod-lisp sends the 4 requests to TBNL. Unfortunately, mod-lisp never receives any headers from TBNL for the last request although I've seen TBNL send them (I just didn't realize until now that they were probably going over different sockets). In any case, I've been banging my head all day, I need a break, but it would be appreciated if someone could either confirm or deny the opening of multiple sockets while never closing any of the old ones. Its easy to see via a 'netstat -an | grep 3000' (or whatever port you run it on). Thanks, Pete

2 5

[tbnl-devel] "Leaked children"
by Edi Weitz 20 Jul '04

20 Jul '04

Hi! Again, a little patch. This time it's not about leaked sockets but rather about "leaked children," so to say. It was Stefan Scholl who actually prompted me to investigate this further and here's what I found out: This piece of code if (ReadLength < ContentLength || r->connection->aborted) { char buffer[HUGE_STRING_LEN]; ContentLength -= ReadLength; do { ReadLength = ForceGets(buffer, (BUFF *) BuffSocket, HUGE_STRING_LEN > ContentLength ? ContentLength : HUGE_STRING_LEN); ContentLength -= ReadLength; } while (ReadLength > 0 && ContentLength > 0); } doesn't work if ContentLength is large enough. What's happening is that the process of emptying BuffSocket (the loop above) always hangs when exactly the last 8192 (HUGE_STRING_LEN) bytes are waiting to be removed. I tried with ap_bread instead of ForceGets but got the same result. (Note that ap_bgets which is used by ForceGets does CR/LF handling which is not needed here.) The result is that this child becomes unusable but is still there, it is never killed by the Apache root process. An easy way to reproduce this (with TBNL) is to do (asdf:oos 'asdf:load-op :tbnl-test) (tbnl:start-test) with a proper Apache configuration (see TBNL docs) and then call ApacheBench with large values like so: ab -n 2000 -c 200 http://localhost/tbnl/test/image.jpg (The important point is that image.jpg is big enough - about 20kB in this case.) After doing this you'll see a large number of Apache processes with ps(1) and the same amount of Lisp processes from within your Lisp image. Call ApacheBench often enough (two or three times) and Apache will completely stop to respond because it has reached its 'MaxClient' limit of 150 (unless you've changed it, of course) but none of the 150 clients is usable. This happens because ApacheBench will abort all pending connections as soons as its finished with its tests. The pattern can obviously be used as a DoS attack on mod_lisp. Now, what to do? One option would probably be to set a timeout before emptying the buffer (not tested). But I think the better (and faster) solution is to get rid of the buffer and the socket as well. The next time the client is used we'll have to open up a new socket to Lisp but this won't need 300 seconds (the default Apache value for 'Timeout'). So... if (ReadLength < ContentLength || r->connection->aborted) { ap_log_error("mod_lisp", 0, APLOG_WARNING|APLOG_NOERRNO, r->server, "Could not send complete body to client, closing socket to Lisp"); ap_bclose(BuffSocket); KeepSocket = 0; LispSocket = 0; } The appended patch also adds a couple of braces to appease gcc and it removes some code that is never used at all. Hope that's OK. Cheers, Edi.

1 0

[tbnl-devel] Re: [mod-lisp-devel] Re: Socket leaks, again
by Edi Weitz 19 Jul '04

19 Jul '04

On Mon, 19 Jul 2004 19:11:29 +0200, "Marc Battyani" <marc.battyani(a)fractalconcept.com> wrote: > I'm checking it now and it's ok for me. Do you still have connection > problems ? No, it works now. Thanks, Edi.

1 0

[tbnl-devel] URL rewrite for XHTML content-types, too
by Stefan Scholl 19 Jul '04

19 Jul '04

Hi! The documentation for *rewrite-for-session-urls* says that ""This only happens, though, if the body's content type (see CONTENT-TYPE) starts with "text/html""". XHTML can have other content types, too. See <http://www.w3.org/TR/xhtml-media-types/> OK, application/xml and text/xml are a bad choice, because you can't say if it's really a kind of XHTML or just another XML application. You have to parse the content itself for that. But application/xhtml+xml is OK and recommended. Regards, Stefan

2 2

[tbnl-devel] New version 0.2.4
by Edi Weitz 19 Jul '04

19 Jul '04

Hi! A new release is available from <http://weitz.de/files/tbnl.tgz>. Here's the relevant part from the changelog: Version 0.2.4 2004-07-19 New variable *CONTENT-TYPES-FOR-URL-REWRITE* (suggested by Stefan Scholl) Updated index.html regarding new version of mod_lisp Have fun, Edi

1 0

[tbnl-devel] Re: [mod-lisp-devel] Re: Socket leaks, again
by Edi Weitz 19 Jul '04

19 Jul '04

On Sun, 18 Jul 2004 22:12:39 +0200, "Marc Battyani" <marc.battyani(a)fractalconcept.com> wrote: > Hum, this web site is poorly maintained... :( I change it from time > to time, when I find some time. The trouble is that these days, when > I find some time, I prefer hacking cl-typesetting or something like > that rather than updating the web site... I'll add a link to the SVN repository to the TBNL docs. >> > Please get the latest one (2.35) on the mod_lisp repository: >> > http://www.fractalconcept.com:8000/public/open-source/ >> >> I get no reply when I try to connect... :( > > I restarted Apache2 (used by svn), it's ok for me now. Yep, it worked briefly last night but tomorrow again the connection is refused... :( Cheers, Edi.

1 1

[tbnl-devel] Socket leaks, again
by Edi Weitz 18 Jul '04

18 Jul '04

[Again, I'm in a train and sending via cell phone and GPRS. Let's see if it works better this time. Also, I'm not sure if SquirrelMail will be able to keep indentations.] I'm prepared to make myself a fool in public again. I've debugged the mod_lisp/Apache interaction (by inserting log statements in strategic places) a bit and here's what I found out (Linux x86, mod_lisp 2.33, Apache 1.3.29, CMUCL 18e): 1. Whenever OpenLispSocket is called, cfg->LispSocket is 0. This can be best seen if you start Apache with the -X option so that you only one child process. This would imply that sockets can never be re-used. 2. Another data point (see also Peter's earlier post) is that netstat -an | grep 3000 reports far more established connections than there are Apache child processes. 3. I guess this is due to the fact that the configuration record is reset by Apache on each request. I observe that the comment in Apache's example module (which is also in mod_lisp) says "Note that while the per-directory and per-server configuration records are available to most of the module handlers, they should be treated as READ-ONLY by all except the command and merge handlers. Sometimes handlers are handed a record that applies to the current location by implication or inheritance, and modifying it will change the rules for other locations." This is obviously violated by mod_lisp which modifies the record in the content handler. 4. My naïve attempt to fix this is to make LispSocket and UnsafeLispSocket global variables. A patch which reflects my changes is attached at the bottom. This currently works for me. Debugging shows that sockets are in fact re-used this time. Also, if I benchmark with ApacheBench (2000 request, 200 concurrent, 1300 byte static page, client and server on same machine) then the original mod_lisp code is able to handle roughly 140 requests per seconds while my modified code handles more than 460 requests per seconds. 5. Of course, this patch will only work if the Apache children are separate processes spawned by the server process as with Apache 1.3, i.e. another approach must be taken for the new, alternative Apache 2.0 thread implementations. OK, that's all for now. Let me know what you think. Cheers, Edi. --- /home/edi/downloads/Lisp/mod_lisp-2.33.c 2004-07-16 01:52:23.000000000 +0200 +++ mod_lisp-2.33.c 2004-07-18 16:58:23.000000000 +0200 @@ -189,10 +189,11 @@ char LispServerIP[20]; long LispServerPort; char LispServerId[100]; - long LispSocket; - long UnsafeLispSocket; } excfg; +static long LispSocket = 0; +static long UnsafeLispSocket = 0; + pool *SocketPool = NULL; /* @@ -371,13 +372,6 @@ if (lisp_pool == NULL) { lisp_pool = ap_make_sub_pool(NULL); }; - /* - * Likewise for the table of routine/environment pairs we visit outside of - * request context. - */ - if (static_calls_made == NULL) { - static_calls_made = ap_make_table(lisp_pool, 16); - }; } #endif @@ -421,21 +415,21 @@ int ret; #ifndef WIN32 - if (cfg->LispSocket) - if (cfg->UnsafeLispSocket) + if (LispSocket) + if (UnsafeLispSocket) { - ap_pclosesocket(SocketPool, cfg->LispSocket); - cfg->LispSocket = 0; - cfg->UnsafeLispSocket = 0; + ap_pclosesocket(SocketPool, LispSocket); + LispSocket = 0; + UnsafeLispSocket = 0; } else { - return cfg->LispSocket; + return LispSocket; } #endif - cfg->LispSocket = 0; - cfg->UnsafeLispSocket = 0; + LispSocket = 0; + UnsafeLispSocket = 0; addr.sin_addr.s_addr = inet_addr(cfg->LispServerIP); addr.sin_port = htons((unsigned short) cfg->LispServerPort); addr.sin_family = AF_INET; @@ -459,7 +453,7 @@ if (ret == -1) return -1; - cfg->LispSocket = sock; + LispSocket = sock; return sock; } @@ -498,13 +492,13 @@ if (Socket != -1) ap_pclosesocket(SocketPool, Socket); #else - if (!cfg->LispSocket) + if (!LispSocket) return; - ap_pclosesocket(SocketPool, cfg->LispSocket); + ap_pclosesocket(SocketPool, LispSocket); - cfg->LispSocket = 0; - cfg->UnsafeLispSocket = 0; + LispSocket = 0; + UnsafeLispSocket = 0; #endif } @@ -605,7 +599,7 @@ } ap_reset_timeout(r); - dcfg->UnsafeLispSocket = 1; + UnsafeLispSocket = 1; if (r->subprocess_env) { @@ -860,7 +854,7 @@ ap_bpushfd(BuffSocket, -1, -1); /* unlink buffer to keep socket */ BuffSocket->flags &= ~B_SOCKET; } - dcfg->UnsafeLispSocket = 0; + UnsafeLispSocket = 0; return OK; } @@ -985,7 +979,6 @@ strcpy(cfg->LispServerId, "apache"); cfg->LispServerPort = 3000; cfg->DefaultLispServer = 1; - cfg->LispSocket = 0; cfg->cmode = CONFIG_MODE_DIRECTORY; dname = (dname != NULL) ? dname : ""; @@ -1059,7 +1052,6 @@ merged_config->DefaultLispServer = 1; } - merged_config->LispSocket = 0; return (void *) merged_config; } @@ -1087,7 +1079,6 @@ strcpy(cfg->LispServerIP, "127.0.0.1"); strcpy(cfg->LispServerId, "apache"); cfg->LispServerPort = 3000; - cfg->LispSocket = 0; cfg->DefaultLispServer = 1; sname = (sname != NULL) ? sname : ""; cfg->loc = ap_pstrcat(p, "SVR(", sname, ")", NULL); @@ -1148,7 +1139,6 @@ merged_config->DefaultLispServer = 1; } - merged_config->LispSocket = 0; return (void *) merged_config; } @@ -1309,7 +1299,6 @@ cfg->LispServerId[99] = 0; cfg->LispServerPort = atoi(port); cfg->DefaultLispServer = 0; - cfg->LispSocket = 0; return NULL; }

1 0

Re: [mod-lisp-devel] Re: [tbnl-devel] Odd behavior (socket leak)
by Edi Weitz 17 Jul '04

17 Jul '04

Hi Marc! On Sat, 17 Jul 2004 13:04:06 +0200, "Marc Battyani" <marc.battyani(a)fractalconcept.com> wrote: > in OpenLispSocket: > > If there is a socket in cfg->LispSocket and that socket is not > unsafe (cfg->UnsafeLispSocket) then I return this socket. I don't > create a new one. Re-using the socket is much faster. > > if (cfg->LispSocket) > if (cfg->UnsafeLispSocket) > { > ap_pclosesocket(SocketPool, cfg->LispSocket); > cfg->LispSocket = 0; > cfg->UnsafeLispSocket = 0; > } > else > return cfg->LispSocket; > > Or did I mis-read your question ? No, you didn't, it was just an oversight of mine. Sorry for the noise, Edi.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel July 2004