Fork me on GitHub

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

Alex Miller (Clojure team)15:07:47

whichever one is doing IO?

Alex Miller (Clojure team)16:07:24

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)
What should I look for? There is some doc about debug it? What the name of this problem (so I can search resources my own)


"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?

Alex Miller (Clojure team)16:07:32

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


d/pull inside #pathom resolvers

Alex Miller (Clojure team)16:07:07

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

Alex Miller (Clojure team)16:07:13

and thus don't do it in a go block


move to client.async should solve it?

Alex Miller (Clojure team)17:07:51

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

👍 4