Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 18 Jan 2017 18:39:26 +0000 (UTC)
From: "Wiktor N (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13032743.1483750811000.43497.1484764766390@Atlassian.JIRA>
In-Reply-To: <JIRA.13032743.1483750811000@Atlassian.JIRA>
References: <JIRA.13032743.1483750811000@Atlassian.JIRA> <JIRA.13032743.1483750811770@jira-lw-us.apache.org>
Subject: [jira] [Commented] (JCS-171) Multiple CacheEventQueue.QProcessor
 spawned for the same cache region
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 18 Jan 2017 18:39:33 -0000


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