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 Wed, 18 Jan 2017 18:39:26 GMT

    [ https://issues.apache.org/jira/browse/JCS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828534#comment-15828534
] 

Wiktor N commented on JCS-171:
------------------------------

In both cases you have 8 threads processing cache events. In thread pool mode any thread may
get event for any cache region (and file). So you can have a situation, that you have two
threads trying to process event for one cache. Because of the locking in *DiskCache, you can
have only one writing thread. So the other waits.

In single queue, the processing thread process the events only for it's own cache. So there
is no lock contention and basically, only cache reads may block it from writing the cache.

As for why you get OOM in threaded mode - the only guess I have, is that single mode process
events so fast, that the queue doesn't grow that much, thus you don't get OOM's. It's interesting,
what is the High Water Mark on the queue in the single mode, and then - check - how many events
would be dropped, with such boundarySize of thread queue.



> 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, jcs-perf-test.zip
>
>
> 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