Clojurians Log v2

How can I detect which library/go-block is locking my system? my system has locked, and I solved it with -Dclojure.core.async.pool-size=500

whichever one is doing IO?

if you take a thread dump, it's probably obvious

like, I mean, first guess is look at the ones you wrote

Lot of threads in many states:

java.lang.Thread.State: RUNNABLE
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
   java.lang.Thread.State: TIMED_WAITING (parking)
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   java.lang.Thread.State: WAITING (on object monitor)
   java.lang.Thread.State: WAITING (parking)

"doing io in go blocks"

if you are digging through thread dumps you should not set the core.async pool size so high

but even before digging through threaddumps I would go back and look at the code I wrote to see if I am doing anything blocking in a go block

I'm back on default core.async (that freezes my system) with my system frozen

or in a transducer on a channel that might run on the async threadpool

when you say freezes your system, what do you mean?

is it live lock or dead lock?

dead lock is nothing happening (so low resource usage) live lock is lots going on (high resource usage) but nothing happening

There is a deftest block that freezes. It simply stops, no more logs, do not end and CPU goes to "0%"

Many of java.lang.Thread.State: WAITING (parking) are caused due (<!! p) inside datomic.client.api where p is a clojure.core/promise. Is it relevant?

my guess there would be you are waiting on a channel that doesn't have anything written to it somewhere

s/many/all "async-dispatch" threads/

what datomic operations are you doing in go blocks?

<!! is a blocking operation and you shouldn't do that in a go block

d/pull inside #pathom resolvers

d/pull is a database op, which should always be assumed to be IO

and thus don't do it in a go block

move to client.async should solve it?

probably better, but I would read the fine print and still probably shouldn't do it in a go block - prob a better question for #datomic. doing this in pipeline-blocking or pipeline-async or a no-go thread prob better