Re: [naviserver-devel] Upload Progress

[Stephen D. <sd...@gm...>]

On 12/31/05, Gustaf Neumann <ne...@wu...> wrote:
> Zoran Vasiljevic wrote:
> >
> > But that would occupy the conn thread for ages, right?
> > I can imagine several slow-line large-file uploads could
> > consume many of those. Wasn't that the reason everything
> > was moved in the driver thread for the 4.0 ?
> >
> > What I have/had in mind is aync writes from the driver thread.
> > Most of the OS'es have this feature (kaio) so we can employ it.
> > The question of locking, however still remains in such case.
> > So the decision has to be made on: what is cheaper? Locking
> > or spooling to disk out of the conn thread? I have no real-life
> > experience but I'm inclined to believe that spooling out of the
> > conn thread would be more costly.
> >
> > What do you think?
> i have not much looked into the c-code, so please forgive, if my
> mail here is obviously wrong or naive.
>
> One thing, which i dislike about the aolserver for file uploads is that
> there is no hook for early permission or quota checking; one has to
> upload the whole file before aolserver is able to give some feedback.
> i see this even more important than the progress bar.


I agree. This is important.


> What about the following model:
>
> A) HTTP header (up to empty line) -> driver thread
>
> B) Then passing control+socket to a separate receiving thread that
>   1) issues a callback at the start (e.g. for permission checking)
>   2) does async i/o to receive the message body (e.g. PUT, POST request)
>     here, one can issue as well callbacks per async block, and decide
>     fom tcl, whether one would like to spool to memory or disc.
>
> C) When end of message received, pass control to connection thread as usu=
al.
>
> The receiving thread is like a connection thread with tcl stuff; when the
> receiving thread is implemented via libthtread, there won't be probably
> much locking. Only one receiving thread will be necessary.
> The overall model could be quite compatible with the aolserver, since the
> connection tread is invoked when all data is received. It would be necess=
ary
> to pass context information from the receiving thread to the connection
> thread
> to avoid double permission checking.
>
> It could as well make sense, to pass control to the receiving thread only
> for chunked content. Maybe, the receiving thread is not needed at all,
> since the driver thread could handle everything as well.


This is similar to the way the old Flash web server worked.  It had a
pool of IO threads which would make sure data on disk was in memory,
possibly blocking, before the main thread would try to write it out to
the client.  Multiple threads are used to get more throughput out of
the disk.  As one thread blocks, another can submit a request.

Your single thread helper mechanism above may not work the disk as
hard as multiple threads, but it does mean that the driver thread
doesn't have to block waiting for disk.

You've also moved quota checking etc. into the helper thread.  This
doesn't so much matter if there's just one, but with more than one you
have to remember that a Tcl interp will be allocated for each, and
they'll be just as heavyweight as normal conn threads.

We have a similarly problem with normal downloads, i.e. writing data
to the client, an mp3 file for example, ties up a heavyweight conn
thread.  A generic pool of IO threads might be useful in a number of
places.  Of course, this is just a simulation of AIO to disk, but see
my other email for why AIO is not so easy.


AOLserver HEAD has a new filter type, NS_FILTER_PREQUEUE, which gets
called just before the connection is queued for processing by a conn
thread.  The unique thing about this filter type is that the
registered code runs in the context of the driver thread.=20
Unfortunately that's after all the data has been read and spooled, but
we could implement it such that they ran just after all headers have
been received.

If you want to check quotas by querying a database then then this
doesn't help -- your db query will block the driver thread.  These
filters will have to be coded carefully.  We could also implement
non-blocking db calls, and that's certainly something I'm interested
in, but it doesn't help right now.

However, if the code you want to run is short and non blocking,
prequeue filters we be a good way to run quota checks and such without
having to involve a conn thread at all.


Prequeue filters don't help with upload tracking, nor with actually
spooling large uploads to disk.