[
https://issues.apache.org/jira/browse/JCS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814387#comment-15814387
]
Wiktor N commented on JCS-171:
------------------------------
After a night I have further thoughts about this.
I assume, that most of the work done by CacheEventQueues is writing/removing
from the cache. So for IndexedDiskCache and BlockDiskCache - writeLock will
anyway allow at most one thread to do the job.
If it's true, then switching default to pooled implementation may have
significant performance implications:
1. In case when we have cache region A and cache region B - thread might wait
to acquire the writeLock on cache A instead of doing job in region B.
2. This should be especially visible, when there are more regions configured
than minimum threads given the ThreadPoolExecutor behaviour
But I need to do some performance tests to back up my theory.
Alternative approach to this might be, that instead of CacheEventQueue /
QProcessor pair:
1. Use Pooled implementation, but for separate pool for each cache region
2. Configure the pool as minimumThread = 0, maximumThreads = 1
ThreadPoolExecutor will then give exactly the same behaviour as we have for
SINGLE (kill the thread if there is no work to be done, spawn the thread when
something arrives to the queue), but we will just relay on correctness of
ThreadPoolExecutor instead of rolling our own implementation.
> Multiple CacheEventQueue.QProcessor spawned for the same cache region
> ---------------------------------------------------------------------
>
> Key: JCS-171
> URL: https://issues.apache.org/jira/browse/JCS-171
> Project: Commons JCS
> Issue Type: Bug
> Components: Composite Cache
> Affects Versions: jcs-2.0
> Reporter: Wiktor N
> Assignee: Thomas Vandahl
> Fix For: jcs-2.1
>
> Attachments: CacheEventQueue.patch
>
>
> I noticed that running on new version of JCS I get multiple
> CacheEventQueue.QProcessor thread. They spawn from time to time.
> I've checked recent changes and changes few things in r1774925 look
> suspicious:
> 1. In previous code we spawned a new thread in synchronized section. This got
> us a guarantee, that there will be no two threads trying to spawn a new
> thread in the same time. Maybe some locking is needed around thread creation?
> 2. QProcessor uses isAlive() method. But this is defined by Thread.isAlive()
> while it should probably check for CacheEventQueue.this.isAlive()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
