Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add request retry functionality #23

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

vincentjames501
Copy link

This is an initial crack to resolve #21. It's easily extendable and provides a reasonable retry strategy when :auto is supplied.

(catch Exception e
(throw (unwrap-async-exception e)))))))

(def default-wrapped-request (middleware/wrap-request request*))
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it so every request doesn't have to rebuild the entire middleware chain

(reify Function
(apply [_ e]
(raise (unwrap-async-exception e))))))
(try @resp-fut
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since .send is still async (it just does a .get internally), I don't think we're losing anything by handling it this way other than we must unwrap ExecutionException

(-> (.sendAsync http-client http-request bh)
http-request (ring-request->HttpRequest req)
retry-handler (if (= :auto retry-handler) default-retry-handler retry-handler)
body-handler (HttpResponse$BodyHandlers/ofInputStream)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to bring back the ->BodyHandler function, but confused me at first passing the as field and doing nothing with it.


(-> (.sendAsync http-client http-request bh)
http-request (ring-request->HttpRequest req)
retry-handler (if (= :auto retry-handler) default-retry-handler retry-handler)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call it

:retry-handler or just :retry?

Should we call it :auto or :default?

Personally, I'd like to make it the retries truly default like Apache HttpClient does, however, I realize that is a decent change to default behavior so opt-in makes sense.

(reify Function
(apply [_ [resp e]]
(let [retry-fut (if retry-handler
(retry-handler resp e req retry-count)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should put some of this in a map instead so it is more easily extensible in the future? Something like a retry-context map?

ex)
ex))

(def retry-exceptions
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think these should be in client.clj or should we move to a separate namespace?

{:name "file" :content (io/file ".test-data")}
{:name "data" :content (.getBytes "hi" "UTF-8") :content-type "text/plain" :file-name "data.txt"}
{:name "jsonParam" :content (io/file ".test-data") :content-type "application/json" :file-name "data.json"}]})
(hc/post "http://moo.com"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just making a quick doc change here. Doesn't make sense to do a multipart get request :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider adding a retry handler
1 participant