rnewson commented on code in PR #5469:
URL: https://github.com/apache/couchdb/pull/5469#discussion_r1990018411
##########
src/nouveau/src/nouveau_api.erl:
##########
@@ -318,15 +318,34 @@ send_if_enabled(Url, Header, Method, Body) ->
send_if_enabled(Url, Header, Method, Body, Options) ->
case nouveau:enabled() of
true ->
- ibrowse:send_req(Url, Header, Method, Body, Options);
+ retry_if_connection_closes(fun() ->
+ ibrowse:send_req(Url, Header, Method, Body, Options)
+ end);
false ->
{error, nouveau_not_enabled}
end.
send_direct_if_enabled(ConnPid, Url, Header, Method, Body, Options) ->
case nouveau:enabled() of
true ->
- ibrowse:send_req_direct(ConnPid, Url, Header, Method, Body,
Options);
+ retry_if_connection_closes(fun() ->
+ ibrowse:send_req_direct(ConnPid, Url, Header, Method, Body,
Options)
+ end);
false ->
{error, nouveau_not_enabled}
end.
+
+retry_if_connection_closes(Fun) ->
+ MaxRetries = max(1, config:get_integer("nouveau", "max_retries", 5)),
+ retry_if_connection_closes(Fun, MaxRetries).
+
+retry_if_connection_closes(_Fun, 0) ->
+ {error, connection_closed};
Review Comment:
retrying any request can't harm the index (each request has to have the
current index seq on it, and nouveau rejects the request if it doesn't match).
there's a few protections around this as a consequence of not using erlang
distributed protocol, like each index updater loop gets its own connection and
sends all its requests down that, to ensure they are not reordered in-flight,
etc).
the retry loop could cause an index updater to crash (with the a 409
'updates out of order') but that'll just cause the updater to crash, a retry
will pick up where it left off.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@couchdb.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
