Re: handler timeout

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 ?