(defn retry-fn-exec [^HttpClientBuilder builder
request]
(when (:retry-fn request)
(.setServiceUnavailableRetryStrategy builder
(proxy [ServiceUnavailableRetryStrategy] []
(retryRequest [^HttpResponse resp cnt ctx]
(println ::AAA)
(boolean (when (and (= 400 (-> resp
.getStatusLine
.getStatusCode))
(> 3 cnt))
true)))
(getRetryInterval []
0)))))
#_(-> {:url ""
:keystore-type "pkcs12"
:cache true
:retry-fn true
:http-builder-fns [retry-fn-exec]}
client/request) @d.ian.b just started working on this, indeed this works pretty nicely, doesn't quite cover (yet?) all the use cases for me, it def simplified a lot of code
that's awesome! 😄
which cases are not covered by this? (just out of curiosity)
not sure yet, I need to tidy up the code and check failing tests - I'll report back 🫡
Nice, I have test harness which spins up a local jetty server to simulate all kinds of issues - I’ll see how that behaves 👍
Btw @lukaszkorecki, I have a lib for mock testing http-clj 😄 https://github.com/ianffcs/apache-http-client-ring-adapter/pulls
I've add a retryable client in this PR, if you think it's good enough 😄
(tomorrow I'll take a look again into it before merging it)
interesting approach - I went a different way by providing a http client protocol, and different versions of the client - one for making real requests, and mock one that can be used to provide Ring-style responses on matched requests
I really wanna know about your exps on it
prolly not gonna get to it this week, we will see
Here's more or less what I ended up with - it does all the things my teams need: https://gist.github.com/lukaszkorecki/f2f83e98c3b2283b0f156814883ff11c
Nice. Why deftype and not defn+proxy?
from what I remember, it things tidier from the JVM level: actual classes will be created and all that, so it will be somewhat faster to deal with than repeated call to proxy - also was much easier to express mutable nature of associated objects and such