Early testing of 1.2-alpha-3 showed some issues with the new default :executor during our integration tests. When executing an operation inside a resolver the threadpool locks up. We fixed it by using the clojure.lang.Agent/soloExecutor (which is basically the same threadpool that was used by the future’s before). Is there any reason to use a different threadpool? It isn’t clear to me what the intended use is for the new option :thinking_face:

the default executor is limited to 10 threads, where as soloExecutor is open ended, if the default is locking up but soloexecutor is not, that suggests the 10 threads in the default executor are blocked doing something

derefing a promise that the 11 operation in the queue would deliver to or something

It has been a long time since I have seriously had my head in lacinia, but I believe resolvers sort of operate under the same rules as core.async go blocks, you shouldn't be running blocking operations in them, it is all callbacks and what not, if you do run blocking operations in them you can block up the bounded threadpool

I suppose that makes sense. I’ll try and investigate why it’s locking up. I got a report that it was locking up after 1 thread (instead of 10); but i haven’t seen it myself yet. Avoiding blocking code in resolvers is sometimes hard too 😅 we access the db occasionally (so that could be the problem as well 😛)

I might just be misremembering things, because https://github.com/walmartlabs/clojure-game-geek/blob/master/src/clojure_game_geek/schema.clj definitely does blocking (db io) in resolvers

But if blocking operations are intended to be allowed in resolvers, using a bounded threadpool seems pretty mixed up

(we are way behind on our lacinia version at work)

We just got around to go to async interceptors; which took a little more effort than predicted 😅 (multiple databases & connections to setup, deadlocks to prevent, etc). doing the same for resolvers might prove challenging. Although the unbounded threadpool served us well in the past