tbnl-devel July 2004

tbnl-devel@common-lisp.net

4 participants
24 discussions

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

17 Jul '04

[Looks like it didn't work the first time with common-lisp.net - maybe due to my misconfiguration of SquirrelMail. I'll try it again. Note that Peter has already pointed out my mistaken assumption.] I'm sitting in a train and trying to send this via my cell phone. Let's see if it works... :) I've looked at the source code of mod_lisp.c (version 2.33) and Apache (1.3.29) and I'm beginning to ask myself whether the "Keep-Socket" option makes any sense at all. What I see with my limited knowledge of Apache is the following: 1. The actual content handler in mod_lisp.c which is called each time a new request comes in (from the client) is the function lisp_handler. 2. To get a socket, lisp-handler calls OpenLispSocket. 3. OpenLispSocket uses ap_psocket (using the global variable SocketPool) to get a socket from Apache. 4. ap_psocket is defined in Apache's src/main/alloc.c and basically just calls ap_psocket_ex. 5. ap_socket_ex always unconditionally acquires a new socket via socket(7). The pool which is its first argument (and which is SocketPool from above) is only used for cleanup purposes. So, as a consequence, I cannot understand if and how the socket used by lisp_handler is ever going to be re-used. I'm sending a copy of this email to mod-lisp-devel because Marc is the authoritative source for this kind of questions... :) Cheers, Edi.

1 0

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

16 Jul '04

On Fri, Jul 16, 2004 at 12:37:49PM +0200, edi@miles wrote: > I'm sitting in a train and trying to send this via my cell > phone. Let's see if it works... :) Nice :-) > I've looked at the source code of mod_lisp.c (version 2.33) and Apache > (1.3.29) and I'm beginning to ask myself whether the "Keep-Socket" > option makes any sense at all. What I see with my limited knowledge of > Apache is the following: You missed one key part of the process. > 2. To get a socket, lisp-handler calls OpenLispSocket. > > 3. OpenLispSocket uses ap_psocket (using the global variable > SocketPool) to get a socket from Apache. OpenLispSocket only fetches a new socket if and only if one has not already established and is safe to use (see here): if (cfg->LispSocket) if (cfg->UnsafeLispSocket) { ap_pclosesocket(SocketPool, cfg->LispSocket); cfg->LispSocket = 0; cfg->UnsafeLispSocket = 0; } else { return cfg->LispSocket; } This is the step that bypasses the creation of a new socket. Thus, Keep-Socket does make sense. I'll continue looking at the TBNL and mod_Lisp interaction to see if I can find anything else. Thanks, Pete

1 0

Re: [tbnl-devel] Last-Modified / If-Modified-Since Headers
by Edi Weitz 14 Jul '04

14 Jul '04

On Wed, 14 Jul 2004 01:14:35 -0400, pete-tbnl-dev(a)kazmier.com wrote: > Just to make sure I understand what you are saying: > > - If the user does not assign a handler to the special variable, > then TBNL should not make any assumptions on the intention of the > coder and thus not send any Last-Modified header and never send a > 304 reply in response to a client's If-Modified-Since header. Yes. The default value should be a function which always returns NIL. > - If the user does assign a handler and it returns a non-nil value, > then TBNL should use this universal-time as the value of the > Last-Modified header or the value to compare to a client's > If-Modified-Since header. > > - If the user does assign a handler and it returns a nil value, then > TBNL should not send any Last-Modified header and never send a 304 > reply in response to a client's If-Modified-Since header because the > coder has indicated that the last modified time is not known for > this request. Yes and yes. > I'd be happy to send a patch. I probably won't get to this right > away as I'm busy trying to get other parts of my new site working > and just trying to learn lisp in general. However, at some point > I'll probably need the functionality at which point I'll submit a > patch. That's fine. No need to hurry. > I've built sites that use template engines that are backed by a > "data miner" that refreshes the context used to fill templates on a > periodic basis. Web-based reporting interfaces can take advantage > of this scenario. But why then don't you serve these pages statically directly from Apache? Cheers, Edi.

2 1

[tbnl-devel] Last-Modified / If-Modified-Since Headers
by pete-tbnl-dev＠kazmier.com 13 Jul '04

13 Jul '04

Is there any interest in adding functionality that enables TBNL to automatically send a "304 Not Modified" in response to content that has not changed? For example, in the Java Servlet world, a servlet author can define getLastModified(). What does this buy the servlet author? Automatic client-side caching. For those not familiar with the "Last-Modified/If-Modified-Since" headers, here's a brief overview. The first time client A visits our servlet page, our servlet is called to generate some HTML output. If a servlet author has implemented getLastModified(), the servlet container invokes this method and inserts a "Last-Modified" header in the response to the client. The value of this header is a date specifying when the page was last modified. This value is cached in the client's browser. The next time client A visits our servlet page, in the HTTP request, the client's browser includes a "If-Modified-Since" header with the value that our servlet had previously sent. When our servlet receives the request, it notices the "If-Modified-Since" header, and thus invokes our servlet's getLastModified() method (if defined). When the time returned by this method is newer than the time the client sent, the servlet container proceeds to dispatch the request to our servlet for processing and generation of output. Things are more interesting when the value returned from getLastModified() is the not newer than the value of the "If-Modified-Since" header. In this case, the servlet container bypasses our servlet and simply sends a "304 Not Modified" back to the client which instructs the browser to display the cached content. It is important to note that this servlet container did not dispatch to our code to generate HTML output, it is completely bypassed and all handled by the container. This is the functionality that I would like to add to TBNL. I'm going to do it for myself even if its not part of the core; however, I thought it would be useful for others as well, and thus this post. How would one implement this within TBNL? Would the same approach the Java folks used suffice? Provide a special variable, *last-modified-handler*, that users can set to return a timestamp? From within that method, users would have access to *request* so they could return specific times for various URIs. This is what I need it for, my entire site will be served by HTML-TEMPLATEs and I'll use the last time the template file was modified as my timestamp. Thoughts? Thanks, Pete

2 1

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