Since golang handles incoming requests in separate goroutines, it's unclear to me which types of tasks should be deferred for processing by a message queue e.g. NSQ consumers and which should be handled within the http request goroutine.
Since the net/http package runs each request you do not need to worry about blocking the request goroutine. The real question you should ask myself is "Do I need to do this before I return a response to the client, or can it be deferred until later". Generally if I need to fetch from a database to serve a response that will block the request goroutine, and that is ok. If I can return a response now and put a message on a queue to do stuff later, that can be ok too.
Since the request goroutine has little cost to exist, and it is isolated from other requests, you really don't need to worry about it that much. Do what makes sense for the client.
Related
I want to invoke an HTTP POST with a request body and wait until it has reached the receiver, but NOT wait for any full response if the receiving server is slow to send the response.
Is this possible at all to do reliably? It's been years since I studied the internals of TCP/IP so I don't really remember the entire state machine here.
I guess that if I simply incur a timeout of say 1 seconds and then close the socket, there's no guarantee that the request has reached the remote server. Is there any signalling at all happening when the receiving server has received the entire request, but before it starts sending its response?
In practical terms I want to call a webhook URL without having to wait for a potentially slow server implementation of that webhook - I want to make the webhook request as "fire and forget" and simply ignore the responses (even if they are intermediate errors in gateways etc and the request actually didn't reach its final destination), but I'm hesitant to simply setting a low timeout (if so, how low would be "sufficient", etc)?
I stumbled upon a case where a request to an endpoint might take more than 60 seconds (let's say that's the timeout value), in which case the server sends a response and continues processing the request in the background. There are also cases where the same request would be processed before it times out and a successful response would be sent from the server to the client.
What would be the best HTTP code to use in those first case? I read HTTP server timeout. When should it be sent, which suggests 503 or 504, and HTTP status code for 'Loading', which mentions that the request can be deemed successful and return 200. But I'm not convinced by any of those suggestions more than the others yet.
No
HTTP protocol doesn't work that way.
A server would receive a request, process it and sends a reply. The cycle ends there.
HTTP is never intended to send multui-stage replies with different states. You need to work on a custom protocol built on top of HTTP if you want to do that.
Sending timeout error as an indication of an unfinished response is an anti pattern. If your server takes more time than usual to process a request, you should send a success response with an ID which can be used to poll the state of the initial request and get the results.
So to summarize from your question and comments: you have an HTTP API that takes a command and executes it, and sends a callback-reply through a webhook. If the execution takes longer than a minute, you have to send some form of reply that indicates the request is still being processed.
There are various problems with executing long-running work in an HTTP request handler. For starters, you tie up HTTP server resources (threads, sockets) while processing non-HTTP work, you can't restart the HTTP server without losing work, and so on.
So I would opt for a queuing mechanism that takes in the work, replies 200 OK or 201 Created immediately, and then schedules the work for processing on a background thread or even a different service. When finished, you execute the webhook callback.
Any error response to the initial call will leave the caller confused: they won't know whether their requested work will finish, unless you use an "exotic" status code that actually differs from real error conditions, and document that they can expect that.
Charlie and CodeCaster suggested to return 200 or 201 and I took a look at the other 2xx codes and found 202 Accepted:
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202
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.
I wonder if this would fit best.
I understand an HTTP request will result in a response with a code and optional body.
If we call the originator of the request the 'client' and the recipient of the request the 'server'.
Then the sequence is
Client sends request
Server receives request
Server sends response
Client receive response
Is it possible for the Server to complete step 3 but step 4 does not happen (due to dropped connection, application error etc).
In other words: is it possible for the Server to 'believe' the client should have received the response, but the client for some reason has not?
Network is inherently unreliable. You can only know for sure a message arrived if the other party has acknowledged it, but you never know it did not.
Worse, with HTTP, the only acknowledge for the request is the answer and there is no acknowledge for the answer. That means:
The client knows the server has processed the request if it got the response. If it does not, it does not know whether the request was processed.
The server never knows whether the client got the answer.
The TCP stack does normally acknowledge the answer when closing the socket, but that information is not propagated to the application layer and it would not be useful there, because the stack can acknowledge receipt and then the application might not process the message anyway because it crashes (or power failed or something) and from perspective of the application it does not matter whether the reason was in the TCP stack or above it—either way the message was not processed.
The easiest way to handle this is to use idempotent operations. If the server gets the same request again, it has no side-effects and the response is the same. That way the client, if it times out waiting for the response, simply sends the request again and it will eventually (unless the connection was torn out never to be fixed again) get a response and the request will be completed.
If all else fails, you need to record the executed requests and eliminate the duplicates in the server. Because no network protocol can do that for you. It can eliminate many (as TCP does), but not all.
There is a specific section on that point on the HTTP RFC7230 6.6 Teardown (bold added):
(...)
If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last
HTTP response.
(...)
To avoid the TCP reset problem, servers typically close a connection
in stages. First, the server performs a half-close by closing only
the write side of the read/write connection. The server then
continues to read from the connection until it receives a
corresponding close by the client, or until the server is reasonably
certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection.
So yes, this response sent step is a quite complex stuff.
Check for example the Lingering close section on this Apache 2.4 document, or the complex FIN_WAIT/FIN_WAIT2 pages for Apache 2.0.
So, a good HTTP server should maintain the socket long enough to be reasonably certain that it's OK on the client side. But if you really need to acknowledge something in a web application, you should use a callback (image callback, ajax callback) asserting the response was fully loaded in the client browser (so another HTTP request). That means it's not atomic as you said, or at least not transactional like you could expect from a relational database. You need to add another request from the client, that maybe you'll never get (because the server had crash before receiving the acknowledgement), etc.
I want to send the same http request repeatedly unless I get the right response, and the server is slow, sending the request is quick, receiving the response is quick also, but waiting for server to handle the request is slow. So if I send the request, and then waiting the failure should not be acceptable.
I think of the following workflow:
1)Sending the request
2)After sending the data, start a new request to send the same request
repeat 1-2, and the response should be handled asynchronously, and when detecting the right response, it stop sending request.
How to achieve this workflow or any other workflow can solve my problem. Any language and tool which will be fast would be considerable, like C/C++.
This will cause the server to simply respond slower and slower; your first request will be the first to receive any response, all the others will be wasted CPU time and bandwidth - if you did that to my servers you'd get your IP banned automatically.
What you need to consider is
why do you need the response this fast?
can you cache the response so that re-requesting it is no longer needed
perhaps having a caching proxy between your client(s) and the server will cover your needs? (also, prefetching)
I have been exploring Netty for the past days, as I am writing a quick and tight HTTP server that should receive lots of requests, and Netty's HTTP server implementation is quite simple and does the job.
My next step is as part of the request handling, I need to launch an HTTP request to an external web server. My intuition is to implement an asynchronous client that can send a lot of requests simultaneously, but I am a little confused as what is the right approach. My understanding is that Netty server uses a worker thread for each incoming message, therefore that worker thread would not be freed to accept new messages until my handler finishes its work.
Here is the punch: even if I have an asynchronous HTTP client in hand, it won't matter if I need to wait for each response and process it back with my server handler - the same worker thread would remain blocking all this time. The alternative is to use the async nature of the client, returning a future object quickly to release the thread and place a listener (meaning I have to return 200 or 202 status to the client), and check my future object to indicate when the response is received and I can push it to the client.
Does this make sense? Am I way off with my assumptions? What is a good practice to implement such kind of Netty acceptor server + external client with high concurrency?
Thanks,
Assuming you're asking about Netty 4.
Netty configured with a ServerBootstrap will have a fixed number of worker threads that it uses to accept requests and execute the channel, like so:
Two threads accepting / processing requests
bootstrap.group(NioEventLoopGroup(2))
One thread accepting requests, two threads processing.
bootstrap.group(NioEventLoopGroup(1), NioEventLoopGroup(1))
In your case, you have a channel includes a bunch of Http Codec decoding/encoding stuff and your own handler which itself makes an outgoing Http request. You're right that you don't want to block the server from accepting incoming requests, or decoding the incoming Http message, and there are two things you can do to mitigate that, you've struck on the first already.
Firstly, you want to use an Async netty client to make the outgoing requests, have a listener write the response to the original requests channel when the outgoing request returns. This means you don't block and wait, meaning you can handle many more concurrent outgoing requests than the number of threads available to process those requests.
Secondly, you can have your custom handler run in its own EventExecutorGroup, which means it runs in a separate threadpool from the acceptor / http codec channel handlers, like so:
// Two separate threads to execute your outgoing requests..
EventExecutorGroup separateExecutorGroup new DefaultEventExecutorGroup(2);
bootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
#Override
public void initChannel(SocketChannel ch) {
ChannelPipeline pipeline = ch.pipeline();
.... http codec stuff ....
pipeline.addLast(separateExecutorGroup, customHandler);
}
};
Meaning your outgoing requests don't hog the threads that would be used for accepting / processing incoming ones.