[
https://issues.apache.org/jira/browse/JCS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15813128#comment-15813128
]
Wiktor N commented on JCS-171:
------------------------------
Thanks.
I was surprised by this idea too. I prefer more stable solution with pooled
threads. I guess that this might be the safe default as it should be easier to
get right.
There two things worth considering:
1. As it might be the case, that disk I/O saturates the thread and more threads
will not result in more throughput, this might not be the case for remote
caches (where network latency might kill the throughput). Not sure if this is
the case as I'm not use remote caches
2. As I've learned recently, Java ThreadPoolExecutor behaves far from
expectations that I had, as it spawns new threads only when workQueue refuses
to take next task. In JCS we have following defaults:
corePoolSize = 4
maxPoolSize =150
workQueueSize = 2000
It means, that we have to have 2000 events in the queue before next task will
spawn a fifth thread to try to handle with the tasks. It means also, that if
someone's configure workQueueSize as unlimited - then he will be left with only
4 workers, no matter the load. We should probably disallow such configurations.
And as I understand, we do not care much about loosing some of the tasks handed
to ThreadPoolExecutor as it means, that we might just not put into the cache
some of the cache elements. Which might sound good in case of overload
So to sum up - yes - I think that pooled implementation is a good default.
> 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)
