I have a web application using warp and while trying to query some large-ish using curl I noticed the connection get shutdown exactly after 1 minute transfer. I increased curl's own timeout but this did not changed anything so I assume this is set on the server side.
Is this actually the case there is a 60s timeout on sending response in warp, and if yes, how can I control it?
Related
So, I have Express server that accepts a request. The request is web scraping that takes 3-4 minute to finish. I'm using Bull to queue the jobs and processing it as and when it is ready. The challenge is to send this results from processed jobs back as response. Is there any way I can achieve this? I'm running the app on heroku, but heroku has a request timeout of 30sec.
You don’t have to wait until the back end finished do the request identified who is requesting . Authenticate the user. Do a res.status(202).send({message:”text});
Even though the response was sended to the client you can keep processing and stuff
NOTE: Do not put a return keyword before res.status...
The HyperText Transfer Protocol (HTTP) 202 Accepted response status code indicates that the request has been accepted for processing, but the processing has not been completed; in fact, processing may not have started yet. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.
202 is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.
You always need to send response immediately due to timeout. Since your process takes about 3-4 minutes, it is better to send a response immediately mentioning that the request was successfully received and will be processed.
Now, when the task is completed, you can use socket.io or web sockets to notify the client from the server side. You can also pass a response.
The client side also can check continuously if the job was completed on the server side, this is called polling and is required with older browsers which don't support web sockets. socket.io falls back to polling when browsers don't support web sockets.
Visit socket.io for more information and documentation.
Best approach to this problem is socket.io library. It can send data to client send whenever you want. It triggers a function on client side which receives the data. Socket.io supports different languages and it is really ease to use.
website link
Documentation Link
create a jobs table in a database or persistant storage like redis
save each job in the table upon request with a unique id
update status to running on starting the job
sent HTTP 202 - Accepted
At the client implement a polling script, At the server implement a job status route/api. The api accept a job id and queries the job table and respond with the status
When the job is finished update the job table with status completed, when the jon is errored updated the job table with status failed and maybe a description column to store the cause for error
This solution makes your system horizontaly scalable and distributed. It also prevents the consequences of unexpected connection drops. Polling interval depends on average job completion duration. I would recommend an average interval of 5 second
This can be even improved to store job completion progress in the jobs table so that the client can even display a progress bar
->Request time out occurs when your connection is idle, different servers implement in a different way so timeout time differs
1)The solution for this timeout problem would be to make your connections open(constant), that is the connection between client and servers should remain constant.
So for such scenarios use WebSockets, which ensures that after the initial request and response handshake between client and server the connection stays open.
there are many libraries to implement realtime connection.Eg Pubnub,socket.io. This is the same technology used for live streaming.
Node js can handle many concurrent connections and its lightweight too, won't use many resources too.
I run sanic application and it raises an exception every several seconds even without any request coming in.
sanic.exceptions.RequestTimeout: Request Timeout
How to fix the issue?
I would point you towards the documentation so that you understand what you are doing and why you are receiving that exception. Just blindly changing KEEP_ALIVE to False may not be what you want.
The KEEP_ALIVE config variable is set to True in Sanic by default. If you don’t need this feature in your application, set it to False to cause all client connections to close immediately after a response is sent, regardless of the Keep-Alive header on the request.
The amount of time the server holds the TCP connection open is decided by the server itself. In Sanic, that value is configured using the KEEP_ALIVE_TIMEOUT value. By default, it is set to 5 seconds, this is the same default setting as the Apache HTTP server and is a good balance between allowing enough time for the client to send a new request, and not holding open too many connections at once. Do not exceed 75 seconds unless you know your clients are using a browser which supports TCP connections held open for that long.
The issue comes from the fact that the connection remains alive. Adding following configuration seems to have fixed my issue
from sanic.config import Config
Config.KEEP_ALIVE = False
I am using 'request' node.js module (https://github.com/request/request) to send requests to another service.
And sometimes it is needed to send request and wait for the response infinitely, because of the slowness of this service to which the request was sent.
It is possible to set 'timeout' property to the request and by this way you will override the default value for read and connection timeout:
timeout - Integer containing the number of milliseconds to wait for a server to send response headers (and start the response body) before aborting the request. Note that if the underlying TCP connection cannot be established, the OS-wide TCP connection timeout will overrule the timeout option (the default in Linux can be anywhere from 20-120 seconds).
But what value we can set to make this timeout infinite?
Set the server.timeout property from 120,000 (default) to 0
All clients have their own timeout(chrome, Firefox,...) then you must to think that's it's not useful to set a infinite timeout, you must to re-think your problem that's not the good way man
In Chrome, Socket IO seems to stop transmitting data. Is there an internal reason for this?
I've tried a very simple client and simple server side but consistently the server stops receiving any emits after 5 minute, will then reconnect and it's fine for another 5 minutes.
On top of the internal ping mechanism I have a polling mechanism which sends back session data every 20 seconds.
I don't use WebSocket with NodeJS or Socket.io but experienced the same behaviour with Jetty. It turns out that Jetty has an idle timeout default to 5 minutes (or 300 seconds) for all WebSocket's sessions. You could change the default idle timeout value to an appropriate value or ping/pong those connections before it timed out.
In my situation, I decided to use ping/pong as it also helps determine when the connection is no longer there. I observed that in some cases, connection was not closed even when the network is down.
According to engine.io (which is used by socket.io) docs, the server seems to have default pingInterval of 25 seconds. So unless you inadvertently disabled or changed default options, the ping/pong mechanism should be in place.
I'm using Socket.io on a project and would use XHR polling, but I have a limit of 6 concurrent connections. Therefore, after opening 5 tabs, Socket.io starts to hang.
If I set the polling duration to 0 seconds (20 is the default), the limit no longer affects the application but Firebug shows that there's a request every second.
If I use a 0 second limit, how this affect my server and users?
When you set a duration, you are using XHR long-polling. This duration instructs the server on how long to keep a HTTP request open when it does not have any data to send. If the server does have data to send, the data is sent instantly and the connection is closed. The client then creates a new connection and the cycle continues.
When you set the duration to zero, you are effectively telling the server to use short-polling, which if the client asks the server for data, the server will instantly respond with an empty response, or with the data.
The influences that short-polling will have on the client and server are that the client will not receive messages instantly as long-polling would allow, but it consumes less resources because the HTTP request is not kept open. This also means that you probably won't hit your concurrent connection limit, because the connections end immediately.