Hi Tommi,

thank you for this clarification. But, I am still a bit unsure:

    size_t bytesRead = 0;
    char buffer[KB(16)];
    while ((bytesRead = streamer->Read(buffer, KB(16))) > 0 && length) {
      reply.out().write(buffer, bytesRead);
      length -= bytesRead;
    }

This loop runs until the very end of the file or when the specified
length, which shall be streamed is reached. If I read your statement
correctly, this loop causes the issue because the loop does not end
though the actual request was canceled or stopped.

How can I detect, if I may leave the loop because the request was terminated?

2012/11/12 Tommi Mäkitalo <[email protected]>
>
> Am 12.11.2012 19:51, schrieb Denis Loh:
> > Hi,
> >
> > I recently asked the question, how to count the number of active
> > requests of a tntnet application. The solution which Tommi and the rest
> > posted here are working fine. However, there's a little drawback, I
> > can't solve somehow.
> >
> > This is my request counter in the request scope. I was thinking that, if
> > the request is closed, the counter will be decremented.
> > <%request>
> >     request_counter_t counter;
> > </%request>
> >
> > True, it's working. However, the more interesting question is not if,
> > but when the connection is closed?
> >
> > After 10 minutes of waiting, I get this error:
> >
> > 2012-11-09 06:48:10.22709 [4703.140470126638848] FATAL tntnet.worker -
> > requesttime 600 seconds in thread 140470229518080 exceeded - exit process
> >
> > I added a keepAliveTimeout of 60 seconds. So, my assumption was that the
> > connection is closed shortly after 60 seconds, doesn't it?
> >
> > How could I reduce the requesttime from 600s to 120s or some other
> > arbitrary timeout?
> >
> > Thank you!
> >
> > Denis
> Those timeouts are different things. The request scope variable is
> destroyed just after the reply is sent. This does not mean, that the
> connection is closed. In keep alive, the connection is held until the
> keep alive timeout is reached. But this can't be detected in a
> application. And it should be transparent to the client.
>
> This fatal error is something very different. A single request must not
> take too long. Normally the client gets impatient after some minutes and
> times out. And the client is right. Http demands, that a request is
> answered more or less immediately. Tntnet keeps track of it and if a
> component do not answer the request after 10 minutes, it assumes, that
> the application hangs in an endless loop. The only thing tntnet can do
> to stop the loop is to restart the whole tntnet process. This is
> possible, since tntnet has a monitor process, which restarts the worker
> process, if the worker process decides, that it should be restarted.
>
> If you really want to run a request longer (you have to have good
> reasons to do so), you have to notify tntnet, that the application is
> still alive by calling "request.touch()" before this 10 minute timeout,
> which rewinds the timer.
>
> Tommi
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Tntnet-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tntnet-general

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general

Reply via email to