Re: handler timeout

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.

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.
>