Quantcast

JCS: Possible bug or simple misconfiguration

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JCS: Possible bug or simple misconfiguration

Tom Schroeder
I was hoping to get some advice on whether my issue is a simple
misconfiguration or if it represents a bug in the JCS code.

On my latest project, we have a system that is using JCS for content
caching.  We have implemented it with the following properties file
(cache.ccf):

##############################################################
##### Default Region Configuration
jcs.default=DC
jcs.default.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=100
jcs.default.cacheattributes.UseDisk=true
jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
jcs.default.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache

##############################################################
##### CACHE REGIONS
# Keep staged images around for 30 minutes
jcs.region.stagedImages=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.region.stagedImages.elementattributes.IsEternal=false
jcs.region.stagedImages.elementattributes.MaxLife=1800

# Keep staged content around for 30 minutes
jcs.region.stagedContent=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.region.stagedContent.elementattributes.IsEternal=false
jcs.region.stagedContent.elementattributes.MaxLife=1800

##############################################################
##### AUXILIARY CACHES
# Indexed Disk Cache
jcs.auxiliary.DC=org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC.attributes=org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC.attributes.DiskPath=${dataDirectory}/indexed-disk-cache
jcs.auxiliary.DC.attributes.MaxPurgatorySize=10000
jcs.auxiliary.DC.attributes.MaxKeySize=10000
jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=300000
jcs.auxiliary.DC.attributes.OptimizeOnShutdown=true
jcs.auxiliary.DC.attributes.MaxRecycleBinSize=7500


This configuration seemed to work as expected in the 2.0-beta-1 JCS
version.  However we started to see the following error in our builds:

java.io.IOException: Mismatched memory and disk length (2781042) for [DED:
 pos = 5786 len = 2889]
        at org.apache.commons.jcs.auxiliary.disk.indexed.
IndexedDisk.move(IndexedDisk.java:138)
        at org.apache.commons.jcs.auxiliary.disk.indexed.
IndexedDiskCache.defragFile(IndexedDiskCache.java:1337)
        at org.apache.commons.jcs.auxiliary.disk.indexed.
IndexedDiskCache.optimizeFile(IndexedDiskCache.java:1261)
        at org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.
disposeInternal(IndexedDiskCache.java:1109)
        at org.apache.commons.jcs.auxiliary.disk.indexed.
IndexedDiskCache$1.run(IndexedDiskCache.java:1055)
        at java.lang.Thread.run(Thread.java:745)

Thinking that this was related to the following JIRA issue:
<a href="https://issues.apache.org/jira/browse/JCS-146?jql=text%">https://issues.apache.org/jira/browse/JCS-146?jql=text%
20~%20%22Mismatched%20memory%20and%20disk%20length%22, we upgraded our
version to 2.0-beta-2 and then to 2.0.  The upgrade eliminated the build
error, but it seems now that we have an issue with our MaxLife property on
our stagedContent region.  It appears that after the system has been up for
longer than the MaxLife number of seconds (1800 seconds, or 30 minutes),
the entire cache stops returning data.  Any content staged to the cache can
no longer be retrieved with the CacheAccess.get(id) method (returns null).
We have to bounce the system to get the cache working again.  We reverted
to the 2.0-beta-1 version and the cache is now remaining operational beyond
the MaxLife time, but we would like to be able to upgrade to the latest
version.  Have we missed something obvious in the configuration here, or is
there something else going on?  Any ideas would be greatly appreciated.
Thank you very much.

-Tom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JCS: Possible bug or simple misconfiguration

Thomas Vandahl
On 10.01.17 18:08, Tom Schroeder wrote:
> jcs.auxiliary.DC.attributes.MaxRecycleBinSize=7500

This setting does no longer exist. Please remove it. It has nothing to
do with your problem, however.

> Thinking that this was related to the following JIRA issue:
> <a href="https://issues.apache.org/jira/browse/JCS-146?jql=text%">https://issues.apache.org/jira/browse/JCS-146?jql=text%
> 20~%20%22Mismatched%20memory%20and%20disk%20length%22, we upgraded our
> version to 2.0-beta-2 and then to 2.0.  The upgrade eliminated the build
> error, but it seems now that we have an issue with our MaxLife property on
> our stagedContent region.  It appears that after the system has been up for
> longer than the MaxLife number of seconds (1800 seconds, or 30 minutes),
> the entire cache stops returning data.  Any content staged to the cache can
> no longer be retrieved with the CacheAccess.get(id) method (returns null).
> We have to bounce the system to get the cache working again.  We reverted
> to the 2.0-beta-1 version and the cache is now remaining operational beyond
> the MaxLife time, but we would like to be able to upgrade to the latest
> version.  Have we missed something obvious in the configuration here, or is
> there something else going on?  Any ideas would be greatly appreciated.

Could you please try to add the following to your configuration and see
if it changes anything?

--8<--
jcs.auxiliary.DC.attributes.EventQueueType=POOLED
jcs.auxiliary.DC.attributes.EventQueuePoolName=disk_cache_event_queue

##############################################################
################## OPTIONAL THREAD POOL CONFIGURATION ########

# Disk Cache Event Queue Pool
thread_pool.disk_cache_event_queue.useBoundary=false
thread_pool.disk_cache_event_queue.maximumPoolSize=15
thread_pool.disk_cache_event_queue.minimumPoolSize=1
thread_pool.disk_cache_event_queue.keepAliveTime=3500
thread_pool.disk_cache_event_queue.startUpSize=1
 --8<--

