Re: handler timeout

On 28.03.2018 13:13, PANG J. wrote:
> As shown below,
>
>
> Last day total requests are 42,368,982,  not all are successful, but 42,362,363 are right.
>
> The failed requests are timeout.
>

OK, that is quite an impressive number of requests, and a good answer to people who always 
wonder if an Apache/mod_perl/perl solution is really scaleable..
(Perl/mod_perl advocates, take note)

5619 failed requests, on a total of 42,368,982 is approximately a 0,013% failure rate.

That does no really look like justifying a complete architecture change.

Can you maybe reprogram the client-side app, to wait for a "normal" time, and if there is 
a timeout, ask the user if they want to continue waiting, or abort the call ?

(According to the numbers above, such a message should only appear in 0,013% of the cases, 
and the other 42,362,363 (99.987%) clients will never see it.)


> Thanks.
>
>
>
> On 2018/3/28 星期三 PM 6:37, André Warnier (tomcat) wrote:
>> On 28.03.2018 12:31, PANG J. wrote:
>>> what the client I meant is mobile App.
>>> mobile App gets the result from server via SDK.
>>
>> Ok. But it is very likely that your "mobile app SDK", also has a timeout after it sends
>> a request to a server. Or are you /sure/ that it waits forever ?
>> /Precisely what/ makes you think that it is a server-side timeout ?
>>
>>> in future we may move the computing task into App itself.
>>> But currently they are running on server side.
>>>
>>> thanks.
>>>
>>> On 2018/3/28 星期三 PM 6:11, André Warnier (tomcat) wrote:
>>>> I believe that the timeout which Pang J. is mentioning, may be the browser-side timeout,
>>>> which is fixed at the browser level at about 5 minutes or so.
>>>> When a browser sends a request to a server, and it does receive /some/ response within
>>>> the next +-5 minutes, then the browser will drop the connection to the server, and pop
>>>> up a message saying "sorry, the server appears not to respond.."
>>>> In other words, it is not a server timeout, it is a client timeout.
>>>> The only way to avoid this, is to insure that the server sends at least /some/ temporary
>>>> response to the client (*), regularly, so that this browser timeout does not occur.
>>>> Unfortunately, that is a bit more complicated to set up, than just some parameter
>>>> somewhere.
>>>> But there must be plenty of past discussions of this issue already on the www, and
>>>> solution guidelines.
>>
>