Closed zuiderkwast closed 3 years ago
The gun_up
isn't unexpected because you let Gun reconnect automatically (it'll do that by default). The second gun_down
is not normal though.
In general it's OK to send more requests, they should be postponed until Gun has reconnected. But there's probably lots of corner case issues.
Ah... So, disabling automatic reconnect will cause the errors to be returned immediately? I have to check....
Not what I meant, this probably still is an issue. Just responding to the other points at the end of your report.
Right. Anyway, the important point for us is that we can retry the request as soon as possible on a different connection, so I guess we must use retry => 0
. Then, with the same scenario, I only get response headers and body for the first request and then a {gun_down, ConnPid, http2, normal, []}
. No error for the 2nd request is sent.
%% Actual behaviour: We get response for the 1st request first.
{gun_response, ConnPid, StreamRef1, nofin, 200, _} = receive M1 -> M1 end,
{gun_data, ConnPid, StreamRef1, fin, <<"hello">>} = receive M2 -> M2 end,
%% Then, a single gun_down message.
{gun_down, ConnPid, http2, normal, []} = receive M3 -> M3 end,
%% No error is sent for the 2nd request.
no_more_message = receive M4 -> M4 after 0 -> no_more_message end,
So I suppose in that case the problem is that the request is postponed despite the fact that it won't be handled, when retry is disabled we could produce errors instead of postponing.
Exactly. Here is a PR: #252.
Merged, thanks!
Scenario: On a connection with constant high load, the server sends a GOAWAY frame. Then, before all the streams have completed, more requests are sent to the Gun process by the application.
Expected behaviour: The
gun_error
needs to be sent instantly, so that the application can retry the request on a different connection (typically to a different machine in a cloud setup of some sort).Actual behaviour: The errors are not sent until all streams are completed. Additionally, two unexpected extra messages
gun_down
andgun_up
are sent when the streams have completed.The test case below illustrates the current actual behavior:
This scenario is expected to be common whenever a remote server is being taken out of service.
Apart from getting the
gun_error
as soon as possible, before the other streams have completed, it would also be useful to be informed that the connection is going down, so that the application can avoid sending more requests to it, or perhaps it would be enough to indicate this in the Reason element of thegun_error
tuple.