Bye, Thomas




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JCS: Possible bug or simple misconfiguration

Tom Schroeder
Thanks for taking a look, Thomas.  I added your extra configuration params
(and removed the one that no longer exists).  But I'm still having the same
problem.  I have the MaxLife set down to 120 seconds so that I can get the
system to fail quickly for testing.  I can get stuff into and out of the
cache for the first couple of minutes.  But once the system has been up for
longer than 120 seconds, I cannot retrieve anything I put in the
stagedContent cache.

I've made a couple of changes to the config since my first post, because I
think we may have had some bad configs in there before.  This is the
current config we are using (including your additional parameters):

##############################################################
##### Default Region Configuration
jcs.default=DC
jcs.default.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=100
jcs.default.cacheattributes.UseDisk=true
jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
jcs.default.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache

##############################################################
##### CACHE REGIONS
# Keep staged content around for 30 minutes
jcs.region.stagedContent=DC
jcs.region.stagedContent.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
jcs.region.stagedContent.elementattributes.IsEternal=false
jcs.region.stagedContent.elementattributes.MaxLife=120

##############################################################
##### AUXILIARY CACHES
# Indexed Disk Cache
jcs.auxiliary.DC=org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC.attributes=org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC.attributes.DiskPath=${dataDirectory}/indexed-disk-cache
jcs.auxiliary.DC.attributes.MaxPurgatorySize=10000
jcs.auxiliary.DC.attributes.MaxKeySize=10000
jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=300000
jcs.auxiliary.DC.attributes.OptimizeOnShutdown=true

jcs.auxiliary.DC.attributes.EventQueueType=POOLED
jcs.auxiliary.DC.attributes.EventQueuePoolName=disk_cache_event_queue

##############################################################
################## OPTIONAL THREAD POOL CONFIGURATION ########

# Disk Cache Event Queue Pool
thread_pool.disk_cache_event_queue.useBoundary=false
thread_pool.disk_cache_event_queue.maximumPoolSize=15
thread_pool.disk_cache_event_queue.minimumPoolSize=1
thread_pool.disk_cache_event_queue.keepAliveTime=3500
thread_pool.disk_cache_event_queue.startUpSize=1


Any ideas on what's going wrong?  Thanks.

Tom



On Thu, Jan 12, 2017 at 1:13 PM, Thomas Vandahl <[hidden email]> wrote:

> On 10.01.17 18:08, Tom Schroeder wrote:
> > jcs.auxiliary.DC.attributes.MaxRecycleBinSize=7500
>
> This setting does no longer exist. Please remove it. It has nothing to
> do with your problem, however.
>
> > Thinking that this was related to the following JIRA issue:
> > <a href="https://issues.apache.org/jira/browse/JCS-146?jql=text%">https://issues.apache.org/jira/browse/JCS-146?jql=text%
> > 20~%20%22Mismatched%20memory%20and%20disk%20length%22, we upgraded our
> > version to 2.0-beta-2 and then to 2.0.  The upgrade eliminated the build
> > error, but it seems now that we have an issue with our MaxLife property
> on
> > our stagedContent region.  It appears that after the system has been up
> for
> > longer than the MaxLife number of seconds (1800 seconds, or 30 minutes),
> > the entire cache stops returning data.  Any content staged to the cache
> can
> > no longer be retrieved with the CacheAccess.get(id) method (returns
> null).
> > We have to bounce the system to get the cache working again.  We reverted
> > to the 2.0-beta-1 version and the cache is now remaining operational
> beyond
> > the MaxLife time, but we would like to be able to upgrade to the latest
> > version.  Have we missed something obvious in the configuration here, or
> is
> > there something else going on?  Any ideas would be greatly appreciated.
>
> Could you please try to add the following to your configuration and see
> if it changes anything?
>
> --8<--
> jcs.auxiliary.DC.attributes.EventQueueType=POOLED
> jcs.auxiliary.DC.attributes.EventQueuePoolName=disk_cache_event_queue
>
> ##############################################################
> ################## OPTIONAL THREAD POOL CONFIGURATION ########
>
> # Disk Cache Event Queue Pool
> thread_pool.disk_cache_event_queue.useBoundary=false
> thread_pool.disk_cache_event_queue.maximumPoolSize=15
> thread_pool.disk_cache_event_queue.minimumPoolSize=1
> thread_pool.disk_cache_event_queue.keepAliveTime=3500
> thread_pool.disk_cache_event_queue.startUpSize=1
>  --8<--
>
> Bye, Thomas
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JCS: Possible bug or simple misconfiguration

Thomas Vandahl
On 12.01.17 19:38, Tom Schroeder wrote:
> Thanks for taking a look, Thomas.  I added your extra configuration params
> (and removed the one that no longer exists).  But I'm still having the same
> problem.  I have the MaxLife set down to 120 seconds so that I can get the
> system to fail quickly for testing.  I can get stuff into and out of the
> cache for the first couple of minutes.  But once the system has been up for
> longer than 120 seconds, I cannot retrieve anything I put in the
> stagedContent cache.

Please open a ticket in JIRA. If possible, please provide some
stripped-down test code to recreate the issue.

Bye, Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...