My current hypothesis is that you get into a deadlock by exhausting your thread-pool:
- You create a thread per outer http/get
- If you create less requests than available threads in the thread pool, there is room to service at least one inner
http/get
(which will require a new thread)
- Or if your first request is completed before you exhaust the thread-pool
- Once there are no more threads in the thread-pool, the inner
http/get
cannot
be serviced
- Since the inner request cannot be completed, the outers are stuck forever
You can check the status of the thread-pool http-kit uses peeking http/default-pool
. There you can see things like:
#object[java.util.concurrent.ThreadPoolExecutor 0x5a99e5c "java.util.concurrent.ThreadPoolExecutor@5a99e5c[Running, pool size = 8, active threads = 0, queued tasks = 0, completed tasks = 24]"]
when you did not get into the deadlock. Or
#object[java.util.concurrent.ThreadPoolExecutor 0x5a99e5c "java.util.concurrent.ThreadPoolExecutor@5a99e5c[Running, pool size = 8, active threads = 8, queued tasks = 8, completed tasks = 28]"]
when you did.
I have tested this in my machine (shows 8 as (.availableProcessors (Runtime/getRuntime))
) and I got the results above. I walked into a deadlock when I run more than 8 requests.
Regards