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.
