[
https://issues.jboss.org/browse/ISPN-9722?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-9722:
------------------------------------
We shouldn't ever be hitting the CallerRunsPolicy. The thread
pool should have a large amount of threads and a large queue. We don't ever want to
run this on the soon to be very precious CPU threads.
For all we know, the application could be doing {{while (true)
cache.putAsync(Random.nextInt(), "value")}}.
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.
Adding support for actual asynchronous stores is a different PR after
this.
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.
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)