[
https://issues.apache.org/jira/browse/JCS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13563579#comment-13563579
]
Thomas Vandahl commented on JCS-101:
------------------------------------
Well, as the code has been working for almost two years and the compiled
classes usually have no tendency to modify themselves, I guess something else
changed in your environment.
You could try to use the current trunk on a test or staging system to see if
things improve.
> Basic cache functions (store/delete) not occurring consistently
> ---------------------------------------------------------------
>
> Key: JCS-101
> URL: https://issues.apache.org/jira/browse/JCS-101
> Project: Commons JCS
> Issue Type: Question
> Components: Composite Cache
> Affects Versions: jcs-1.3
> Environment: Linux, running on VM
> Reporter: Mike Ellis
> Priority: Minor
>
> Our process had been deployed and running since December 2010 with no
> problems but two weeks ago we started seeing that updates were not working
> consistently, but we were not getting errors indicating any problems. We are
> using version 1.3
> Our setup specifies a primary and failover linux server - see cache.ccf snip
> below - but we see the error even when just one server is active. Separate
> domain restarts (we use VMs) did not resolve the issue. A simultaneous
> restart appeared to work (existing records gone, updates happened) but the
> problem reoccurred within hours.
> Commands like clear and dispose also failed to work. Normal
> ShrinkerThread tasks were running as expected.
> Our tech support are checking that the VM environment is working correctly,
> but is there a reason why store/delete/clear/dispose would not work and would
> not display an error?
> Also, is there a way to retrieve all existing keys from a region at runtime,
> rather than setting up a group and using putInGroup(...) as records are
> created? The aim is to retrieve the keys from every record in a specified
> region without changing code to specify/use groups.
> #XpressClientAuthCache
> #---------------------
> jcs.region.XpressClientAuthCache=RC
> jcs.region.XpressClientAuthCache.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.region.XpressClientAuthCache.cacheattributes.MaxObjects=10000
> jcs.region.XpressClientAuthCache.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
> jcs.region.XpressClientAuthCache.cacheattributes.UseMemoryShrinker=true
> jcs.region.XpressClientAuthCache.cacheattributes.MaxMemoryIdleTimeSeconds=180
> jcs.region.XpressClientAuthCache.cacheattributes.ShrinkerIntervalSeconds=60
> jcs.region.XpressClientAuthCache.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.region.XpressClientAuthCache.elementattributes.IsEternal=false
> jcs.region.XpressClientAuthCache.elementattributes.MaxLifeSeconds=86400
> jcs.region.XpressClientAuthCache.elementattributes.IdleTime=3600
> jcs.region.XpressClientAuthCache.elementattributes.IsSpool=true
> jcs.region.XpressClientAuthCache.elementattributes.IsRemote=true
> jcs.region.XpressClientAuthCache.elementattributes.IsLateral=true
> jcs.auxiliary.RC=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
> jcs.auxiliary.RC.attributes=org.apache.jcs.auxiliary.remote.RemoteCacheAttributes
> jcs.auxiliary.RC.attributes.FailoverServers=eaicch-adp-0pp:1102,eaicch-adp-0pk:1102
> jcs.auxiliary.RC.attributes.RemoveUponRemotePut=false
> jcs.auxiliary.RC.attributes.RmiSocketFactoryTimeoutMillis=5000
> jcs.auxiliary.RC.attributes.GetOnly=false
> jcs.auxiliary.RC.attributes.Receive=true
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
