Not sure which is the best, but I've had very good success with .

I evaluated a bunch recently and liked diehard the most

• https://github.com/sunng87/diehard if you cannot use JDK17+ • https://github.com/KingMob/TrueGrit if you can

FWIW, cljdoc uses https://github.com/joegallo/robert-bruce

What are we retrying?

sorry, but: https://grishaev.me/en/clojure-with-retry/

File system reads that might throw FileSystemException s

Interesting. I'm curious, why do you think calling the same function more than once might have a different result? Im just asking the first thing that comes to mind, so feel free to ignore me. 😜

We’re assuming that there’s transient issues with a file system mount

TL;DR: by retrying, you're just closing your eyes to the real problem

Hmmm, yeah. I don't have good ideas given what i know. GL.

huh ngl, the article seems to lack nuance. The vast majority of times what's being retried is network issues or the given remote api having some sort of hiccup. A good retry impl with specifically observe 5XX status codes or timeout exceptions. If peers didn't observe that, it has nothing to do with retrying or clojure 🤷

I don't have a particular opinion about file systems, although it's not rare to find articles explaining how they're quite the rabbit hole, a leaky abstraction, etc etc. I'd log the error for future examination but also retry if that happens to fix things. Most devs aren't going to casually become fs experts overnight.

funny, I'm currently working on a resilience lib that more or less solve the issues in that article

tl;dr have users specify a retry? fn

safely, linked above, has a parameter - :retryable-error? - that gives users control over when it actually makes sense to retry versus when it doesn't, by allowing them to pass a predicate function to match on the exception type. it also logs using the excellent mulog library by default, so it's not throwing information away. it makes it pretty easy to "do the right thing" and gradually incorporate more error handling into the retry loop with the benefit of detailed logs, just as the article recommends.

If by "Clojure" library you mean "JVM" library, then I highly recommend failsafe. https://github.com/failsafe-lib/failsafe You might be after something written in Clojure and that's totally fair but when it comes to retry and fault tolerance, failsafe really does deserve a mention.

You actually don't need a library for retries. Here's exponential backoff with 4 attempts max:

(loop [retries [100 200 400 800]]
  (let [res
        (try :...
             (catch Exception e
               (if retries
                 (do (Thread/sleep (first retries))
                     :retry)
                 (throw e))))]
    (if (= :retry res)
      (recur (next retries))
      res)))

that's why you use trampoline

(trampoline ((fn f [tries] (try ... (catch ... f))) 0))

I always forget about trampoline

🫂

I'm probably not the right audience for the question since I don't know what it means. But out of curiosity - what does the question mean?

(locking :synchronization-from-hell
  ...)

Ah, huh. That's... interesting.

https://github.com/clojure/core.typed/blob/master/typed/checker.jvm/test/clojure/core/typed/test/core.clj#L3607

You can beat that with

(locking false (+ 1 2))

Unrelated, but still weird: https://github.com/phronmophobic/clj-media/blob/main/src/com/phronemophobic/clj_media/impl/cljfx.clj#L59-L61 Probably a missed second argument to locking?

yup, it should almost certainly be locking on draw-lock. I think that namespace was just for a proof of concept that I never finished.

is there a reason for the question?

I guess it has to do with the fact that keywords are interned. If you do it at least on namespaced keywords then you have global monitors usable from everywhere that don't even need to require? 😛 And then grep to understand what is going on

although they are interned with WeakReferences, so no idea what happens when you are locking against an object that can be collected?

Locking on interned things is deeply bad (this is a known bad pattern for Strings in Java for example). Please don’t do that :)

We were musing about if keywords could become value classes in Java 24 or whenever they land. If so, they would not have identity (so also don’t do identity checks) or be lockable.

Will get back to you in 5 yrs :)

> We were musing about if keywords could become value classes in Java 24 or whenever they land. If so, they would not have identity (so also don’t do identity checks) or be lockable. Would that be backwards incompatible with the edn spec? > If the target platform supports some notion of interning, it is a further semantic of keywords that all instances of the same keyword yield the identical object. > -- https://github.com/edn-format/edn