[ https://issues.jboss.org/browse/ISPN-9722?page=com.atlassian.jira.plugin.... ] Will Burns commented on ISPN-9722: ---------------------------------- {quote} At some point we'll run out of memory and we'll stall waiting for the GC, so I still don't think we can guarantee we'll never block unless we have some other backpressure mechanism that prevents new cache invocations from running on the CPU thread pool even when the CPU thread pool is free. {quote} We actually have this already today, since we offload the server requests to a different thread pool. In this case it is based on how large of a queue we have configured. It appears that we enqueue everything in HR https://github.com/infinispan/infinispan/blob/master/server/core/src/main... But I should clarify I meant to say under normal operation we should never have to worry about caller runs policy. The queue should be quite large to prevent having to run in caller runs policy, but not too large to cause OOM. Originally we had some of the queue sizes as 100K elements, which seems reasonable to me for a blocking thread pool queue. But this can be discussed as needed. One thing to note is the hope is that we would have just a CPU thread pool, blocking op thread pool and scheduled thread pool. So there would only need to be 3 queues which would help in sizing those properly as well. Then we can also use `LimitedExecutor` on top of these to guarantee FIFO or limit thread usage for given tasks as needed (which also has its own individual queues). {quote} Sorry I wasn't clear, I meant stores with write-behind enabled, which are wrapped in an AsyncCacheWriter. I understand that you would like the caller to never block, but I don't think we can guarantee that with the current SPI and without implementing backpressure first. {quote} This is a stop gap until the SPI is changed, I agree, in which case we shouldn't need to use a thread, but this is a simple step to getting to where we need to be. In regards to backpressure, we have CallerRunsPolicy as you mentioned and should be sufficient for the cases when we are absolutely swamped by a ton of async calls. -- This message was sent by Atlassian Jira (v7.12.1#712002)