serving very large files from allegroserve

Testing downloads of large audio recordings from ilc2007, I
find that
the bytes stop flowing after five minutes. Allegroserve
(version
1.2.43 on ACL 8.0) spits out a 500 return code and the
transaction is
over.

I find in AServe doc the following:

    (wserver-response-timeout wserver) - the number of
seconds
    AllegroServe allows for an http request function to be
run and
    finished sending back its response. The initial value
for this
    slot of the wserver object is found in
*http-response-timeout*
    which defaults to 300 seconds. You can alter this
timeout value
    with the :timeout argument to with-http-response or by
specifying
    a :timeout argument to the publish function creating the
entity.

and I'm sure this is exactly what I've hit. 

The thought of just cranking this number up and hoping for
the best
makes me cringe a little. Surely there must be better? Well,
the folks
at Franz obviously thought so too, because a couple of
paragraphs up
they say:

    In Acl 6.1 we added the capability of having each I/O
operation to
    a socket stream time out.  This means that we don't have
to
    predict how long it should take to get a request or send
a
    response.  As long as we're making progress reading or
writing we
    know that the client on the other end of the network
connection is
    alive and well.

Fine words. But totally contradicted by having a
response-timeout slot
in the server.

Does anyone have any experience with getting AServe to
monitor whether
it's "making progress reading" and so knows
"that the client on the
other end of the network connection is alive and
well"?

Thanks,

- nick






_______________________________________________
lispweb mailing list
lispwebred-bean.com
http
://www.red-bean.com/mailman/listinfo/lispweb

>     In Acl 6.1 we added the capability of having each
I/O operation to
>     a socket stream time out.  This means that we don't
have to
>     predict how long it should take to get a request or
send a
>     response.  As long as we're making progress reading
or writing we
>     know that the client on the other end of the
network connection is
>     alive and well.
> 
> Fine words. But totally contradicted by having a
response-timeout slot
> in the server.
> 

I wouldn't call it a contradiction at all.   Suppose you
have some 
people trying to attack your web site by making requests and
very
very slowly reading the response.   If you just let them do
this
then they can tie up a lot of server resources for a long
time.

So allegroserve offers a global timeout for the whole
request
(which defaults to 300 seconds if you're also doing timeout
on each I/O).   If you know you'll be sending things that
could take a long long time then feel free to change
the 300 to a huge value. You're still protected by the
timeout
on I/O which will ensure that some progress gets made ever
N seconds (default 120).

-john foderaro


_______________________________________________
lispweb mailing list
lispwebred-bean.com
http
://www.red-bean.com/mailman/listinfo/lispweb

   So allegroserve offers a global timeout for the whole
request
   (which defaults to 300 seconds if you're also doing
timeout
   on each I/O).   If you know you'll be sending things
that
   could take a long long time then feel free to change
   the 300 to a huge value. You're still protected by the
timeout
   on I/O which will ensure that some progress gets made
ever
   N seconds (default 120).

Ah, well I'm not sure that was clear from the doc but thanks
for the
tip, I guess I need to do a separate publish on the audio
files.

Thanks,

-n



_______________________________________________
lispweb mailing list
lispwebred-bean.com
http
://www.red-bean.com/mailman/listinfo/lispweb

   Date: Thu, 3 May 2007 11:50:24 +0100 (BST)
   From: Nick Levine <ndlravenbrook.com>
   Cc: lispwebred-bean.com
   Precedence: list
   Content-Type: text/plain; charset="us-ascii"
   Sender: lispweb-bouncesred-bean.com

      So allegroserve offers a global timeout for the whole
request
      (which defaults to 300 seconds if you're also doing
timeout
      on each I/O).   If you know you'll be sending things
that
      could take a long long time then feel free to change
      the 300 to a huge value. You're still protected by the
timeout
      on I/O which will ensure that some progress gets made
ever
      N seconds (default 120).

   Ah, well I'm not sure that was clear from the doc but
thanks for the
   tip, I guess I need to do a separate publish on the audio
files.

OK I give up. Where is this set?

For instance, I publish the root for ilc07.org via

  (publish-directory :host *ilc-vhost-names*
		     :prefix "/"
		     :destination "/home/alu/ilc/www/)

which gives me a DIRECTORY-ENTITY. I inspect that and its
timeout slot
has value 8640000. Comforting in that it corresponds to what
my copy
of source said would happen. But it doesn't explain where
the 300 is
that I want to overwrite.

- nick



_______________________________________________
lispweb mailing list
lispwebred-bean.com
http
://www.red-bean.com/mailman/listinfo/lispweb