[
https://issues.apache.org/jira/browse/JCS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823306#comment-15823306
]
Wiktor N commented on JCS-171:
------------------------------
Not much I guess. It only guarantees, that log messages will be generated, when
someone setWorking / setAlive sets to false.
But actually, right now there is no class caring about this state. So this can
be further simplified and and setWorking / setAlive logic removed.
The only case, when it might make sense, is when working with remote caches -
if for some reason thread doing synchronization does not reconnect when
connection is dropped, then restarting the thread might help a lot, but
actually - it looks like these connections are managed somewhere else and
anyhow - thread restart would not help it.
> 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)
