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 Mon, 09 Jan 2017 22:57:58 GMT

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

Mime
View raw message