commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wiktor N (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCS-171) Multiple CacheEventQueue.QProcessor spawned for the same cache region
Date Tue, 10 Jan 2017 08:57:58 GMT

    [ 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)

Mime
View raw message