When I tested using the prequeue filter, it didn't crash the server. The server just ran out of physical memory, which might be even worse. But it just happened because I was doing load testing. I wanted to try logging incoming connections before they got dumped to conn threads. It worked, for a while.
Anyway, the prequeue filter must use a separate interp, since it is in a different thread and conn threads are expensive. I was thinking the prequeue filter was more likely to work with a filter written in C, so I lost interest in it. One possibly easy modification may entail a slightly modified ns_sock module. All reading/writing goes through that point, and you could fairly easily copy and modify the current module. How to connect it to a monitoring page: Before the content is read, all headers have been processed, so you could use a cookie, probably necessary for sites which allow POSTed data. Assuming the cookie is opaque and not easily guessed unless you have access to the packets, you could generate a monitor page using an nsv_array/arrays. Each connection also gets a new connid, so you can tie together connid and cookie. One problem is if the upload is ever "upgraded" to HTTP/1.1, which allows chunked transfer (why?). You could still track a total, but you have no idea the expected size. The other problem is that each query requires a connection thread to process. Why not just create a client side agent which can count output bytes? tom jackson On Wed, Nov 25, 2009 at 2:46 PM, Jeff Rogers <[email protected]> wrote: > It looks like the pre-queue filters are run after the message body has been > read, but before it is passed off to the Conn thread, so no help there. > However it looks like it would not be hard to add in a new callback to the > middle of the read loop, tho it's debatable if that's a good idea or not > (for one, it would get called a *lot*). > > Curious about that tcl prequeue leak. I guess no one uses or cares about > it, since the symptom is serious (more than just a really big memory leak, > it crashes the server too), the cause is pretty obvious and the fix appears > on the surface to be pretty obvious, although it does result in prequeue > filters working differently from all the others, in particular that it would > use a different interp from the rest of the request. > > -J > > Tom Jackson wrote: > >> There is one possibility. There is a pre-queue filter in AOLserver >> (run inside the driver thread). It works from the Tcl level, but >> creates a memory leak equal to the size of an interp, in other words a >> huge memory leak. However, maybe at the C level, you could create a >> handler which would do something interesting before returning control >> back to the driver thread and ultimately the conn thread. I'm not sure >> exactly when the pre-queue filters are activated, but if it is before >> reading the message body, it might be useful. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[email protected]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: > field of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[email protected]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
