John, I'm just going to venture a guess. I hope that Jim D. or someone else more familiar with the internals will set me straight.
The problem with upload progress monitoring is that uploads are finished before a conn thread is allocated. Uploads are done in the driver thread, or a worker thread before the conn thread is given control. One thing which could help is if AOLserver introduced chunked transfer encoding for uploads. But to report progress back to the user would require a different setup. You would need to monitor the progress of some other process/thread. AOLserver has chosen to stratify io. By stratify I mean the io handling is moved through a pipeline. The pipeline may transfer handling between threads but also enforces the direction of communication. There is no asynchronous io, each step in the pipeline is focused on one-way communication. For instance, the driver thread only reads, the conn threads only write. There is a kind of fiction that conn threads do any reading from the client. These threads only read from buffers or disk. The reason should be obvious: dos attacks. The driver thread is highly tuned to protect the expensive conn threads. In addition to that issue, the connio uses scatter/gather io, so the application gets a very imperfect view of the actual progress. Of course the io is much more efficient and progress reporting would require an independent observation and messaging system. A first step would be the ability to log upload progress to error.log. If you can't do that, reporting back to the client will be impossible (unless you think the logging system should operate with less available information than individual conn threads). 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. tom jackson On Tue, Nov 24, 2009 at 2:13 PM, John Buckman <[email protected]> wrote: > Naviserver has a very nice feature that allows (via javascript) to show a > user the percent upload progress of a file. I tried porting their progress.c > file to aolserver, but it's a significant effort, as it depends on other > changes naviserver has implemented to the aolserver code. > > However, I was wondering if there wasn't a fairly simple way to implement > something similar on aolserver. > > What I'd need is a way to know how much data has been uploaded. > > The way naviserver does it, is by asking you to POST your upload to a unique > URL, and then they provide a tcl command that returns how many bytes have > been uploaded to that unique URL. A javascript regularly polls an ADP page > that uses the tcl progress command to tell you the number of bytes uploaded. > > Is there any access (in C or Tcl) to an upload-in-progress in aolserver? > > -john > > > -- > 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.
