[tbnl-devel] 1) Aborted connections 2) create-static-file-dispatcher-and-handler

Jeff Caldwell jdcal at yahoo.com
Fri Jul 23 22:22:54 UTC 2004


Hi guys,

Edi, I responded to your email last week but, by
accident, didn't cc you. I told Pete I had just
started my first Debian stable -> unstable upgrade and
that my world was torn apart. The upgrade was a bear
for me but I finally have the pieces glued back in
place, at least enough to do rough work. I now know
more than I did about X, BlackBox, KDE, apt-get,
dselect, and all that jazz.

A couple of things.

Edi, your aborted connection patch is a good thing. I
don't remember if you noted that the aborted
connections never happen until after ab completes its
run. It seems to me that the there is one additional
request sent to mod_lisp as each httpd process
terminates. I used the Apache logging feature and did
'tail -f error_log' to watch what happens as ab runs.
Everything was fine until after ab completed. Then and
only then did the aborted connection logs start
appearing. I didn't measure it exactly but it seemed
the messages dribbled along as httpd's terminated
after reaching their approx. 150 peak.

I put in enough log messages to verify that with ab -n
2000 -c 200, I got about 2199 total messages, of which
199 ended with aborts. With ab -n 2000 -c 1, there
were no aborts. With ab -n 2000 -c 2, there was 1
abort. I was unable to find any fields in the
request_rec that indicated that the request was a
"duplicate". I set flags in the .. from memory, what
are the functions, lib_child_init and lib_child_exit?
.. but the "extra" call comes before any call to
lib_child_exit. 

The requests are all full ones, and TBNL gets the full
request and generates a full response, even through
more requests are made than are asked for with ab's -n
parameter.

I'll do more research, for example looking at other
Apache module's source code, and google searches, or
writing a custom ab, when I get a chance. Tonight I'm
leaving for vacation. I'm taking my laptop but my time
and access will be occasional only. I'll be back the
second Tuesday after today.

In create-static-file-dispatcher-and-handler, I'm
pretty sure the make-array is thread unsafe where it
sits. Aren't only special variables thread safe? The
code as is establishes the closure at best when the
dispatch table is constructed. With multiple threads,
they each are sharing buf, which isn't good for
several reasons. In CMUCL, I got lots of "bad address"
errors in  a function underneath read-sequence on the
stream reading fz.jpg. The errors seemed to go away
when I moved the let/make-array inside the handler.

Sorry I don't have time for a real test or real
patches but I hope to be on the road in an hour. It's
great to see an active tbnl-devel.

Jeff



--- Stefan Scholl <stesch at no-spoon.de> wrote:
...
> (defun create-static-file-dispatcher-and-handler
> (uri path content-type)
>   "Creates a dispatch function which will dispatch
> to a handler
> function which emits the file PATH with CONTENT-TYPE
> if the URI
> matches the SCRIPT-NAME of the request."
>   (let ((buf (make-array 8192 :element-type
> #-:tbnl-bivalent-streams 'character
>                          #+:tbnl-bivalent-streams
> '(unsigned-byte 8))))
>     (let ((handler #'(lambda ()
>                        (setf (content-type)
>                              content-type)
>                        (with-output-to-string (str)
>                          (with-open-file (file path
> :direction :input
>                                               
> #+:tbnl-bivalent-streams :element-type
>                                               
> #+:tbnl-bivalent-streams '(unsigned-byte 8))
>                            (do ((pos (read-sequence
> buf file) (read-sequence buf file)))
>                                ((zerop pos))
>                              (write-sequence buf str
> :end pos)))))))
>       #'(lambda (request)
>           (when (equal (script-name request) uri)
>             handler)))))
...


	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/




More information about the Tbnl-devel mailing list