We are using it, working stable, no crashes
Zoran Vasiljevic wrote:
Vlad,
You have added spooling large uploads into temp file and
said you will be using it on some of your servers.
What are your experiences with that?
I'm asking this because we will have to switch to the newest
NS code in abou
Vlad,
You have added spooling large uploads into temp file and
said you will be using it on some of your servers.
What are your experiences with that?
I'm asking this because we will have to switch to the newest
NS code in about 2 months
Cheers
Zoran
Am 17.06.2005 um 22:26 schrieb Stephen Deasey:
We just need to build up the test library one test at a time.
OK. I'm going to expand this when I come to rewriting this
upload file stuff. But one thing at a time. Currently I'm
rewriting Tcl VFS related stuff and this will take me
(given the l
On 6/17/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 17.06.2005 um 21:23 schrieb Stephen Deasey:
>
> >
> > Sounds like a plan for stage 1.
> >
>
> Let me then try this one and see how far I'll come :-)
>
> >
>
> > If there's any part of the code base we should be testing, it's this.
Am 17.06.2005 um 21:23 schrieb Stephen Deasey:
Sounds like a plan for stage 1.
Let me then try this one and see how far I'll come :-)
If there's any part of the code base we should be testing, it's this.
Yes. But this is also the most complex one...
Cheers
Zoran
On 6/17/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 17.06.2005 um 12:30 schrieb Zoran Vasiljevic:
>
> >>
> >> I see that quite a lot of plumbing must be done
> >> to get this working. We must keep the Sock for
> >
>
> Wrong. Not very many plumbings, as we have almost
> all in place.
>
Am 17.06.2005 um 12:30 schrieb Zoran Vasiljevic:
I see that quite a lot of plumbing must be done
to get this working. We must keep the Sock for
Wrong. Not very many plumbings, as we have almost
all in place.
The chages would be mainly in the driver.c SockRead()
to declare SOCK_READY at the
Am 17.06.2005 um 11:45 schrieb Zoran Vasiljevic:
Am 17.06.2005 um 10:07 schrieb Stephen Deasey:
Yeah, looks like a mult-stage project.
I see that quite a lot of plumbing must be done
to get this working. We must keep the Sock for
the request in the Request structure for later
use by the
Am 17.06.2005 um 11:08 schrieb Stephen Deasey:
File a bug report with Mozilla, Safari, Opera etc. "No visible
progress for large file uploads"... :-)
Actually, they're all pretty responsive these days, and when one of
them gets a good idea, the others are often quick to copy. The
undying gra
Am 17.06.2005 um 10:07 schrieb Stephen Deasey:
Yeah, looks like a mult-stage project.
I see that quite a lot of plumbing must be done
to get this working. We must keep the Sock for
the request in the Request structure for later
use by the Ns_ConnContent. Also, the Conn
structure must be expa
On 6/17/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 17.06.2005 um 10:07 schrieb Stephen Deasey:
>
> > You can of course fake it: as soon as the connection which accepts
> > the large file runs it begins a server push, the first page of which
> > contains an animated gif 'uploading...'
Am 17.06.2005 um 10:07 schrieb Stephen Deasey:
You can of course fake it: as soon as the connection which accepts
the large file runs it begins a server push, the first page of which
contains an animated gif 'uploading...'. Once the upload completes
the server pushes a new page which confirms
On 6/17/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 17.06.2005 um 09:24 schrieb Stephen Deasey:
>
> >
> > I believe this is pretty common, but I'm not sure if this is what you
> > want. An anonymous mapping is still going to account against the
> > processes memory budget, and I don't
On 6/17/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 17.06.2005 um 09:06 schrieb Stephen Deasey:
> >
> > However... Vlad's question about ns_getform has me wondering about
> > the common case of HTTP file upload. Consider a 10MB file upload --
> > just before the form parsing code does
Am 17.06.2005 um 09:24 schrieb Stephen Deasey:
I believe this is pretty common, but I'm not sure if this is what you
want. An anonymous mapping is still going to account against the
processes memory budget, and I don't think it's going to be any more
likely to be swapped out than malloc'ed mem
Am 17.06.2005 um 09:06 schrieb Stephen Deasey:
However... Vlad's question about ns_getform has me wondering about
the common case of HTTP file upload. Consider a 10MB file upload --
just before the form parsing code does it's thing, the situation is
that there is a file on disk containing the
On 6/16/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 16.06.2005 um 18:18 schrieb Zoran Vasiljevic:
>
> >
> > One can even explore the memmap machinery and see if we can
> > entirely drop the temp-file and use the system paging for that:
> > so if the input exceeds the maxinput, we just
On 6/16/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 16.06.2005 um 22:13 schrieb Stephen Deasey:
>
> >
> > It was at one point implemented with mmap:
> >
> > http://cvs.sourceforge.net/viewcvs.py/aolserver/aolserver/nsd/
> > driver.c?rev=1.34&view=markup
> >
>
> Aha! But it was taken o
Am 17.06.2005 um 07:29 schrieb Stephen Deasey:
Hope I didn't confuse the issue here, but Vlad seemed worried about
having connection threads tied up handling blocking IO. We have some
good options: adjust the readahead buffer, upto maxinput if needed,
and use connection thread pools to partiti
On 6/16/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 16.06.2005 um 22:13 schrieb Stephen Deasey:
>
> >
> > At any time before the registered proc asks for the content it can
> > check the content length header and decide whether it is too large to
> > accept. You could imagine setting
On 6/16/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 16.06.2005 um 23:35 schrieb Vlad Seryakov:
>
> > I understand that but my question is:
> > How and when all content will be downloaded?
> > By the driver? By the conn thread on first call?
> >
>
> The driver will load up to maxreadah
Am 16.06.2005 um 23:35 schrieb Vlad Seryakov:
I understand that but my question is:
How and when all content will be downloaded?
By the driver? By the conn thread on first call?
The driver will load up to maxreadahead.
At the first call to Ns_ConnContent, the rest
will be sinked from the soc
There's a maxreadahead parameter which is <= maxinput. When a request
arrives with Content-Length > 0 && < maxinput, maxreadahead bytes are
read into a buffer by the driver thread before the conn is passed to a
conn thread.
Actually, there is already (kind of) maxreadahead param: bufsize.
It i
You can check ns_conn contentlength in advance and
decide to get all the content or to discard it (because too large).
You can use ns_conn setmaxinput to some large(r) value and then
call ns_queryget.
The ns_queryget will call Ns_ConnContent and this is now clever
to either return the content fro
Am 16.06.2005 um 22:52 schrieb Vlad Seryakov:
When you call ns_queryget/ns_getform, NS parses the input and split
content into temporaty file in case of attachements. When sending
multipart/data content and i called ns_queryget at the beginning of my
connection script, parser needs all the
Am 16.06.2005 um 22:13 schrieb Stephen Deasey:
At any time before the registered proc asks for the content it can
check the content length header and decide whether it is too large to
accept. You could imagine setting a low global maxinput, and a call
such as Ns_ConnSetMaxInput() which a regis
When you call ns_queryget/ns_getform, NS parses the input and split
content into temporaty file in case of attachements. When sending
multipart/data content and i called ns_queryget at the beginning of my
connection script, parser needs all the data available, big attachments
can be the first on
Am 16.06.2005 um 22:13 schrieb Stephen Deasey:
It was at one point implemented with mmap:
http://cvs.sourceforge.net/viewcvs.py/aolserver/aolserver/nsd/
driver.c?rev=1.34&view=markup
Aha! But it was taken out for some reason...
It would be good to know why?
Spooling large requests to d
On 6/16/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I ran into several problems while debuggging a problem at the
> customer site related to uploading files and size of those files.
>
> As it looks like, the NS/AS spools all the incoming content into
> the memory (urks!). Depending
Am 16.06.2005 um 18:18 schrieb Zoran Vasiljevic:
One can even explore the memmap machinery and see if we can
entirely drop the temp-file and use the system paging for that:
so if the input exceeds the maxinput, we just mmap /dev/zero file
I believe something like that should be possible but wil
Hi!
I ran into several problems while debuggging a problem at the
customer site related to uploading files and size of those files.
As it looks like, the NS/AS spools all the incoming content into
the memory (urks!). Depending on the content-type, the content
may be parsed, as in case of multipa
31 matches
Mail list logo
