[
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.
Perform all CacheStore operations on a separate thread
------------------------------------------------------
Key: ISPN-9722
URL:
https://issues.jboss.org/browse/ISPN-9722
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Reporter: Will Burns
Assignee: Will Burns
Priority: Major
Fix For: 10.0.0.Beta4, 10.0.0.Final
Persistence is one of the few remaining systems that are not non blocking. This needs to
be remedied. We will eventually need to add an SPI that does this, but for now we need to
offload the persistence operations to a different thread pool.
This should only require changes in the PersistenceManager to return non blocking methods
(ie. return CompletionStage). We should then update references to use non blocking when
possible.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)