On 28.03.2018 12:54, PANG J. wrote:
> I do think it's a client timeout.
>
Ok, then there are many kinds of answers to your question..
1) the quick and dirty solution, is to find out how to set the timeout higher in your app
SDK, and set it high enough so that the timeout never happens.
As far as I know, there is no timeout at the server side. The server-side app will just
take whatever time it takes to provide the response, and then the server will send it.
If the connection to the client is still open when that happens, then everything will be
fine. If by that time the client has closed the connection (because it was tired of
waiting), then you will see an error both on the client side (the timeout), and on the
server side : something in the error log like "cannot send response : connection closed by
client".
But that is not a "good" solution, for a number of reasons. One reason is that then, if
there really is a problem on the server, the client will have to wait for a very long
time, before it sees the error.
Another reason is that you will "block" one server-side webserver process or thread, for
as long as it takes to generate one response. That will use up a lot of resources on your
server (which maybe is not very important to you, but it is still quite inefficient).
2) a slightly better solution, would be looking at some of the links found in Google, for
"tricks" to get around the browser timeout (your app is not a browser, but it is a HTTP
client, so maybe some of these tricks apply to you also).
3) a better solution would be to change the logic of your applications, and use one of the
"job queue frameworks" which a previous person mentioned.
That would avoid these timeout issues, and is more efficient both for the client and the
server. But it does require changes in the design of your application, and the user
interface.
4) an even higher level question, is whether HTTP 1.x is really the appropriate protocol
to use, for such a type of application. HTTP was fundamentally designed (some 30 years
ago) to handle a case of "one request, one response", and the requests were supposed to be
for something like a single HTML document. So the request-response cycle was not supposed
to take more than a few seconds.
And that is why HTTP clients time out after a couple of minutes waiting, because in HTTP,
this is fundamentally considered as possible only if there is a network problem or a
server problem, and it is thus considered /as an error/.
HTTP was not really designed for handling long-processing-time requests, and that
fundamental architecture is still the base of HTTP today. There have been lots of clever
developments since then to "get around" that kind of limitation (such as the job queues
mentioned above), and javascript applets and whatever, but the fundamental truth is that
all of those are like ways to just get around the basic HTTP (1.x) protocol design, and
they are always somewhat clunky or delicate, just because they have to "fight" against
this basic HTTP design.
Maybe you should have a look at HTTP 2.0, if your client-side applet SDK supports it.
And if it does not support it, maybe you should look at alternatives to standard HTTP
servers, on the server side.
If you want to stay in the perl world for that, you may want to have a look at
http://search.cpan.org/~miyagawa/Starman-0.1000/lib/Starman.pm > regards.
>
> On 2018/3/28 ??? PM 6:37, André Warnier (tomcat) wrote:
>>
>> 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 ?
