[ANNOUNCE] Apache Commons JCS 3.2.1

[Thomas Vandahl]

The Apache Commons JCS team is pleased to announce the release of
Apache Commons JCS 3.2.1.

Apache Commons JCS is a distributed caching system written in Java. 
It is intended to speed up applications by providing means to 
manage cached data of various dynamic natures.

This is a maintenance and bug fix release (Java 8 or above).

For complete information on Apache Commons JCS, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons JCS website:

https://commons.apache.org/proper/commons-jcs/

Download page: https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

Historical list of changes:
https://commons.apache.org/proper/commons-jcs/changes-report.html

Enjoy!
Thomas Vandahl 
-Apache Commons JCS team


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[JCS] Remote cache not updated and not broadcasting removes from clients

[Greg Parmiter]

Hi, we're experiencing some difficulty getting JCS (3.2) remote RMI cache to 
work properly. I'm having trouble finding a full working example of the remote 
RMI cache setup. I'd appreciate it if someone could point me in the right 
direction. Thank you! -Greg


  1.  Our clients are initiating 2 PUTs in quick succession. The server 
recognizes both, but only stores the first. I'm seeing the following in the 
remote server log, for the second PUT (note the "remove node" statement which 
does not occur during the first PUT)-

DEBUG | [RMI TCP Connection(138)-192.168.2.100] log.Log4j2LogAdapter 
(Log4j2LogAdapter.java:57) - In update, put [key1] in [cache2]

DEBUG | [RMI TCP Connection(138)-192.168.2.100] log.Log4j2LogAdapter 
(Log4j2LogAdapter.java:112) - In update, requesterId = [7] fromCluster = false

DEBUG | [RMI TCP Connection(138)-192.168.2.100] log.Log4j2LogAdapter 
(Log4j2LogAdapter.java:112) - Put NOT from cluster, updating other auxiliaries 
for region.  requesterId [7]

DEBUG | [RMI TCP Connection(138)-192.168.2.100] log.Log4j2LogAdapter 
(Log4j2LogAdapter.java:55) - Updating memory cache key1

DEBUG | [RMI TCP Connection(138)-192.168.2.100] log.Log4j2LogAdapter 
(Log4j2LogAdapter.java:89) - removing node

  1.  When a client initiates a REMOVE, the remote server recognizes and 
removes its own inmem entry, but that event does not appear to be broadcast to 
the OTHER clients. This results in the other clients being out of sync with the 
remote server.

Setup/Config details-
The cache server is running within the same app server (Wildfly) as the 
clients. There are 2 cache regions configured in the clients.

In our code, we're using CacheAccess, where CustomValue 
class is fully serializable.

The client config is as follows-
# # CLIENT CONFIG  #
jcs.default=RC
jcs.default.cacheattributes=org.apache.commons.jcs3.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=1000
jcs.default.cacheattributes.MemoryCacheName=org.apache.commons.jcs3.engine.memory.lru.LRUMemoryCache
jcs.default.cacheattributes.UseMemoryShrinker=true
jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
jcs.default.elementattributes=org.apache.commons.jcs3.engine.ElementAttributes
jcs.default.elementattributes.IsEternal=false
jcs.default.elementattributes.MaxLife=700
jcs.default.elementattributes.IdleTime=1800
jcs.default.elementattributes.IsSpool=true
jcs.default.elementattributes.IsRemote=true
jcs.default.elementattributes.IsLateral=true

jcs.region.cache1=RC
jcs.region.cache2=RC

jcs.auxiliary.RC=org.apache.commons.jcs3.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.RC.attributes=org.apache.commons.jcs3.auxiliary.remote.RemoteCacheAttributes
jcs.auxiliary.RC.attributes.FailoverServers=localhost:1101
jcs.auxiliary.RC.attributes.LocalPort=1102
jcs.auxiliary.RC.attributes.RemoveUponRemotePut=false
jcs.auxiliary.RC.attributes.GetTimeoutMillis=-1
jcs.auxiliary.RC.attributes.GetOnly=false
jcs.auxillary.RC.cacheeventlogger=org.apache.commons.jcs3.engine.logging.CacheEventLoggerDebugLogger
jcs.auxillary.RC.cacheeventlogger.attributes.logCategoryName=RCEventLogCategory

The remote server config is as follows-
# # REMOTE SERVER CONFIG  #
# Registry used to register and provide the IRmiCacheService service.
registry.host=localhost
registry.port=1101
# call back port to local caches.
jcs.remotecache.serverattributes.servicePort=1102
# cluster setting
jcs.remotecache.serverattributes.LocalClusterConsistency=true
jcs.remotecache.serverattributes.RemoveUponRemotePut=false
jcs.remotecache.cacheeventlogger=org.apache.commons.jcs3.engine.logging.CacheEventLoggerDebugLogger
jcs.remotecache.cacheeventlogger.attributes.logCategoryName=RCEventLogCategory

# #
# # DEFAULT CACHE REGION  #
# sets the default aux value for any non configured caches
jcs.default=
jcs.default.cacheattributes=org.apache.commons.jcs3.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=20
jcs.default.cacheattributes.MemoryCacheName=org.apache.commons.jcs3.engine.memory.lru.LRUMemoryCache
jcs.default.cacheattributes.UseMemoryShrinker=true
jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
jcs.default.elementattributes=org.apache.commons.jcs3.engine.ElementAttributes
jcs.default.elementattributes.IsEternal=false
jcs.default.elementattributes.MaxLife=7000
jcs.default.elementattributes.IdleTime=1800
jcs.default.elementattributes.IsSpool=true
jcs.default.elementattributes.IsRemote=true
jcs.default.elementattributes.IsLateral=true

jcs.region.cache1=
jcs.region.cache2=

[ANNOUNCEMENT] Apache Commons JCS 3.2 Released

[Thomas Vandahl]

The Apache Commons JCS team is pleased to announce the Apache Commons JCS 3.2 
release!

Apache Commons JCS is a distributed, versatile caching system.

Changes in this version include:

Fixed Bugs:
o Fix OSGi manifest  Issue: JCS-234. Thanks to Chris Lake. 
o Handle ServiceConfigurationError when using a different logging framework  
Issue: JCS-232. Thanks to Jeremy Long. 
o Fix Lateral TCP cache recovery loop for empty TCP servers  Issue: JCS-231. 
Thanks to Andrea Vettori. 
o UDPDiscoveryReceiver with EncryptingSerializer fails #88.  Issue: JCS-230. 
Thanks to Dorota Oeknigk-Urbanska. 
o LateralTCPListener class uses always StandardSerializer #89.  Issue: JCS-229. 
Thanks to Dorota Oeknigk-Urbanska. 

Changes:
o Bump actions/cache from 2.1.7 to 3.0.9 #86, #111. Thanks to Dependabot, Gary 
Gregory. 
o Bump actions/checkout from 2 to 3.0.2 #93. Thanks to Dependabot, Gary 
Gregory. 
o Bump actions/setup-java from 2 to 3.5.1. Thanks to Gary Gregory. 
o Bump commons-parent from 52 to 58 #90, #130, #154. Thanks to Dependabot. 
o Bump log4j-api from 2.17.1 to 2.20.0 #85, #100, #107, #145. Thanks to 
Dependabot. 
o Bump log4j-core from 2.17.1 to 2.20.0 #87, #99, #108, #144. Thanks to 
Dependabot. 
o Bump commons-text from 1.9 to 1.10.0 #110. Thanks to Dependabot. 
o Bump commons-io from 2.11.0 to 2.12.0. Thanks to Gary Gregory. 

For complete information on Apache Commons JCS, including instructions on how 
to submit bug reports, patches, or suggestions for improvement, see the Apache 
Commons JCS website:

https://commons.apache.org/proper/commons-jcs/

Download it from
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

Thomas Vandahl 
Apache Commons Team

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCE] Apache Commons JCS 3.1

[Thomas Vandahl]

The Apache Commons project announces the release of Apache Commons JCS 3.1.

Apache Commons JCS is a distributed caching system written in Java. It is 
intended to speed up 
applications by providing a means to manage cached data of various dynamic 
natures.

JCS 3.0 and onwards require at least Java 8.

JCS 3.1 uses log4j as an optional component only. Nevertheless, the dependency 
has been updated to address the Log4Shell issues.

This is a feature and bug fix release.

For a list of changes in this release see:
https://commons.apache.org/proper/commons-jcs/changes-report.html#a3.1

For complete information on Apache Commons JCS, including instructions on
how to submit bug reports, patches, or suggestions for improvement, see the
Apache Apache Commons JCS website:
https://commons.apache.org/proper/commons-jcs/

Download page:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

Have fun!


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Invalid Class Exception help needed

[Thomas Vandahl]

Hi Stuart,

On 22.01.21 08:26, Stuart Maclean wrote:
I have a cache region whose key type is say String and whose value type 
is some class C.  C is Serializable.


I use the cache, so objects of class C go into that region. The cache is 
backed by disk, so objects of class C end up in files.


C may then change, such that its serialVersionUID changes. If so, what I 
want to happen is that when I do a


I guess what you are looking for happens in e.g. 
org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.readElement(K)


In this method, the ClassNotFoundException from deserialization is 
wrapped into an IOException. This exception is then caught by 
org.apache.commons.jcs.auxiliary.disk.indexed.IndexedDiskCache.processGet(K) 



In the catch clause, reset() is called, which clears the cache. So 
actually the behavior you are asking for actually should be there.


If you need more detailed control, you may provide your own 
org.apache.commons.jcs.engine.behavior.IElementSerializer and use the 
object validation features described in 
java.io.ObjectInputStream.registerValidation(ObjectInputValidation, int)


You will have to create the disk cache programmatically then, as the 
IElementSerializer cannot be set via configuration.


HTH
Bye, Thomas

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Invalid Class Exception help needed

[Mat Jaggard]

Hi, thanks for your question. I'm not a JCS expert by any means so I'm not
sure the answer to your question but I do have a question myself. What's
the reason for wanting to clear the cache in these cases rather than just
getting no result back so that you just refresh that value?

On Fri, 22 Jan 2021, 07:26 Stuart Maclean,  wrote:

> I am using JCS 2.2. I am an infrequent user of JCS, so please bear with
> me.  I have checked the mail list archives for past few years, couldn't
> find any answers to this q...
>
> I have a cache region whose key type is say String and whose value type
> is some class C.  C is Serializable.
>
> I use the cache, so objects of class C go into that region. The cache is
> backed by disk, so objects of class C end up in files.
>
> C may then change, such that its serialVersionUID changes. If so, what I
> want to happen is that when I do a
>
> C c = cache.get( "K" );
>
> I would like to see the InvalidClassException, so that I can call
>
> cache.clear()
>
> and start over with the 'new' C objects.
>
> But cache.get() doesn't throw such an error.  I always get a null result
> back, which means I can't distinguish this type of error from a simple
> cache miss (key not present), so I can't call the cache.clear().
>
> Somewhere in the call stack, JCS is catching the error so that it
> doesn't propogate to user code?
>
> Are there any api calls I can make to set the cache up so that it is
> cleared on this type of error?
>
> Thanks
>
> Stu
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

[jcs] Invalid Class Exception help needed

[Stuart Maclean]

I am using JCS 2.2. I am an infrequent user of JCS, so please bear with 
me.  I have checked the mail list archives for past few years, couldn't 
find any answers to this q...


I have a cache region whose key type is say String and whose value type 
is some class C.  C is Serializable.


I use the cache, so objects of class C go into that region. The cache is 
backed by disk, so objects of class C end up in files.


C may then change, such that its serialVersionUID changes. If so, what I 
want to happen is that when I do a


C c = cache.get( "K" );

I would like to see the InvalidClassException, so that I can call

cache.clear()

and start over with the 'new' C objects.

But cache.get() doesn't throw such an error.  I always get a null result 
back, which means I can't distinguish this type of error from a simple 
cache miss (key not present), so I can't call the cache.clear().


Somewhere in the call stack, JCS is catching the error so that it 
doesn't propogate to user code?


Are there any api calls I can make to set the cache up so that it is 
cleared on this type of error?


Thanks

Stu


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Maven - Commons JCS 3

[Thomas Vandahl]

On 30.10.20 21:57, tolai...@ups.com.INVALID wrote:

Is the Commons JCS 3 library going to be published to Maven?


What is wrong with 
https://repo1.maven.org/maven2/org/apache/commons/commons-jcs3-core/3.0/commons-jcs3-core-3.0.jar 
?


Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[jcs] Maven - Commons JCS 3

[tolaiyun]

Is the Commons JCS 3 library going to be published to Maven?

RE: [ANNOUNCE] Apache Commons JCS 3.0 Releasedttk

[Stephan Wahlbrink]

 Ursprüngliche hNachricht Von: Thomas Vandahl  
Datum: 23.08.20  12:11  (GMT+01:00) An: annou...@apache.org, Commons Developers 
List , Commons Users List  
Betreff: [ANNOUNCE] Apache Commons JCS 3.0 Released The Apache Cnommons Team is 
pleased to announce the availability ofApache Commons JCS 3.0Apache Commons JCS 
is a distributed, versatile caching system.This has been a major 
overhaulggOberhauptr of JCS with many adjustments for JDK 8+,better concurrency 
and logging.GdaCommons JCS 3.0 requires Java 8 or later.The release notes can 
be reviewed 
at:http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txtDistribution 
packages can be downloaded 
from:https://commons.apache.Ygiorg/proper/commons-jcs/download_jcs.cgiWhen 
downloading, please verify signatures using the KEYS file availableat: 
http://www.apache.org/dist/commonsMore information and comprehensive 
documentation is available 
at:https://commons.apache.org/proper/commons-jcs/Maven artifacts are also 
available in the central Maven 
repository:http://repo1.maven.org/maven2/org/apache/commons/jcs3The Apache 
Commons Team

RE: [ANNOUNCE] Apache Commons JCS 3.0 Releasedttk

[Stephan Wahlbrink]

 Ursprüngliche hNachricht Von: Thomas Vandahl  
Datum: 23.08.20  12:11  (GMT+01:00) An: annou...@apache.org, Commons Developers 
List , Commons Users List  
Betreff: [ANNOUNCE] Apache Commons JCS 3.0 Released The Apache Cnommons Team is 
pleased to announce the availability ofApache Commons JCS 3.0Apache Commons JCS 
is a distributed, versatile caching system.This has been a major 
overhaulggOberhauptr of JCS with many adjustments for JDK 8+,better concurrency 
and logging.GdaCommons JCS 3.0 requires Java 8 or later.The release notes can 
be reviewed 
at:http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txtDistribution 
packages can be downloaded 
from:https://commons.apache.Ygiorg/proper/commons-jcs/download_jcs.cgiWhen 
downloading, please verify signatures using the KEYS file availableat: 
http://www.apache.org/dist/commonsMore information and comprehensive 
documentation is available 
at:https://commons.apache.org/proper/commons-jcs/Maven artifacts are also 
available in the central Maven 
repository:http://repo1.maven.org/maven2/org/apache/commons/jcs3The Apache 
Commons Team

[ANNOUNCE] Apache Commons JCS 3.0 Released

[Thomas Vandahl]

The Apache Commons Team is pleased to announce the availability of
Apache Commons JCS 3.0

Apache Commons JCS is a distributed, versatile caching system.

This has been a major overhaul of JCS with many adjustments for JDK 8+,
better concurrency and logging.

Commons JCS 3.0 requires Java 8 or later.

The release notes can be reviewed at:
http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt

Distribution packages can be downloaded from:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

When downloading, please verify signatures using the KEYS file available
at: http://www.apache.org/dist/commons

More information and comprehensive documentation is available at:
https://commons.apache.org/proper/commons-jcs/

Maven artifacts are also available in the central Maven repository:
http://repo1.maven.org/maven2/org/apache/commons/jcs3

The Apache Commons Team


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

JCS: AbstractDoubleLinkedListMemoryCache AbstractDoubleLinkedListMemoryCache: update: remove failed for key

[Jean-Marc Spaggiari]

Hi,

I hope it's the right place to ask questions about JCS. I'm getting tons of
this on  my application logs:

19/04/05 14:39:07 WARN memory.AbstractDoubleLinkedListMemoryCache: update:
remove failed for key: [0, 0, 2, 2, 5, 1, 0, 0, 4, 3, 4, 4, 1, 1, 0, 1,
127, 127, 127, 127, 127]

I guess it doesn't hurt, but any idea what it means? I googled it but I
didn't find anything meaningful :(

Thanks,

JMS

[ANNOUNCE] Apache Commons JCS 2.2 Released

[Thomas Vandahl]

The Apache Commons Team is pleased to announce the availability of:

Apache Commons JCS 2.2

Apache Commons JCS is a distributed, versatile caching system.

The release notes can be reviewed at:
http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt

Distribution packages can be downloaded from:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

When downloading, please verify signatures using the KEYS file available
at:
http://www.apache.org/dist/commons

More information and comprehensive documentation is available at:
https://commons.apache.org/proper/commons-jcs/

Maven artifacts are also available in the central Maven repository:
http://repo1.maven.org/maven2/org/apache/commons/

The Apache Commons Team


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: JCS LateralTCPCacheFactory

[Greg Parker]

I reverted the ports back to the way they were and the SEVERE error goes away.  
I also get some lateral caching going on but its very erratic.  In my test, 
server A is the only instance that writes to the cache.

Scenario 1 - success
- Start server A, B, C
- Access server B
- Access server C
- Access server A to put value in cache
- Server B and C display the value put by A

Scenaio 2 - fail
- Start server A, B, C
- Access server A to put value in cache
- console displays connection exceptions
- Access server B
- Access server C
- Access server A to remove then put value to cache
- Server B and C displays null

Scenaio 3 - fail
- Start server A, B, C
- Access server B
- Access server C
- Access server A to put value in cache
- Server B and C display the value put by A
- Restart server B
- Access server A to put value in cache
  - server A displays exception about connection to B
- Server B  displays null


Just wondering if perhaps I have some fundamental misunderstanding about how 
the lateral caching should be working.  I would assume that values written to 
any of the local caches would be pushed into the other two.  When a instance 
restarts it would rejoin the group etc.  Am I missing something?

Thanks


> On Jul 27, 2017, at 12:00 PM, Mat Jaggard <apa...@jaggard.org.uk> wrote:
> 
> Have you tested to see if any of the the TcpListenerPorts are open on your
> server? If you're on Linux you can try `netstat -l`
> 
> On Thu, 27 Jul 2017 at 15:52 Russell Sherk <russell.sh...@roguewave.com>
> wrote:
> 
>> Hi Greg,
>> 
>> Don't know much about JCS. Just general Tomcat stuff.
>> 
>> See if this helps:
>> http://sentineltechsupport.gemalto.com/2013/10/java-runtime-log-error-could-not-instantiate-auxfactory-named-dc/
>> 
>> If not, maybe someone else in the list can help.
>> 
>> Cheers,
>> 
>> --Russ
>> 
>> -Original Message-
>> From: Greg Parker [mailto:gmparker2...@gmail.com]
>> Sent: July-27-17 10:07 AM
>> To: Commons Users List <user@commons.apache.org>
>> Subject: Re: JCS LateralTCPCacheFactory
>> 
>> Thanks Russ,
>> 
>> So the TcpListenerPort value should match the tomcat port?  So if tomcat
>> is running on port 6080 the cache.ccf on that instance should set
>> TcpListenerPort=6080?  I set things up this way and nothing seems to
>> complain; however, now I get a SEVERE error on first access and caching is
>> not working across the three instances.  Here are the details:
>> 
>> SEVERE [ajp-nio-6009-exec-1]
>> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary
>> Could not instantiate auxiliary cache named "hello".
>> 
>> jcs.region.hello=LTCP
>> 
>> jcs.region.hello.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
>> jcs.region.hello.cacheattributes.MaxObjects=1000
>> 
>> jcs.region.hello.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
>> jcs.region.hello.cacheattributes.UseMemoryShrinker=true
>> jcs.region.hello.cacheattributes.MaxMemoryIdleTimeSeconds=3600
>> jcs.region.hello.cacheattributes.ShrinkerIntervalSeconds=60
>> jcs.region.hello.cacheattributes.MaxSpoolPerRun=500
>> 
>> jcs.region.hello.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
>> jcs.region.hello.elementattributes.IsEternal=false
>> 
>> 
>> 
>> jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
>> 
>> jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
>> jcs.auxiliary.LTCP.attributes.AllowGet=true
>> jcs.auxiliary.LTCP.attributes.Receive=true
>> jcs.auxiliary.LTCP.attributes.TcpListenerPort=6080
>> jcs.auxiliary.LTCP.attributes.TcpServers=localhost:7080,localhost:8080
>> 
>> Thanks
>> 
>> 
>> 
>>> On Jul 27, 2017, at 8:57 AM, Russell Sherk <russell.sh...@roguewave.com>
>> wrote:
>>> 
>>> Hi Greg,
>>> 
>>> Tomcat uses two consecutive ports. The one you specify and the next one
>> for shutdown. E.g if you specify 8020, the shutdown port by default is 8021.
>>> 
>>> Try spacing your ports out: 8020, 8022, 8024.
>>> 
>>> --Russ
>>> 
>>> 
>>> On Jul 26, 2017 10:11 PM, Greg Parker <gmparker2...@gmail.com> wrote:
>>> I'm trying to get a sample cluster of tomcat servers (server A, B and C)
>> to use a distributed cache.  The ‘hello’ cache is configured on each server
>> with a different TcpListenerPort on each s

Re: JCS LateralTCPCacheFactory

[Mat Jaggard]

Have you tested to see if any of the the TcpListenerPorts are open on your
server? If you're on Linux you can try `netstat -l`

On Thu, 27 Jul 2017 at 15:52 Russell Sherk <russell.sh...@roguewave.com>
wrote:

> Hi Greg,
>
> Don't know much about JCS. Just general Tomcat stuff.
>
> See if this helps:
> http://sentineltechsupport.gemalto.com/2013/10/java-runtime-log-error-could-not-instantiate-auxfactory-named-dc/
>
> If not, maybe someone else in the list can help.
>
> Cheers,
>
> --Russ
>
> -Original Message-
> From: Greg Parker [mailto:gmparker2...@gmail.com]
> Sent: July-27-17 10:07 AM
> To: Commons Users List <user@commons.apache.org>
> Subject: Re: JCS LateralTCPCacheFactory
>
> Thanks Russ,
>
> So the TcpListenerPort value should match the tomcat port?  So if tomcat
> is running on port 6080 the cache.ccf on that instance should set
> TcpListenerPort=6080?  I set things up this way and nothing seems to
> complain; however, now I get a SEVERE error on first access and caching is
> not working across the three instances.  Here are the details:
>
> SEVERE [ajp-nio-6009-exec-1]
> org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary
> Could not instantiate auxiliary cache named "hello".
>
> jcs.region.hello=LTCP
>
> jcs.region.hello.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
> jcs.region.hello.cacheattributes.MaxObjects=1000
>
> jcs.region.hello.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
> jcs.region.hello.cacheattributes.UseMemoryShrinker=true
> jcs.region.hello.cacheattributes.MaxMemoryIdleTimeSeconds=3600
> jcs.region.hello.cacheattributes.ShrinkerIntervalSeconds=60
> jcs.region.hello.cacheattributes.MaxSpoolPerRun=500
>
> jcs.region.hello.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
> jcs.region.hello.elementattributes.IsEternal=false
>
>
>
> jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
>
> jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
> jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
> jcs.auxiliary.LTCP.attributes.AllowGet=true
> jcs.auxiliary.LTCP.attributes.Receive=true
> jcs.auxiliary.LTCP.attributes.TcpListenerPort=6080
> jcs.auxiliary.LTCP.attributes.TcpServers=localhost:7080,localhost:8080
>
> Thanks
>
>
>
> > On Jul 27, 2017, at 8:57 AM, Russell Sherk <russell.sh...@roguewave.com>
> wrote:
> >
> > Hi Greg,
> >
> > Tomcat uses two consecutive ports. The one you specify and the next one
> for shutdown. E.g if you specify 8020, the shutdown port by default is 8021.
> >
> > Try spacing your ports out: 8020, 8022, 8024.
> >
> > --Russ
> >
> >
> > On Jul 26, 2017 10:11 PM, Greg Parker <gmparker2...@gmail.com> wrote:
> > I'm trying to get a sample cluster of tomcat servers (server A, B and C)
> to use a distributed cache.  The ‘hello’ cache is configured on each server
> with a different TcpListenerPort on each server (8020, 8021, 8022) like
> this:
> >
> > jcs.region.hello=LTCP
> > …
> >
> > jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp
> > .LateralTCPCacheFactory
> > jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral
> > .socket.tcp.TCPLateralCacheAttributes
> > jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
> > jcs.auxiliary.LTCP.attributes.AllowGet=true
> > jcs.auxiliary.LTCP.attributes.Receive=true
> > jcs.auxiliary.LTCP.attributes.TcpListenerPort=8020
> > jcs.auxiliary.LTCP.attributes.TcpServers=localhost:8020,localhost:8021
> > ,localhost:8022
> >
> >
> > Server A has a page that sets a value in the cache like this:
> >
> >cache = JCS.getInstance("hello");
> >cache.put(“message", “Hello from server A");
> >
> >
> > Server B, and C try to get the value without setting it:
> >
> >cache = JCS.getInstance("hello");
> >add(new Label("message", "Server B -> cache has : " +
> > cache.get(“message");));
> >
> >
> > The first time I access the page on server A I get an exception -
> "Cannot connect to localhost:8021”.  If I access the page on each server
> then things appear to start communicating; however, the “message” entry
> from the “hello” region is set on server A and null on B and C.  Sometimes
> I see the value on server C displayed properly but never on server B.
> >
> > With a configuration like th

RE: JCS LateralTCPCacheFactory

[Russell Sherk]

Hi Greg,

Don't know much about JCS. Just general Tomcat stuff. 

See if this helps: 
http://sentineltechsupport.gemalto.com/2013/10/java-runtime-log-error-could-not-instantiate-auxfactory-named-dc/

If not, maybe someone else in the list can help.

Cheers,

--Russ

-Original Message-
From: Greg Parker [mailto:gmparker2...@gmail.com] 
Sent: July-27-17 10:07 AM
To: Commons Users List <user@commons.apache.org>
Subject: Re: JCS LateralTCPCacheFactory

Thanks Russ,

So the TcpListenerPort value should match the tomcat port?  So if tomcat is 
running on port 6080 the cache.ccf on that instance should set 
TcpListenerPort=6080?  I set things up this way and nothing seems to complain; 
however, now I get a SEVERE error on first access and caching is not working 
across the three instances.  Here are the details:

SEVERE [ajp-nio-6009-exec-1] 
org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary 
Could not instantiate auxiliary cache named "hello".

jcs.region.hello=LTCP
jcs.region.hello.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.region.hello.cacheattributes.MaxObjects=1000
jcs.region.hello.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.hello.cacheattributes.UseMemoryShrinker=true
jcs.region.hello.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.region.hello.cacheattributes.ShrinkerIntervalSeconds=60
jcs.region.hello.cacheattributes.MaxSpoolPerRun=500
jcs.region.hello.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
jcs.region.hello.elementattributes.IsEternal=false


jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
jcs.auxiliary.LTCP.attributes.AllowGet=true
jcs.auxiliary.LTCP.attributes.Receive=true
jcs.auxiliary.LTCP.attributes.TcpListenerPort=6080
jcs.auxiliary.LTCP.attributes.TcpServers=localhost:7080,localhost:8080

Thanks



> On Jul 27, 2017, at 8:57 AM, Russell Sherk <russell.sh...@roguewave.com> 
> wrote:
> 
> Hi Greg,
> 
> Tomcat uses two consecutive ports. The one you specify and the next one for 
> shutdown. E.g if you specify 8020, the shutdown port by default is 8021.
> 
> Try spacing your ports out: 8020, 8022, 8024.
> 
> --Russ
> 
> 
> On Jul 26, 2017 10:11 PM, Greg Parker <gmparker2...@gmail.com> wrote:
> I'm trying to get a sample cluster of tomcat servers (server A, B and C) to 
> use a distributed cache.  The ‘hello’ cache is configured on each server with 
> a different TcpListenerPort on each server (8020, 8021, 8022) like this:
> 
> jcs.region.hello=LTCP
> …
> 
> jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp
> .LateralTCPCacheFactory 
> jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral
> .socket.tcp.TCPLateralCacheAttributes
> jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
> jcs.auxiliary.LTCP.attributes.AllowGet=true
> jcs.auxiliary.LTCP.attributes.Receive=true
> jcs.auxiliary.LTCP.attributes.TcpListenerPort=8020
> jcs.auxiliary.LTCP.attributes.TcpServers=localhost:8020,localhost:8021
> ,localhost:8022
> 
> 
> Server A has a page that sets a value in the cache like this:
> 
>cache = JCS.getInstance("hello");
>cache.put(“message", “Hello from server A");
> 
> 
> Server B, and C try to get the value without setting it:
> 
>cache = JCS.getInstance("hello");
>add(new Label("message", "Server B -> cache has : " +  
> cache.get(“message");));
> 
> 
> The first time I access the page on server A I get an exception -  "Cannot 
> connect to localhost:8021”.  If I access the page on each server then things 
> appear to start communicating; however, the “message” entry from the “hello” 
> region is set on server A and null on B and C.  Sometimes I see the value on 
> server C displayed properly but never on server B.
> 
> With a configuration like this should I expect to see values immediately 
> distributed to the other servers?
> 
> Is there a way I should be bootstrapping the cache when the server starts?  
> If the servers need to communicate with one another it would seem to me that 
> they need to be listening long before the first time the server tries to 
> access the cache.
> 
> For performance I would like to use the cache to store serialized XML data 
> instead of storing it in the session or a database.  The data remains in the 
> cache while the user transforms it through several request cycles.  So during 
> a request cycle the XML data would be retrieved, transformed, and stored back 
> in the cache.  In a clustered environment I need the XML data available on 
> every server in the cluster.  Is this an acceptable use case for JCS?
> 
> Thanks
> 
> 
> 
> 

Re: JCS LateralTCPCacheFactory

[Greg Parker]

Thanks Russ,

So the TcpListenerPort value should match the tomcat port?  So if tomcat is 
running on port 6080 the cache.ccf on that instance should set 
TcpListenerPort=6080?  I set things up this way and nothing seems to complain; 
however, now I get a SEVERE error on first access and caching is not working 
across the three instances.  Here are the details:

SEVERE [ajp-nio-6009-exec-1] 
org.apache.commons.jcs.engine.control.CompositeCacheConfigurator.parseAuxiliary 
Could not instantiate auxiliary cache named "hello".

jcs.region.hello=LTCP
jcs.region.hello.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.region.hello.cacheattributes.MaxObjects=1000
jcs.region.hello.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.hello.cacheattributes.UseMemoryShrinker=true
jcs.region.hello.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.region.hello.cacheattributes.ShrinkerIntervalSeconds=60
jcs.region.hello.cacheattributes.MaxSpoolPerRun=500
jcs.region.hello.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
jcs.region.hello.elementattributes.IsEternal=false


jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
jcs.auxiliary.LTCP.attributes.AllowGet=true
jcs.auxiliary.LTCP.attributes.Receive=true
jcs.auxiliary.LTCP.attributes.TcpListenerPort=6080
jcs.auxiliary.LTCP.attributes.TcpServers=localhost:7080,localhost:8080

Thanks



> On Jul 27, 2017, at 8:57 AM, Russell Sherk <russell.sh...@roguewave.com> 
> wrote:
> 
> Hi Greg,
> 
> Tomcat uses two consecutive ports. The one you specify and the next one for 
> shutdown. E.g if you specify 8020, the shutdown port by default is 8021.
> 
> Try spacing your ports out: 8020, 8022, 8024.
> 
> --Russ
> 
> 
> On Jul 26, 2017 10:11 PM, Greg Parker <gmparker2...@gmail.com> wrote:
> I'm trying to get a sample cluster of tomcat servers (server A, B and C) to 
> use a distributed cache.  The ‘hello’ cache is configured on each server with 
> a different TcpListenerPort on each server (8020, 8021, 8022) like this:
> 
> jcs.region.hello=LTCP
> …
> 
> jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
> jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
> jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
> jcs.auxiliary.LTCP.attributes.AllowGet=true
> jcs.auxiliary.LTCP.attributes.Receive=true
> jcs.auxiliary.LTCP.attributes.TcpListenerPort=8020
> jcs.auxiliary.LTCP.attributes.TcpServers=localhost:8020,localhost:8021,localhost:8022
> 
> 
> Server A has a page that sets a value in the cache like this:
> 
>cache = JCS.getInstance("hello");
>cache.put(“message", “Hello from server A");
> 
> 
> Server B, and C try to get the value without setting it:
> 
>cache = JCS.getInstance("hello");
>add(new Label("message", "Server B -> cache has : " +  
> cache.get(“message");));
> 
> 
> The first time I access the page on server A I get an exception -  "Cannot 
> connect to localhost:8021”.  If I access the page on each server then things 
> appear to start communicating; however, the “message” entry from the “hello” 
> region is set on server A and null on B and C.  Sometimes I see the value on 
> server C displayed properly but never on server B.
> 
> With a configuration like this should I expect to see values immediately 
> distributed to the other servers?
> 
> Is there a way I should be bootstrapping the cache when the server starts?  
> If the servers need to communicate with one another it would seem to me that 
> they need to be listening long before the first time the server tries to 
> access the cache.
> 
> For performance I would like to use the cache to store serialized XML data 
> instead of storing it in the session or a database.  The data remains in the 
> cache while the user transforms it through several request cycles.  So during 
> a request cycle the XML data would be retrieved, transformed, and stored back 
> in the cache.  In a clustered environment I need the XML data available on 
> every server in the cluster.  Is this an acceptable use case for JCS?
> 
> Thanks
> 
> 
> 
> 

Re: JCS LateralTCPCacheFactory

[Russell Sherk]

Hi Greg,

Tomcat uses two consecutive ports. The one you specify and the next one for 
shutdown. E.g if you specify 8020, the shutdown port by default is 8021.

Try spacing your ports out: 8020, 8022, 8024.

--Russ


On Jul 26, 2017 10:11 PM, Greg Parker <gmparker2...@gmail.com> wrote:
I'm trying to get a sample cluster of tomcat servers (server A, B and C) to use 
a distributed cache.  The ‘hello’ cache is configured on each server with a 
different TcpListenerPort on each server (8020, 8021, 8022) like this:

jcs.region.hello=LTCP
…

jcs.auxiliary.LTCP=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
jcs.auxiliary.LTCP.attributes=org.apache.commons.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=false
jcs.auxiliary.LTCP.attributes.AllowGet=true
jcs.auxiliary.LTCP.attributes.Receive=true
jcs.auxiliary.LTCP.attributes.TcpListenerPort=8020
jcs.auxiliary.LTCP.attributes.TcpServers=localhost:8020,localhost:8021,localhost:8022


Server A has a page that sets a value in the cache like this:

cache = JCS.getInstance("hello");
cache.put(“message", “Hello from server A");


Server B, and C try to get the value without setting it:

cache = JCS.getInstance("hello");
add(new Label("message", "Server B -> cache has : " +  
cache.get(“message");));


The first time I access the page on server A I get an exception -  "Cannot 
connect to localhost:8021”.  If I access the page on each server then things 
appear to start communicating; however, the “message” entry from the “hello” 
region is set on server A and null on B and C.  Sometimes I see the value on 
server C displayed properly but never on server B.

With a configuration like this should I expect to see values immediately 
distributed to the other servers?

Is there a way I should be bootstrapping the cache when the server starts?  If 
the servers need to communicate with one another it would seem to me that they 
need to be listening long before the first time the server tries to access the 
cache.

For performance I would like to use the cache to store serialized XML data 
instead of storing it in the session or a database.  The data remains in the 
cache while the user transforms it through several request cycles.  So during a 
request cycle the XML data would be retrieved, transformed, and stored back in 
the cache.  In a clustered environment I need the XML data available on every 
server in the cluster.  Is this an acceptable use case for JCS?

Thanks

Re: Jcs 2.2 release

[Helge Waastad]

Hi,
Yes...thats what I was hoping for :-)
/hw
fr., 09.06.2017 kl. 12.15 -0700, skrev Gary Gregory:
> Hi Hege,
> 
> It all depends on an Apache Committer willing to volunteer and take
> the
> time. This is the right place to ask :-)
> 
> Gary
> 
> On Fri, Jun 9, 2017 at 11:19 AM, Helge Waastad <he...@waastad.org>
> wrote:
> 
> > 
> > Hi,
> > Is it possible to release the JCS 2.2?
> > 
> > Rmannibucau fixed a serious remote cache issue today and it's been
> > there
> > since 2.0-beta-1.
> > 
> > /hw
> > 
> > Sent from my Nokia 6110
> > 
> > -
> > 
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> > 
> > 

[jcs] Re: Can JCS have update events?

[Thomas Vandahl]

On 08.04.17 14:40, robertlazarski . wrote:
> We need update events because our code already uses them - we are
> replacing our current cache libs (ehcache) with another lib -
> preferably JCS.
> 
> More specifically, our local cache is filled with stock prices via a
> "HTTP server push" stream and on updates we need to perform some
> additional calculations using events and listeners.

Although I strongly believe that this should be handled outside the
scope of the cache, I think that update events could be added to JCS
quite easily.

JCS does not support this at the moment. The best place to add such a
feature probably would be CompositeCache.update() and remove(),
respectively. Please be sure to take the asynchronous nature of event
handling into account.

> I looked a lot at the JCS code and didn't find update events, which is
> why I looked at the JCS JCache implementation. Apparently JSR-107
> didn't define persistence though. I notice some other projects have a
> JSR-107 "CacheStore" for disk persistence but to be clear I definitely
> want to use JCS.

The JCache implementation actually is just a wrapper around JCS, so all
features of JCS, including the disk auxiliary should be available from
JCache, too. I'm only maintaining the core of JCS, so I cannot speak
from JCache experiences here.

> Saying this as humbly as possible as clearly I am not a Cache expert ,
> I am an Apache Axis2 committer plus I have done several Linux related
> contributions and I would be willing to submit patches if I end up
> having to "scratch my own itch" . Of course though I would rather use
> an API that already exists.

Patches are always welcome.
However I still suggest to reconsider putting data manipulations into
the scope of the cache, independently of the library used.

Bye, Thomas


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Can JCS have update events?

[robertlazarski .]

On Sat, Apr 8, 2017 at 7:13 AM, Thomas Vandahl <t...@apache.org> wrote:
> Please use [jcs] as a prefix to the subject when posting to
> us...@commons.apache.org.

Got it, thanks for the response.

>
> On 06.04.17 18:21, robertlazarski . wrote:
>> I am coding a simple local "Indexed Disk Auxiliary Cache" and
>> IsEternal=true using JCS, and I can't figure out how to have an
>> onUpdate() event. Is there update events in JCS?
>
> Why are you coding the cache? This should only need configuration. Why
> do you think you need update events?
>

Sorry I was not clear - I really meant configuring an "Indexed Disk
Auxiliary Cache" per the docs and using ICache and CacheAccess etc for
my project code implementation. Nothing out of the ordinary.

We need update events because our code already uses them - we are
replacing our current cache libs (ehcache) with another lib -
preferably JCS.

More specifically, our local cache is filled with stock prices via a
"HTTP server push" stream and on updates we need to perform some
additional calculations using events and listeners.

>> I looked at the JCS implementation of JCache events and it looks like
>> what I need, but I can't figure out how to do disk persistence with
>> JCS / JCache as I can't find any code examples.
>
> Did you read the docs at
> https://commons.apache.org/proper/commons-jcs/IndexedDiskAuxCache.html?
> The configuration example on that page is basically all you need. See
> https://commons.apache.org/proper/commons-jcs/JCSPlugins.html for a
> description of JCS' concept of auxiliaries.
>
> Bye, Thomas
>

The docs mention 4 auxiliaries: (1) memory, (2) disk, (3) lateral, and
(4) remote. I need 1 and 2 but also with update events and a listener.

If I can get an IndexedDiskAuxCache working using typical onUpdate()
events and a listener that would be ideal. Actually I not only read
the docs but also the source code.

I looked a lot at the JCS code and didn't find update events, which is
why I looked at the JCS JCache implementation. Apparently JSR-107
didn't define persistence though. I notice some other projects have a
JSR-107 "CacheStore" for disk persistence but to be clear I definitely
want to use JCS.

Saying this as humbly as possible as clearly I am not a Cache expert ,
I am an Apache Axis2 committer plus I have done several Linux related
contributions and I would be willing to submit patches if I end up
having to "scratch my own itch" . Of course though I would rather use
an API that already exists.

Kind regards,
Robert

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Can JCS have update events?

[Thomas Vandahl]

Please use [jcs] as a prefix to the subject when posting to
us...@commons.apache.org.

On 06.04.17 18:21, robertlazarski . wrote:
> I am coding a simple local "Indexed Disk Auxiliary Cache" and
> IsEternal=true using JCS, and I can't figure out how to have an
> onUpdate() event. Is there update events in JCS?

Why are you coding the cache? This should only need configuration. Why
do you think you need update events?

> I looked at the JCS implementation of JCache events and it looks like
> what I need, but I can't figure out how to do disk persistence with
> JCS / JCache as I can't find any code examples.

Did you read the docs at
https://commons.apache.org/proper/commons-jcs/IndexedDiskAuxCache.html?
The configuration example on that page is basically all you need. See
https://commons.apache.org/proper/commons-jcs/JCSPlugins.html for a
description of JCS' concept of auxiliaries.

Bye, Thomas

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Can JCS have update events?

[robertlazarski .]

Hi all,

I am coding a simple local "Indexed Disk Auxiliary Cache" and
IsEternal=true using JCS, and I can't figure out how to have an
onUpdate() event. Is there update events in JCS?

I am a bit confused on IElementEventConstants since they are seemingly
for expiration and disk spooling, not actual changes in the cache
values.

I looked at the JCS implementation of JCache events and it looks like
what I need, but I can't figure out how to do disk persistence with
JCS / JCache as I can't find any code examples.

So I am a bit stuck - can't figure out how to do update events using
JCS, and can't figure out how to do do disk persistence with JCS /
JCache. I'm open to either one. Any help appreciated.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Migrating from Ehcache to JCS, need help getting the right config

[Thomas Vandahl]

On 23.03.17 15:01, robertlazarski . wrote:
> Thanks for the response! That helped a lot. I am about to start coding
> but I am trying to figure out #3. Please see below.

The cache warming itself is not a big deal. Just call getKeySet() on the
memory cache and call get() for all keys. This will load the values from
disk into the memory cache. The question is just where to insert the
loop into the application initialization.

Bye, Thomas


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Migrating from Ehcache to JCS, need help getting the right config

[robertlazarski .]

Thanks for the response! That helped a lot. I am about to start coding
but I am trying to figure out #3. Please see below.

On Wed, Mar 22, 2017 at 2:44 PM, Thomas Vandahl <t...@apache.org> wrote:
>> 3) Most importantly, on server startup we need the entire disk
>> persisted cache loaded into memory, i.e. "cache warming" . I am
>> wondering if the CacheLoaderAdapter is the right class for this?
>> Currently we use a class that Ehcache calls on startup that just uses
>> an Iterator over all the cache Elements, effectively loading
>> everything into memory.
>
> This can be achieved by setting ClearDiskOnStartup=false. This happens
> to be the default. JCS will load all the keys into memory then but not
> the values. So if you want the values to be loaded, just modify the
> class you used for EHCache.
>
> How to integrate this into your application depends on your application
> lifecycle. There is no CacheLoaderAdapter class in JCS. If you tell me a
> bit more about your application, I might be able to give you a hint.
>
> HTH
> Bye, Thomas
>

The CacheLoaderAdapter class I referred to as it turns out is for
JCache and its in the JCS extras module.

https://commons.apache.org/proper/commons-jcs//commons-jcs-jcache-extras/apidocs/org/apache/commons/jcs/jcache/extras/loader/CacheLoaderAdapter.html

The reason I was interested in this is because with ehcache I define
bootstrapCacheLoaderFactory=myStartUpClass that ehcache calls on
server init / ehcache init, as my class extends the ehcache
MemoryLimitedCacheLoader class to load the entire cache (keys and
values) into memory.

I am just looking for some way to do the equivalent with JCS - call
something on server init and perhaps tied in to JCS init. That led me
into JCache. Anyways we have a simple local cache I am trying to just
get JCS to somehow get my cache into memory on startup and then go
from there.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Migrating from Ehcache to JCS, need help getting the right config

[Thomas Vandahl]

Hi there,

On 21.03.17 15:50, robertlazarski . wrote:
> Hello! We have a production system running Ehcache and we'd like to
> use JCS instead. What I need to do with JCS is:
> 
> 1) Load all Objects into memory, unlimited with infinite "time to
> live". In practice over many years, its not been a problem for us.
> Currently using LRU.

Yes, this is easy, just define a memory cache big enough to hold all
your objects. Set

jcs.default.elementattributes.IsEternal=true

> 2) Store Objects from memory to disk on JVM shutdown, or at least
> periodically flush to disk - while keeping the entire cache in memory.

See
https://commons.apache.org/proper/commons-jcs/IndexedDiskAuxCache.html
for the configuration of an auxiliary disk cache. If you have configured
your memory cache big enough, no "overflow" of items to disk will happen
in normal operation.

You need to shut down the cache orderly
(CompositeCacheManager.getInstance().shutDown()) to trigger the "dump to
disk" process. There is no simple method to do this periodically.

> 
> 3) Most importantly, on server startup we need the entire disk
> persisted cache loaded into memory, i.e. "cache warming" . I am
> wondering if the CacheLoaderAdapter is the right class for this?
> Currently we use a class that Ehcache calls on startup that just uses
> an Iterator over all the cache Elements, effectively loading
> everything into memory.

This can be achieved by setting ClearDiskOnStartup=false. This happens
to be the default. JCS will load all the keys into memory then but not
the values. So if you want the values to be loaded, just modify the
class you used for EHCache.

How to integrate this into your application depends on your application
lifecycle. There is no CacheLoaderAdapter class in JCS. If you tell me a
bit more about your application, I might be able to give you a hint.

HTH
Bye, Thomas

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Migrating from Ehcache to JCS, need help getting the right config

[robertlazarski .]

Hello! We have a production system running Ehcache and we'd like to
use JCS instead. What I need to do with JCS is:

1) Load all Objects into memory, unlimited with infinite "time to
live". In practice over many years, its not been a problem for us.
Currently using LRU.

2) Store Objects from memory to disk on JVM shutdown, or at least
periodically flush to disk - while keeping the entire cache in memory.

3) Most importantly, on server startup we need the entire disk
persisted cache loaded into memory, i.e. "cache warming" . I am
wondering if the CacheLoaderAdapter is the right class for this?
Currently we use a class that Ehcache calls on startup that just uses
an Iterator over all the cache Elements, effectively loading
everything into memory.

I could post our Ehcache config if that'd be helpful. Anyways I am
trying to figure out the right config for these requirements,
particularly the cache warming setup. Any help appreciated.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCE] Apache Commons JCS 2.1 Released

[Thomas Vandahl]

The Apache Commons Team is pleased to announce the availability of:

Apache Commons JCS 2.1

Apache Commons JCS is a distributed, versatile caching system.

The release notes can be reviewed at:
http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt

Distribution packages can be downloaded from:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

When downloading, please verify signatures using the KEYS file available
at:
http://www.apache.org/dist/commons

More information and comprehensive documentation is available at:
https://commons.apache.org/proper/commons-jcs/

Maven artifacts are also available in the central Maven repository:
http://repo1.maven.org/maven2/org/apache/commons/

The Apache Commons Team


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: JCS : element expires sooner than configured

[Thomas Vandahl]

Ouch, that hurt. I'm sorry, this is a problem with ElementAttributes.clone() 
not updating createTime. I fixed it in trunk. Could you try if it works for you?

Bye, Thomas 

-- tv

> Am 23.01.2017 um 10:48 schrieb Sahib Bin Mahboob Ron <sa...@cefalo.com>:
> 
> Hi,
> 
> I am trying to configure a JCS using the following configuration:
> 
> # DEFAULT CACHE REGION
> 
> jcs.default=
> jcs.default.cacheattributes=
>org.apache.commons.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=1000
> jcs.default.cacheattributes.MemoryCacheName=
>org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
> 
> jcs.default.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsEternal=false
> jcs.default.elementattributes.MaxLife=300
> jcs.default.elementattributes.IsSpool=false
> 
> 
> While it is expected to expire the item in 300 seconds as per MaxLife
> configuration, it does not work properly in following steps:
> 
> 1. Putting a key "aKey" for the first time in cache: It works perfectly.
> 2. "aKey" expires after 300 seconds.
> 3. Put "aKey" again on the cache.
> 4. It expires immediately.
> 
> Am I missing any configuration or this is the way it should behave?
> 
> - Sahib


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

JCS : element expires sooner than configured

[Sahib Bin Mahboob Ron]

Hi,

I am trying to configure a JCS using the following configuration:

# DEFAULT CACHE REGION

jcs.default=
jcs.default.cacheattributes=
org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=1000
jcs.default.cacheattributes.MemoryCacheName=
org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache

jcs.default.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
jcs.default.elementattributes.IsEternal=false
jcs.default.elementattributes.MaxLife=300
jcs.default.elementattributes.IsSpool=false


While it is expected to expire the item in 300 seconds as per MaxLife
configuration, it does not work properly in following steps:

1. Putting a key "aKey" for the first time in cache: It works perfectly.
2. "aKey" expires after 300 seconds.
3. Put "aKey" again on the cache.
4. It expires immediately.

Am I missing any configuration or this is the way it should behave?

- Sahib

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=1
jcs.auxiliary.DC.attributes.MaxKeySize=1
jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=30
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:
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

[ANNOUNCE] Apache Commons JCS 2.0 Released

[Thomas Vandahl]

The Apache Commons Team is pleased to announce the availability of:

Apache Commons JCS 2.0

Apache Commons JCS is a distributed, versatile caching system.

The release notes can be reviewed at:
http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt

Distribution packages can be downloaded from:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

When downloading, please verify signatures using the KEYS file available
at:
http://www.apache.org/dist/commons

More information and comprehensive documentation is available at:
https://commons.apache.org/proper/commons-jcs/

Maven artifacts are also available in the central Maven repository:
http://repo1.maven.org/maven2/org/apache/commons/

The Apache Commons Team


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: JCS 2.0-beta-2: ShrinkerThread: Unexpected trouble in shrink cycle

[Kirys]

On 26/11/2016 20:09, Thomas Vandahl wrote:

On 26.11.16 16:07, Kirys wrote:

[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|INFO
o.a.c.j.e.m.s.ShrinkerThread: Unexpected trouble in shrink cycle
java.lang.NoClassDefFoundError:
org/apache/commons/jcs/engine/control/group/GroupAttrName

This looks like a class-loader issue between threads. The class
mentioned is included in the commons-jcs-core jar and the application
should have no problems loading it. I'm not familiar with the TomEE
environment. Can you try to reproduce the problem outside this context?

I have to admit that currently I was not able to reproduce in a client app.
Next week I'll try to put JCS war into the lib folder of tomee to see if 
this fix the issue.

Bye
K.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: JCS 2.0-beta-2: ShrinkerThread: Unexpected trouble in shrink cycle

[Thomas Vandahl]

On 26.11.16 16:07, Kirys wrote:
> [C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|INFO
> o.a.c.j.e.m.s.ShrinkerThread: Unexpected trouble in shrink cycle
> java.lang.NoClassDefFoundError:
> org/apache/commons/jcs/engine/control/group/GroupAttrName

This looks like a class-loader issue between threads. The class
mentioned is included in the commons-jcs-core jar and the application
should have no problems loading it. I'm not familiar with the TomEE
environment. Can you try to reproduce the problem outside this context?

Bye, Thomas



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

JCS 2.0-beta-2: ShrinkerThread: Unexpected trouble in shrink cycle

[Kirys]

Hi all

I'm am experimenting with JCS 2.0-beta-2 inside a TomEE 1.6.4 
application (I'm using it directly not using jcache)


I'm am periodically finding this error into the logs:

[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|DEBUG 
o.a.c.j.e.m.s.ShrinkerThread: Shrinking memory cache for: short
[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|DEBUG 
o.a.c.j.e.m.s.ShrinkerThread: Keys size: 1
[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|DEBUG 
o.a.c.j.e.m.AbstractMemoryCache: short: MemoryCache quiet hit for 
lastFetchDate
[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|DEBUG 
o.a.c.j.e.c.CompositeCache: Exceeded maxLife: lastFetchDate
[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|DEBUG 
o.a.c.j.e.m.AbstractDoubleLinkedListMemoryCache: removing item for key: 
lastFetchDate
[C]2016-11-26 15:56:00,070|JCS-Scheduler-Thread-21|INFO 
o.a.c.j.e.m.s.ShrinkerThread: Unexpected trouble in shrink cycle
java.lang.NoClassDefFoundError: 
org/apache/commons/jcs/engine/control/group/GroupAttrName
at 
org.apache.commons.jcs.engine.memory.AbstractDoubleLinkedListMemoryCache.remove(AbstractDoubleLinkedListMemoryCache.java:427)
at 
org.apache.commons.jcs.engine.memory.shrinking.ShrinkerThread.shrink(ShrinkerThread.java:157)
at 
org.apache.commons.jcs.engine.memory.shrinking.ShrinkerThread.run(ShrinkerThread.java:91)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

What can it be?


Current configuration is:

# cache configuration
jcs.default=
jcs.default.cacheattributes=
org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=10
jcs.default.cacheattributes.MemoryCacheName=
org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache

jcs.region.short=
jcs.region.short.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.region.short.cacheattributes.MaxObjects=200
jcs.region.short.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.short.cacheattributes.UseMemoryShrinker=true
jcs.region.short.cacheattributes.MaxMemoryIdleTimeSeconds=60
jcs.region.short.cacheattributes.ShrinkerIntervalSeconds=30
jcs.region.short.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
jcs.region.short.elementattributes.IsEternal=false
jcs.region.short.elementattributes.MaxLife=800

jcs.region.long=
jcs.region.long.cacheattributes=org.apache.commons.jcs.engine.CompositeCacheAttributes
jcs.region.long.cacheattributes.MaxObjects=30
jcs.region.long.cacheattributes.MemoryCacheName=org.apache.commons.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.long.cacheattributes.UseMemoryShrinker=true
jcs.region.long.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.region.long.cacheattributes.ShrinkerIntervalSeconds=30
jcs.region.long.elementattributes=org.apache.commons.jcs.engine.ElementAttributes
jcs.region.long.elementattributes.IsEternal=false
jcs.region.long.elementattributes.MaxLife=1800

into the pom I've put this dependency


org.apache.commons
commons-jcs-core
2.0-beta-2


Thank you

Bye

K.




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons JCS 2.0-beta-2 Released

[Jörg Schaible]

Tim Cronin wrote:

> doesn't show up in the main maven repo the listings
> 
> http://mvnrepository.com/artifact/org.apache.commons/commons-jcs-core

Ask the owner of that site. The link below points to central and that's the 
only official Maven repository (searchable using http://search.maven.org).

> On Wed, Nov 16, 2016 at 8:54 AM, Thomas Vandahl <t...@apache.org> wrote:
> 
>> On 16.11.16 14:56, Tim Cronin wrote:
>> > when will it be accessible via maven/ivy repo?
>>
>> It already is:
>> http://repo1.maven.org/maven2/org/apache/commons/commons->> 
>> jcs-core/2.0-beta-2/
>>
>> Bye, Thomas.

- Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons JCS 2.0-beta-2 Released

[Tim Cronin]

doesn't show up in the main maven repo the listings

http://mvnrepository.com/artifact/org.apache.commons/commons-jcs-core

On Wed, Nov 16, 2016 at 8:54 AM, Thomas Vandahl <t...@apache.org> wrote:

> On 16.11.16 14:56, Tim Cronin wrote:
> > when will it be accessible via maven/ivy repo?
>
> It already is:
> http://repo1.maven.org/maven2/org/apache/commons/commons-
> jcs-core/2.0-beta-2/
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [ANNOUNCE] Apache Commons JCS 2.0-beta-2 Released

[Thomas Vandahl]

On 16.11.16 14:56, Tim Cronin wrote:
> when will it be accessible via maven/ivy repo?

It already is:
http://repo1.maven.org/maven2/org/apache/commons/commons-jcs-core/2.0-beta-2/

Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [ANNOUNCE] Apache Commons JCS 2.0-beta-2 Released

[Tim Cronin]

when will it be accessible via maven/ivy repo?

On Wed, Nov 16, 2016 at 4:16 AM, Thomas Vandahl <t...@apache.org> wrote:

> The Apache Commons Team is pleased to announce the availability of:
>
> Apache Commons JCS 2.0-beta-2
>
> Apache Commons JCS is a distributed, versatile caching system.
>
> The release notes can be reviewed at:
> http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt
>
> Distribution packages can be downloaded from:
> https://commons.apache.org/proper/commons-jcs/download_jcs.cgi
>
> When downloading, please verify signatures using the KEYS file available
> at:
> http://www.apache.org/dist/commons
>
> Maven artifacts are also available in the central Maven repository:
>
> http://repo1.maven.org/maven2/org/apache/commons/
>
> The Apache Commons Team
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

[ANNOUNCE] Apache Commons JCS 2.0-beta-2 Released

[Thomas Vandahl]

The Apache Commons Team is pleased to announce the availability of:

Apache Commons JCS 2.0-beta-2

Apache Commons JCS is a distributed, versatile caching system.

The release notes can be reviewed at:
http://www.apache.org/dist/commons/jcs/RELEASE-NOTES.txt

Distribution packages can be downloaded from:
https://commons.apache.org/proper/commons-jcs/download_jcs.cgi

When downloading, please verify signatures using the KEYS file available at:
http://www.apache.org/dist/commons

Maven artifacts are also available in the central Maven repository:

http://repo1.maven.org/maven2/org/apache/commons/

The Apache Commons Team


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Apache JCS 2.0 beta 2?

[Thomas Vandahl]

Hi Ryan,

On 23.09.16 22:54, Ryan Fong wrote:
> G'day, all. I've submitted a couple of patches towards Apache JCS 2.0 beta-2 
> a few months back. I've also been seeing some errors like JCS-146 which have 
> already been fixed but are not available in a download.  However, I don't see 
> any activity or intent to build a new beta-2 or a release candidate. Is this 
> project still active? What are the release expectations?
> 

your contributions are very much appreciated. I'm currently working on
JCS-130 to clean up the inter-dependencies of managers, factories,
services and stuff. Before releasing 2.0, I wanted to get this finished.
Unfortunately, I have very little time for open source development at
the moment so this takes longer than I expected.

In the meantime you can use a fairly recent build (currently 2016-08-07)
from the snapshot-repository at
https://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-jcs-core/2.0-SNAPSHOT/

HTH
Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Apache JCS 2.0 beta 2?

[Ryan Fong]

G'day, all. I've submitted a couple of patches towards Apache JCS 2.0 beta-2 a 
few months back. I've also been seeing some errors like JCS-146 which have 
already been fixed but are not available in a download.  However, I don't see 
any activity or intent to build a new beta-2 or a release candidate. Is this 
project still active? What are the release expectations?

Re: [JCS]

[Mat Jaggard]

The error I got was "Table already exists: JCS_STORE_SHRINK in statement
[CREATE CACHED TABLE JCS_STORE_SHRINK]"

How about the attached patch instead?
Looks like my commit made no difference to the continuum problem :-(


On Sat, 6 Feb 2016 at 17:42 Thomas Vandahl  wrote:

> Hi Mat,
>
> On 03.02.16 17:44, Mat Jaggard wrote:
> > I have three patches that might be helpful...
> >
> > 1. Javadoc changes to make it compile on my machine
> > 2. Server port changes which may (or may not) fix the continuum unit
> > test issue
> > 3. Change to the way existing tables are detected (I think I got a
> > different SQL error code)
>
> Thanks again for contributing. I applied patches 1 and 2. I'm not so
> sure about 3.
> The check for SQL state 23000 is quite common. We use the same check in
> DB Torque for several different database systems with good success.
> What error message did you get?
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
Index: HsqlSetupTableUtil.java
===
--- HsqlSetupTableUtil.java	(revision 1726611)
+++ HsqlSetupTableUtil.java	(working copy)
@@ -60,7 +60,7 @@
 }
 catch ( SQLException e )
 {
-if ("23000".equals(e.getSQLState()))
+if ("23000".equals(e.getSQLState()) || ("S0001".equals(e.getSQLState()) && e.getErrorCode() == -21))
 {
 newT = false;
 }
Index: JDBCDiskCacheShrinkUnitTest.java
===
--- JDBCDiskCacheShrinkUnitTest.java	(revision 1726611)
+++ JDBCDiskCacheShrinkUnitTest.java	(working copy)
@@ -254,7 +254,7 @@
 }
 catch ( SQLException e )
 {
-if ("23000".equals(e.getSQLState()))
+if ("23000".equals(e.getSQLState()) || ("S0001".equals(e.getSQLState()) && e.getErrorCode() == -21))
 {
 newT = false;
 }
Index: mysql/MySQLDiskCacheHsqlBackedUnitTest.java
===
--- mysql/MySQLDiskCacheHsqlBackedUnitTest.java	(revision 1726611)
+++ mysql/MySQLDiskCacheHsqlBackedUnitTest.java	(working copy)
@@ -207,7 +207,7 @@
 }
 catch ( SQLException e )
 {
-if ("23000".equals(e.getSQLState()))
+if ("23000".equals(e.getSQLState()) || ("S0001".equals(e.getSQLState()) && e.getErrorCode() == -21))
 {
 newT = false;
 }

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS]

[Thomas Vandahl]

Hi Mat,

On 03.02.16 17:44, Mat Jaggard wrote:
> I have three patches that might be helpful...
> 
> 1. Javadoc changes to make it compile on my machine
> 2. Server port changes which may (or may not) fix the continuum unit
> test issue
> 3. Change to the way existing tables are detected (I think I got a
> different SQL error code)

Thanks again for contributing. I applied patches 1 and 2. I'm not so
sure about 3.
The check for SQL state 23000 is quite common. We use the same check in
DB Torque for several different database systems with good success.
What error message did you get?

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS]

[Mat Jaggard]

I have three patches that might be helpful...

1. Javadoc changes to make it compile on my machine
2. Server port changes which may (or may not) fix the continuum unit test
issue
3. Change to the way existing tables are detected (I think I got a
different SQL error code)

Many thanks,
Mat.

On Tue, 2 Feb 2016 at 17:12 Thomas Vandahl <t...@apache.org> wrote:

> On 02.02.16 11:22, Mat Jaggard wrote:
> > I've submitted my pull request.
> >
> > https://github.com/apache/commons-jcs/pull/2
> >
> > On Mon, 1 Feb 2016 at 16:32 Gary Gregory <garydgreg...@gmail.com> wrote:
> >
> >> It is, github is just a mirror. You submit a patch with the Jira if you
> >> prefer.
>
> Thanks for your contribution. How do I merge this into SVN now? I'm not
> familiar with github.
>
> Bye, Thomas
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
Index: java/org/apache/commons/jcs/auxiliary/remote/server/BasicRemoteCacheClientServerUnitTest.java
===
--- java/org/apache/commons/jcs/auxiliary/remote/server/BasicRemoteCacheClientServerUnitTest.java	(revision 1726611)
+++ java/org/apache/commons/jcs/auxiliary/remote/server/BasicRemoteCacheClientServerUnitTest.java	(working copy)
@@ -46,7 +46,7 @@
 
 /**
  * These tests startup the remote server and make requests to it.
- * 
+ * 
  *
  * @author Aaron Smuts
  */
@@ -53,7 +53,9 @@
 @FixMethodOrder(MethodSorters.NAME_ASCENDING)
 public class BasicRemoteCacheClientServerUnitTest extends Assert
 {
-/**
+private static final int LOCAL_PORT = 12020;
+
+   /**
  * Server instance to use in the tests.
  */
 private static RemoteCacheServer<String, String> server = null;
@@ -124,12 +126,12 @@
  * Verify that we can start the remote cache server. Send an item to the remote. Verify that the
  * remote put count goes up. If we go through JCS, the manager will be shared and we will get
  * into an endless loop. We will use a mock cache manager instead.
- * 
+ * 
  * The remote server uses the real JCS. We can verify that items are added to JCS behind the
  * server by calling get. We cannot access it directly via JCS since it is serialized.
- * 
+ * 
  * This test uses a mock injected client to test a normal server.
- * 
+ * 
  *
  * @throws Exception
  */
@@ -142,7 +144,7 @@
 
 RemoteCacheAttributes attributes = new RemoteCacheAttributes();
 attributes.setRemoteLocation("localhost", remotePort);
-attributes.setLocalPort(1202);
+attributes.setLocalPort(LOCAL_PORT);
 
 RemoteCacheManager remoteCacheManager = RemoteCacheFactory.getManager(attributes, compositeCacheManager, new MockCacheEventLogger(), new MockElementSerializer());
 String regionName = "testSinglePut";
@@ -176,7 +178,7 @@
 
 /**
  * Verify that we can remove an item via the remote server.
- * 
+ * 
  *
  * @throws Exception
  */
@@ -189,7 +191,7 @@
 
 RemoteCacheAttributes attributes = new RemoteCacheAttributes();
 attributes.setRemoteLocation("localhost", remotePort);
-attributes.setLocalPort(1202);
+attributes.setLocalPort(LOCAL_PORT);
 
 MockCacheEventLogger cacheEventLogger = new MockCacheEventLogger();
 
@@ -245,7 +247,7 @@
 
 RemoteCacheAttributes attributes = new RemoteCacheAttributes();
 attributes.setRemoteLocation("localhost", remotePort);
-attributes.setLocalPort(1202);
+attributes.setLocalPort(LOCAL_PORT);
 
 RemoteCacheManager remoteCacheManager = RemoteCacheFactory.getManager(attributes, compositeCacheManager, new MockCacheEventLogger(), new MockElementSerializer());
 String regionName = "testPutAndListen";
@@ -294,7 +296,7 @@
 
 RemoteCacheAttributes attributes = new RemoteCacheAttributes();
 attributes.setRemoteLocation("localhost", remotePort);
-attributes.setLocalPort(1202);
+attributes.setLocalPort(LOCAL_PORT);
 
 RemoteCacheManager remoteCacheManager = RemoteCacheFactory.getManager(attributes, compositeCacheManager, new MockCacheEventLogger(), new MockElementSerializer());
 String regionName = "testPutaMultipleAndListen";
Index: test-conf/TestRemoteCacheClientServer.ccf
===
--- test-conf/TestRemoteCacheClientServer.ccf	(revision 1726611)
+++ test-conf/TestRemoteCacheClientServer.ccf	(working copy)
@@ -18,10 +18,10 @@
 # # REMOTE SERVER CONFIG  #
 # Registry used to register and provide the IRmiCacheService service.
 registry.host=local

Re: [JCS]

[Mat Jaggard]

I've submitted my pull request.

https://github.com/apache/commons-jcs/pull/2

On Mon, 1 Feb 2016 at 16:32 Gary Gregory <garydgreg...@gmail.com> wrote:

> It is, github is just a mirror. You submit a patch with the Jira if you
> prefer.
>
> Gary
> On Feb 1, 2016 8:12 AM, "Mat Jaggard" <matt...@jaggard.org.uk> wrote:
>
> > Ah, great, I thought JCS was on subversion at
> > https://svn.apache.org/repos/asf/commons/proper/jcs/
> >
> > On Mon, 1 Feb 2016 at 16:07 Papendieck, Thomas <
> > thomas.papendi...@opitz-consulting.com> wrote:
> >
> > > https://github.com/apache/commons-jcs
> > >
> > > create an account on github
> > > make a fork
> > > push your changes
> > > initiate a pull request
> > >
> > > bye
> > > Thomas
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Mat Jaggard [mailto:apa...@jaggard.org.uk]
> > > Gesendet: Montag, 1. Februar 2016 16:23
> > > An: Commons Users List
> > > Betreff: [JCS]
> > >
> > > Hi,
> > > I have two patches to fix some problems I had running build and unit
> > tests
> > > on JCS 2.0 - who can I give them to?
> > >
> > > Thanks,
> > > Mat.
> > >
> >
>

Re: [JCS]

[Thomas Vandahl]

On 02.02.16 11:22, Mat Jaggard wrote:
> I've submitted my pull request.
> 
> https://github.com/apache/commons-jcs/pull/2
> 
> On Mon, 1 Feb 2016 at 16:32 Gary Gregory <garydgreg...@gmail.com> wrote:
> 
>> It is, github is just a mirror. You submit a patch with the Jira if you
>> prefer.

Thanks for your contribution. How do I merge this into SVN now? I'm not
familiar with github.

Bye, Thomas


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

AW: [JCS]

[Papendieck, Thomas]

https://github.com/apache/commons-jcs

create an account on github
make a fork
push your changes 
initiate a pull request

bye
Thomas

-Ursprüngliche Nachricht-
Von: Mat Jaggard [mailto:apa...@jaggard.org.uk] 
Gesendet: Montag, 1. Februar 2016 16:23
An: Commons Users List
Betreff: [JCS]

Hi,
I have two patches to fix some problems I had running build and unit tests on 
JCS 2.0 - who can I give them to?

Thanks,
Mat.

Re: [JCS]

[Mat Jaggard]

Ah, great, I thought JCS was on subversion at
https://svn.apache.org/repos/asf/commons/proper/jcs/

On Mon, 1 Feb 2016 at 16:07 Papendieck, Thomas <
thomas.papendi...@opitz-consulting.com> wrote:

> https://github.com/apache/commons-jcs
>
> create an account on github
> make a fork
> push your changes
> initiate a pull request
>
> bye
> Thomas
>
> -Ursprüngliche Nachricht-
> Von: Mat Jaggard [mailto:apa...@jaggard.org.uk]
> Gesendet: Montag, 1. Februar 2016 16:23
> An: Commons Users List
> Betreff: [JCS]
>
> Hi,
> I have two patches to fix some problems I had running build and unit tests
> on JCS 2.0 - who can I give them to?
>
> Thanks,
> Mat.
>

Re: [JCS]

[Gary Gregory]

It is, github is just a mirror. You submit a patch with the Jira if you
prefer.

Gary
On Feb 1, 2016 8:12 AM, "Mat Jaggard" <matt...@jaggard.org.uk> wrote:

> Ah, great, I thought JCS was on subversion at
> https://svn.apache.org/repos/asf/commons/proper/jcs/
>
> On Mon, 1 Feb 2016 at 16:07 Papendieck, Thomas <
> thomas.papendi...@opitz-consulting.com> wrote:
>
> > https://github.com/apache/commons-jcs
> >
> > create an account on github
> > make a fork
> > push your changes
> > initiate a pull request
> >
> > bye
> > Thomas
> >
> > -Ursprüngliche Nachricht-
> > Von: Mat Jaggard [mailto:apa...@jaggard.org.uk]
> > Gesendet: Montag, 1. Februar 2016 16:23
> > An: Commons Users List
> > Betreff: [JCS]
> >
> > Hi,
> > I have two patches to fix some problems I had running build and unit
> tests
> > on JCS 2.0 - who can I give them to?
> >
> > Thanks,
> > Mat.
> >
>

[JCS]

[Mat Jaggard]

Hi,
I have two patches to fix some problems I had running build and unit tests
on JCS 2.0 - who can I give them to?

Thanks,
Mat.

Re: [JCS] Region No longer alive so returning false for key

[Thomas Vandahl]

On 06.07.15 15:37, Tim Cronin wrote:
 is there any documentation on migrating from 1.3 to 2?

Not yet. I started to write something, but I have yet to finish it.

 
 the JCSAdmin.jsp the FAQ link is broken. moved due to package change
 http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log

Thank you for the hint I will fix this.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Thomas Vandahl]

On 06.07.15 17:06, Tim Cronin wrote:
 I added the following before calling the composite cache shutdown.
 this should be called via the composite cache shutdown code i think
 
 ThreadPoolManager poolMgr = ThreadPoolManager.getInstance();
 
 for(String poolName : poolMgr.getPoolNames()) {
 try {
 poolMgr.getPool(poolName).shutdown();
 } catch (Throwable t) {
 LOGGER.warn(Failed to close pool  + poolName, t);
 }
 }

Thank you for your contributions I'll try to take care of these.
Please not that these problems also have been present in 1.3.

Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

will there be another release cut soon?

how close to non beta release?

On Fri, Jul 10, 2015 at 1:48 AM, Thomas Vandahl t...@apache.org wrote:

 On 06.07.15 17:06, Tim Cronin wrote:
  I added the following before calling the composite cache shutdown.
  this should be called via the composite cache shutdown code i think
 
  ThreadPoolManager poolMgr = ThreadPoolManager.getInstance();
 
  for(String poolName : poolMgr.getPoolNames()) {
  try {
  poolMgr.getPool(poolName).shutdown();
  } catch (Throwable t) {
  LOGGER.warn(Failed to close pool  + poolName, t);
  }
  }

 Thank you for your contributions I'll try to take care of these.
 Please not that these problems also have been present in 1.3.

 Bye, Thomas.


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

yes is see it there, but nothing about it being changed in 2.x.

On Fri, Jul 10, 2015 at 4:12 PM, Thomas Vandahl t...@apache.org wrote:

 On 06.07.15 16:33, Tim Cronin wrote:
  MaxLifeSeconds has been changed to MaxLife, didn't find anything in the
  docs about this change.

 See http://commons.apache.org/proper/commons-jcs/RegionProperties.html

 Bye, Thomas



 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Thomas Vandahl]

On 06.07.15 16:33, Tim Cronin wrote:
 MaxLifeSeconds has been changed to MaxLife, didn't find anything in the
 docs about this change.

See http://commons.apache.org/proper/commons-jcs/RegionProperties.html

Bye, Thomas



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

i understand that 1.3 is old and the 2 branch will be the way going forward
but...

this happens on our production server and really don't want to run beta
code on it.

i've played with the beta code and it requires code changes on our side as
well.

On Sun, Jul 5, 2015 at 10:25 AM, Thomas Vandahl t...@apache.org wrote:

 On 02.07.15 15:13, Tim Cronin wrote:
  JCS 1.3
 
  i periodically get the above error.
 
  what do i need to do to recover from this?
 

 First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
 numerous fixes and cleans up the lifecycle of most of the JCS manager
 classes. If that doesn't help, come back and ask again as this would
 require deeper digging.

 Bye, Thomas.

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

is there any documentation on migrating from 1.3 to 2?

the JCSAdmin.jsp the FAQ link is broken. moved due to package change
http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log


On Mon, Jul 6, 2015 at 7:37 AM, Tim Cronin t...@outboundengine.com wrote:

 i understand that 1.3 is old and the 2 branch will be the way going
 forward but...

 this happens on our production server and really don't want to run beta
 code on it.

 i've played with the beta code and it requires code changes on our side as
 well.

 On Sun, Jul 5, 2015 at 10:25 AM, Thomas Vandahl t...@apache.org wrote:

 On 02.07.15 15:13, Tim Cronin wrote:
  JCS 1.3
 
  i periodically get the above error.
 
  what do i need to do to recover from this?
 

 First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
 numerous fixes and cleans up the lifecycle of most of the JCS manager
 classes. If that doesn't help, come back and ask again as this would
 require deeper digging.

 Bye, Thomas.

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

I added the following before calling the composite cache shutdown.
this should be called via the composite cache shutdown code i think

ThreadPoolManager poolMgr = ThreadPoolManager.getInstance();

for(String poolName : poolMgr.getPoolNames()) {
try {
poolMgr.getPool(poolName).shutdown();
} catch (Throwable t) {
LOGGER.warn(Failed to close pool  + poolName, t);
}
}


On Mon, Jul 6, 2015 at 9:33 AM, Tim Cronin t...@outboundengine.com wrote:

 MaxLifeSeconds has been changed to MaxLife, didn't find anything in the
 docs about this change.

 What is the proper way to shutdown jsc now?

 this i how it was recomended to it in 1.3
 CompositeCacheManager.getInstance().shutDown();

 I'm getting the following errors in tomcat when running against 2.0.

 2015-07-06 14:26:21,251 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 appears to have started a thread named [JCS-ThreadPoolManager-Thread-8] but
 has failed to stop it. This is very likely to create a memory leak.
 2015-07-06 14:26:21,252 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 appears to have started a thread named [JCS-ThreadPoolManager-Thread-9] but
 has failed to stop it. This is very likely to create a memory leak.
 2015-07-06 14:26:21,252 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 appears to have started a thread named [JCS-ThreadPoolManager-Thread-10]
 but has failed to stop it. This is very likely to create a memory leak.
 2015-07-06 14:26:21,253 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 appears to have started a thread named [JCS-ThreadPoolManager-Thread-11]
 but has failed to stop it. This is very likely to create a memory leak.
 2015-07-06 14:26:21,254 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 created a ThreadLocal with key of type
 [org.apache.log4j.helpers.ThreadLocalMap] (value
 [org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
 [java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
 the web application was stopped. Threads are going to be renewed over time
 to try and avoid a probable memory leak.
 2015-07-06 14:26:21,256 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 created a ThreadLocal with key of type
 [org.apache.log4j.helpers.ThreadLocalMap] (value
 [org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
 [java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
 the web application was stopped. Threads are going to be renewed over time
 to try and avoid a probable memory leak.
 2015-07-06 14:26:21,257 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 created a ThreadLocal with key of type
 [org.apache.log4j.helpers.ThreadLocalMap] (value
 [org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
 [java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
 the web application was stopped. Threads are going to be renewed over time
 to try and avoid a probable memory leak.
 2015-07-06 14:26:21,258 [localhost-startStop-2] ERROR
 org.apache.catalina.loader.WebappClassLoader- The web application []
 created a ThreadLocal with key of type
 [org.apache.log4j.helpers.ThreadLocalMap] (value
 [org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
 [java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
 the web application was stopped. Threads are going to be renewed over time
 to try and avoid a probable memory leak.


 On Mon, Jul 6, 2015 at 9:15 AM, Tim Cronin t...@outboundengine.com wrote:

 AuxDiskCache is throwing error that it can't create the directory but it
 already exists.

 localhost-startStop-1 2015-07-06 14:01:30,006 ERROR
 org.apache.commons.jcs.auxiliary.disk.AbstractDiskCacheAttributes - Failed
 to create directory C:\java\tomcat\temp\oeserver-cache

 I tested mkdirs and it follows what the javadoc says
 http://docs.oracle.com/javase/8/docs/api/java/io/File.html#mkdirs--.
 the code needs to check if the dir already exists:

 the function should be as follows:

 /**
  * Sets the diskPath attribute of the DiskCacheAttributes object
  * p
  * @param diskPath The new diskPath value
  */
 public void setDiskPath( File diskPath )
 {
 this.diskPath = diskPath;

 if(!this.diskPath.exists())
 {
 boolean result = this.diskPath.mkdirs();

 if (!result)
 {
 log.error(Failed to create directory  + diskPath);
 }
 }
 }



 On Mon, Jul 6, 2015 at 8:37 AM, Tim

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

AuxDiskCache is throwing error that it can't create the directory but it
already exists.

localhost-startStop-1 2015-07-06 14:01:30,006 ERROR
org.apache.commons.jcs.auxiliary.disk.AbstractDiskCacheAttributes - Failed
to create directory C:\java\tomcat\temp\oeserver-cache

I tested mkdirs and it follows what the javadoc says
http://docs.oracle.com/javase/8/docs/api/java/io/File.html#mkdirs--. the
code needs to check if the dir already exists:

the function should be as follows:

/**
 * Sets the diskPath attribute of the DiskCacheAttributes object
 * p
 * @param diskPath The new diskPath value
 */
public void setDiskPath( File diskPath )
{
this.diskPath = diskPath;

if(!this.diskPath.exists())
{
boolean result = this.diskPath.mkdirs();

if (!result)
{
log.error(Failed to create directory  + diskPath);
}
}
}



On Mon, Jul 6, 2015 at 8:37 AM, Tim Cronin t...@outboundengine.com wrote:

 is there any documentation on migrating from 1.3 to 2?

 the JCSAdmin.jsp the FAQ link is broken. moved due to package change
 http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log


 On Mon, Jul 6, 2015 at 7:37 AM, Tim Cronin t...@outboundengine.com wrote:

 i understand that 1.3 is old and the 2 branch will be the way going
 forward but...

 this happens on our production server and really don't want to run beta
 code on it.

 i've played with the beta code and it requires code changes on our side
 as well.

 On Sun, Jul 5, 2015 at 10:25 AM, Thomas Vandahl t...@apache.org wrote:

 On 02.07.15 15:13, Tim Cronin wrote:
  JCS 1.3
 
  i periodically get the above error.
 
  what do i need to do to recover from this?
 

 First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
 numerous fixes and cleans up the lifecycle of most of the JCS manager
 classes. If that doesn't help, come back and ask again as this would
 require deeper digging.

 Bye, Thomas.

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

MaxLifeSeconds has been changed to MaxLife, didn't find anything in the
docs about this change.

What is the proper way to shutdown jsc now?

this i how it was recomended to it in 1.3
CompositeCacheManager.getInstance().shutDown();

I'm getting the following errors in tomcat when running against 2.0.

2015-07-06 14:26:21,251 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
appears to have started a thread named [JCS-ThreadPoolManager-Thread-8] but
has failed to stop it. This is very likely to create a memory leak.
2015-07-06 14:26:21,252 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
appears to have started a thread named [JCS-ThreadPoolManager-Thread-9] but
has failed to stop it. This is very likely to create a memory leak.
2015-07-06 14:26:21,252 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
appears to have started a thread named [JCS-ThreadPoolManager-Thread-10]
but has failed to stop it. This is very likely to create a memory leak.
2015-07-06 14:26:21,253 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
appears to have started a thread named [JCS-ThreadPoolManager-Thread-11]
but has failed to stop it. This is very likely to create a memory leak.
2015-07-06 14:26:21,254 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
created a ThreadLocal with key of type
[org.apache.log4j.helpers.ThreadLocalMap] (value
[org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
[java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time
to try and avoid a probable memory leak.
2015-07-06 14:26:21,256 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
created a ThreadLocal with key of type
[org.apache.log4j.helpers.ThreadLocalMap] (value
[org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
[java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time
to try and avoid a probable memory leak.
2015-07-06 14:26:21,257 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
created a ThreadLocal with key of type
[org.apache.log4j.helpers.ThreadLocalMap] (value
[org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
[java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time
to try and avoid a probable memory leak.
2015-07-06 14:26:21,258 [localhost-startStop-2] ERROR
org.apache.catalina.loader.WebappClassLoader- The web application []
created a ThreadLocal with key of type
[org.apache.log4j.helpers.ThreadLocalMap] (value
[org.apache.log4j.helpers.ThreadLocalMap@52378d83]) and a value of type
[java.util.Hashtable] (value [{host=Tim-PC}]) but failed to remove it when
the web application was stopped. Threads are going to be renewed over time
to try and avoid a probable memory leak.


On Mon, Jul 6, 2015 at 9:15 AM, Tim Cronin t...@outboundengine.com wrote:

 AuxDiskCache is throwing error that it can't create the directory but it
 already exists.

 localhost-startStop-1 2015-07-06 14:01:30,006 ERROR
 org.apache.commons.jcs.auxiliary.disk.AbstractDiskCacheAttributes - Failed
 to create directory C:\java\tomcat\temp\oeserver-cache

 I tested mkdirs and it follows what the javadoc says
 http://docs.oracle.com/javase/8/docs/api/java/io/File.html#mkdirs--.
 the code needs to check if the dir already exists:

 the function should be as follows:

 /**
  * Sets the diskPath attribute of the DiskCacheAttributes object
  * p
  * @param diskPath The new diskPath value
  */
 public void setDiskPath( File diskPath )
 {
 this.diskPath = diskPath;

 if(!this.diskPath.exists())
 {
 boolean result = this.diskPath.mkdirs();

 if (!result)
 {
 log.error(Failed to create directory  + diskPath);
 }
 }
 }



 On Mon, Jul 6, 2015 at 8:37 AM, Tim Cronin t...@outboundengine.com wrote:

 is there any documentation on migrating from 1.3 to 2?

 the JCSAdmin.jsp the FAQ link is broken. moved due to package change
 http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log


 On Mon, Jul 6, 2015 at 7:37 AM, Tim Cronin t...@outboundengine.com
 wrote:

 i understand that 1.3 is old and the 2 branch will be the way going
 forward but...

 this happens on our production server and really don't want to run beta
 code on it.

 i've played with the beta code and it requires code changes on our side

Re: [JCS] Region No longer alive so returning false for key

[Tim Cronin]

thanks for the reply.

looking at trunk there's an added check isDirectory.

On Mon, Jul 6, 2015 at 9:30 AM, sebb seb...@gmail.com wrote:

 On 6 July 2015 at 15:15, Tim Cronin t...@outboundengine.com wrote:
  AuxDiskCache is throwing error that it can't create the directory but it
  already exists.
 
  localhost-startStop-1 2015-07-06 14:01:30,006 ERROR
  org.apache.commons.jcs.auxiliary.disk.AbstractDiskCacheAttributes -
 Failed
  to create directory C:\java\tomcat\temp\oeserver-cache
 
  I tested mkdirs and it follows what the javadoc says
  http://docs.oracle.com/javase/8/docs/api/java/io/File.html#mkdirs--.
 the
  code needs to check if the dir already exists:
 
  the function should be as follows:
 
  /**
   * Sets the diskPath attribute of the DiskCacheAttributes object
   * p
   * @param diskPath The new diskPath value
   */
  public void setDiskPath( File diskPath )
  {
  this.diskPath = diskPath;
 
  if(!this.diskPath.exists())
  {
  boolean result = this.diskPath.mkdirs();
 
  if (!result)
  {
  log.error(Failed to create directory  + diskPath);
  }
  }
  }

 That can still theoretically fail if something else creates the
 directory in the meantime.
 Also exists() will return true for a file as well as a directory.

 Please see:

 https://issues.apache.org/jira/browse/JCI-67

 
 
 
  On Mon, Jul 6, 2015 at 8:37 AM, Tim Cronin t...@outboundengine.com
 wrote:
 
  is there any documentation on migrating from 1.3 to 2?
 
  the JCSAdmin.jsp the FAQ link is broken. moved due to package change
  
 http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log
 
 
 
  On Mon, Jul 6, 2015 at 7:37 AM, Tim Cronin t...@outboundengine.com
 wrote:
 
  i understand that 1.3 is old and the 2 branch will be the way going
  forward but...
 
  this happens on our production server and really don't want to run beta
  code on it.
 
  i've played with the beta code and it requires code changes on our side
  as well.
 
  On Sun, Jul 5, 2015 at 10:25 AM, Thomas Vandahl t...@apache.org wrote:
 
  On 02.07.15 15:13, Tim Cronin wrote:
   JCS 1.3
  
   i periodically get the above error.
  
   what do i need to do to recover from this?
  
 
  First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
  numerous fixes and cleans up the lifecycle of most of the JCS manager
  classes. If that doesn't help, come back and ask again as this would
  require deeper digging.
 
  Bye, Thomas.
 
  -
  To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
  For additional commands, e-mail: user-h...@commons.apache.org
 
 
 
 

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[sebb]

On 6 July 2015 at 15:15, Tim Cronin t...@outboundengine.com wrote:
 AuxDiskCache is throwing error that it can't create the directory but it
 already exists.

 localhost-startStop-1 2015-07-06 14:01:30,006 ERROR
 org.apache.commons.jcs.auxiliary.disk.AbstractDiskCacheAttributes - Failed
 to create directory C:\java\tomcat\temp\oeserver-cache

 I tested mkdirs and it follows what the javadoc says
 http://docs.oracle.com/javase/8/docs/api/java/io/File.html#mkdirs--. the
 code needs to check if the dir already exists:

 the function should be as follows:

 /**
  * Sets the diskPath attribute of the DiskCacheAttributes object
  * p
  * @param diskPath The new diskPath value
  */
 public void setDiskPath( File diskPath )
 {
 this.diskPath = diskPath;

 if(!this.diskPath.exists())
 {
 boolean result = this.diskPath.mkdirs();

 if (!result)
 {
 log.error(Failed to create directory  + diskPath);
 }
 }
 }

That can still theoretically fail if something else creates the
directory in the meantime.
Also exists() will return true for a file as well as a directory.

Please see:

https://issues.apache.org/jira/browse/JCI-67




 On Mon, Jul 6, 2015 at 8:37 AM, Tim Cronin t...@outboundengine.com wrote:

 is there any documentation on migrating from 1.3 to 2?

 the JCSAdmin.jsp the FAQ link is broken. moved due to package change
 http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/admin/JCSAdmin.jsp?view=log


 On Mon, Jul 6, 2015 at 7:37 AM, Tim Cronin t...@outboundengine.com wrote:

 i understand that 1.3 is old and the 2 branch will be the way going
 forward but...

 this happens on our production server and really don't want to run beta
 code on it.

 i've played with the beta code and it requires code changes on our side
 as well.

 On Sun, Jul 5, 2015 at 10:25 AM, Thomas Vandahl t...@apache.org wrote:

 On 02.07.15 15:13, Tim Cronin wrote:
  JCS 1.3
 
  i periodically get the above error.
 
  what do i need to do to recover from this?
 

 First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
 numerous fixes and cleans up the lifecycle of most of the JCS manager
 classes. If that doesn't help, come back and ask again as this would
 require deeper digging.

 Bye, Thomas.

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Region No longer alive so returning false for key

[Thomas Vandahl]

On 02.07.15 15:13, Tim Cronin wrote:
 JCS 1.3
 
 i periodically get the above error.
 
 what do i need to do to recover from this?
 

First of all I'd suggest to try out commons-jcs 2.0-beta1. It contains
numerous fixes and cleans up the lifecycle of most of the JCS manager
classes. If that doesn't help, come back and ask again as this would
require deeper digging.

Bye, Thomas.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

JCS Region No longer alive so returning false for key

[Tim Cronin]

JCS 1.3

i periodically get the above error.

what do i need to do to recover from this?

Re: [JCS] Error starting web service with JCS on WAS 8.5.5 (Linux only)

[Thomas Vandahl]

Hi Barry,

On 01.06.15 02:09, Barry Lulas wrote:
 Hello,
 
 I have created a web service for WebSphere that uses a basic JCS 
 configuration.  When I package and deploy for WAS under Windows on my local 
 machine I have no issues.  When I deploy that same .ear file to my WAS 
 running on Linux I get the following exception when I try to start my service 
 in the WAS console:
 
 [6/1/15 2:00:51:875 CEST] 0093 BeansDeployer E BeansDeployer deploy 
 java.lang.NullPointerException at 
 java.util.Properties.load(Properties.java:356) at 
 org.apache.commons.jcs.jcache.JCSCachingManager.readConfig(JCSCachingManager.java:95)
  at 
 org.apache.commons.jcs.jcache.JCSCachingManager.init(JCSCachingManager.java:70)
  at 
 org.apache.commons.jcs.jcache.JCSCachingProvider.getCacheManager(JCSCachingProvider.java:56)
  at 
 org.apache.commons.jcs.jcache.extras.cdi.ExtraJCacheExtension.addJCacheBeans(ExtraJCacheExtension.java:81)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94) 
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
  at java.lang.reflect.Method.invoke(Method.java:619) at 
 org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:285)
  at 
 org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:455)
  at or
 g
.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:452) 
at 
org.apache.webbeans.config.BeansDeployer.fireAfterBeanDiscoveryEvent(BeansDeployer.java:269)
 at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:180) at 
org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:124)
 at 
org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:78)
 at 
com.ibm.ws.webbeans.common.CommonLifeCycle.startApplication(CommonLifeCycle.java:106)
 at 
com.ibm.ws.webbeans.services.JCDIServletContainerInitializer.onStartup(JCDIServletContainerInitializer.java:85)
 at 
com.ibm.ws.webcontainer.webapp.WebAppImpl.initializeServletContainerInitializers(WebAppImpl.java:613)
 at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:409) 
at 
com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
 at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHost
 I
mpl.java:169) at 
com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:749) at 
com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:634)
 at 
com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:426)
 at 
com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:718)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1177)
 at 
com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1370)
 at 
com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:639)
 at 
com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:968)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:776)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1379)
 at com.ibm.ws.runtime.component.ApplicationMgrImpl.start
 (
ApplicationMgrImpl.java:2189) at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:435)
 at 
com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:378)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$500(CompositionUnitMgrImpl.java:126)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl$1.run(CompositionUnitMgrImpl.java:653)
 at 
com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5477) 
at 
com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5603)
 at 
com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255) 
at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:667)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:611)
 at com.ibm.ws.runtime.compo
 n
ent.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1269) at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
 at java.lang.reflect.Method.invoke(Method.java:619) at 
sun.reflect.misc.Trampoline.invoke(MethodUtil.java:87) at 
sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source

[JCS] Error starting web service with JCS on WAS 8.5.5 (Linux only)

[Barry Lulas]

Hello,

I have created a web service for WebSphere that uses a basic JCS configuration. 
 When I package and deploy for WAS under Windows on my local machine I have no 
issues.  When I deploy that same .ear file to my WAS running on Linux I get the 
following exception when I try to start my service in the WAS console:

[6/1/15 2:00:51:875 CEST] 0093 BeansDeployer E BeansDeployer deploy 
java.lang.NullPointerException at 
java.util.Properties.load(Properties.java:356) at 
org.apache.commons.jcs.jcache.JCSCachingManager.readConfig(JCSCachingManager.java:95)
 at 
org.apache.commons.jcs.jcache.JCSCachingManager.init(JCSCachingManager.java:70)
 at 
org.apache.commons.jcs.jcache.JCSCachingProvider.getCacheManager(JCSCachingProvider.java:56)
 at 
org.apache.commons.jcs.jcache.extras.cdi.ExtraJCacheExtension.addJCacheBeans(ExtraJCacheExtension.java:81)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
 at java.lang.reflect.Method.invoke(Method.java:619) at 
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:285)
 at 
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:455)
 at 
org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:452)
 at 
org.apache.webbeans.config.BeansDeployer.fireAfterBeanDiscoveryEvent(BeansDeployer.java:269)
 at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:180) at 
org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:124)
 at 
org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:78)
 at 
com.ibm.ws.webbeans.common.CommonLifeCycle.startApplication(CommonLifeCycle.java:106)
 at 
com.ibm.ws.webbeans.services.JCDIServletContainerInitializer.onStartup(JCDIServletContainerInitializer.java:85)
 at 
com.ibm.ws.webcontainer.webapp.WebAppImpl.initializeServletContainerInitializers(WebAppImpl.java:613)
 at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:409) 
at 
com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
 at 
com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169)
 at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:749) 
at 
com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:634)
 at 
com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:426)
 at 
com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:718)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1177)
 at 
com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1370)
 at 
com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:639)
 at 
com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:968)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:776)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1379)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2189)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:435)
 at 
com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:378)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$500(CompositionUnitMgrImpl.java:126)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl$1.run(CompositionUnitMgrImpl.java:653)
 at 
com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5477) 
at 
com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5603)
 at 
com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255) 
at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:667)
 at 
com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:611)
 at 
com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1269)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
 at java.lang.reflect.Method.invoke(Method.java:619) at 
sun.reflect.misc.Trampoline.invoke(MethodUtil.java:87) at 
sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55

Re: can # sometimes be ignored by JCS

[arnout cator]

sorry, i showed a Spring bean configuration variable. This Spring bean
works with a jar deployed in WebLogic to render a folder custom for each
web application. This obviously is not a cache.ccf configuration item.
I think I feel that the problem has more to do with multiple JCS instances
in multiple nodes invalidating the same cache folder due to some issue in
the product that deploys and runs the JCS.



On Thu, Mar 19, 2015 at 9:59 PM, arnout cator arnout.ca...@gmail.com
wrote:

 Hi, thanks a lot for taking some time to look at my problem. I have set up
 a reproduction environment for my customer's production installation.

 I have done some deploying and thinking and I think this is what I believe
 might help understand a bit more what is going on:

 The customer has BEA Weblogic and they have multiple instances of the
 site. In cache.ccf they have a weblogic variable set in the invalidation
 monitor path:

   !-- invalidation monitor --
   bean id=runtime.cache.InvalidationFileDirectory
 factory-bean=util.ContentResourceFactory
 factory-method=getFile
 constructor-argvalue/sites/${atg.dynamo.server.name
 }/value/constructor-arg
   /bean

 Now, what I believe is the case is that the problem only occurs when the
 pages are in auxiliary disk. Then when the customer has a code release,
 then they restart BEA when updating the application where JCS is sitting.
 Then they experience the issue that the cached object is not deleted from
 disk from various but not all weblogic managed servers (web applications).
 So, my question then is: is this variable then not read in some cases at
 random?

 This is what the customer's deployment manager said:

 *Additional information:  *When it fails the deployment contains an EAR
 file and the Shared Libraries that are started in the WebLogic instance are
 getting a new jar file pushed to the server.  WebLogic is using this as a
 shared library on start up.  After this happens we push content into the
 web application.  Sometimes the content shows up and sometimes it does not.

 * Happens 5 or 6 times over last 3 months

 * More frequently seeing issues where it caused a problem

 * Appears the cache file is not being invalidated automatically.

 * We push to a preview environment and works fine, then push to Production
 and it fails AND we've seen push to the preview environment fail but push
 to Production works just fine.  Unable to identify why unless it's a timing
 issue we're not aware of or maybe a process is not being done?




 On Fri, Mar 13, 2015 at 7:04 AM, Thomas Vandahl t...@apache.org wrote:

 On 10.03.15 23:12, arnout cator wrote:
  Hi, I have the situation that I have 10+ web apps using JCS. I have
 this in
  cache.ccf:
 
   ###
  # Stylesheet settings
  ###
  #disable disk caching if WAS doesn't provide serialized dom
  #jcs.region.stylesheet=
  jcs.region.stylesheet=DC
  jcs.region.stylesheet.cacheattributes.MaxObjects=128
  ###
 
  I have no issues with all other regions defined, but I have a problem
 that
  sometimes amongst the 10 web apps, not consistently the same web apps,
 the
  stylesheet cache is not invalidated when I do a code release to the 10
  apps. I get over it by removing all disk cache files and restarting the
 app
  server.
 
  I wondered if it is possible that JCS sometimes reads the # line. Can
 that
  be causing this?

 This is very unlikely because JCS uses the standard JDK methods to read
 its configuration files.

  If not, why would just the stylesheet disk cache file not be invalidated
  sometimes? Did anyone in JCS user world see a similar event?

 I'm not sure I understand your environment correctly. Do you generally
 expect the cache contents to survive an application restart or not?

 The disk cache will persist keys and data during an orderly shutdown so
 that they can be reloaded on restart. This normally requires
 JCSServletContextListener to be present in the web application. However
 JCS also registers a shutdown hook to the JVM which may or may not work
 in an app-server environment. This would explain the inconsistent
 behavior you are experiencing.

 Bye, Thomas.



 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: can # sometimes be ignored by JCS

[arnout cator]

Hi, thanks a lot for taking some time to look at my problem. I have set up
a reproduction environment for my customer's production installation.

I have done some deploying and thinking and I think this is what I believe
might help understand a bit more what is going on:

The customer has BEA Weblogic and they have multiple instances of the site.
In cache.ccf they have a weblogic variable set in the invalidation monitor
path:

  !-- invalidation monitor --
  bean id=runtime.cache.InvalidationFileDirectory
factory-bean=util.ContentResourceFactory
factory-method=getFile
constructor-argvalue/sites/${atg.dynamo.server.name
}/value/constructor-arg
  /bean

Now, what I believe is the case is that the problem only occurs when the
pages are in auxiliary disk. Then when the customer has a code release,
then they restart BEA when updating the application where JCS is sitting.
Then they experience the issue that the cached object is not deleted from
disk from various but not all weblogic managed servers (web applications).
So, my question then is: is this variable then not read in some cases at
random?

This is what the customer's deployment manager said:

*Additional information:  *When it fails the deployment contains an EAR
file and the Shared Libraries that are started in the WebLogic instance are
getting a new jar file pushed to the server.  WebLogic is using this as a
shared library on start up.  After this happens we push content into the
web application.  Sometimes the content shows up and sometimes it does not.

* Happens 5 or 6 times over last 3 months

* More frequently seeing issues where it caused a problem

* Appears the cache file is not being invalidated automatically.

* We push to a preview environment and works fine, then push to Production
and it fails AND we've seen push to the preview environment fail but push
to Production works just fine.  Unable to identify why unless it's a timing
issue we're not aware of or maybe a process is not being done?




On Fri, Mar 13, 2015 at 7:04 AM, Thomas Vandahl t...@apache.org wrote:

 On 10.03.15 23:12, arnout cator wrote:
  Hi, I have the situation that I have 10+ web apps using JCS. I have this
 in
  cache.ccf:
 
   ###
  # Stylesheet settings
  ###
  #disable disk caching if WAS doesn't provide serialized dom
  #jcs.region.stylesheet=
  jcs.region.stylesheet=DC
  jcs.region.stylesheet.cacheattributes.MaxObjects=128
  ###
 
  I have no issues with all other regions defined, but I have a problem
 that
  sometimes amongst the 10 web apps, not consistently the same web apps,
 the
  stylesheet cache is not invalidated when I do a code release to the 10
  apps. I get over it by removing all disk cache files and restarting the
 app
  server.
 
  I wondered if it is possible that JCS sometimes reads the # line. Can
 that
  be causing this?

 This is very unlikely because JCS uses the standard JDK methods to read
 its configuration files.

  If not, why would just the stylesheet disk cache file not be invalidated
  sometimes? Did anyone in JCS user world see a similar event?

 I'm not sure I understand your environment correctly. Do you generally
 expect the cache contents to survive an application restart or not?

 The disk cache will persist keys and data during an orderly shutdown so
 that they can be reloaded on restart. This normally requires
 JCSServletContextListener to be present in the web application. However
 JCS also registers a shutdown hook to the JVM which may or may not work
 in an app-server environment. This would explain the inconsistent
 behavior you are experiencing.

 Bye, Thomas.



 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: can # sometimes be ignored by JCS

[Thomas Vandahl]

On 10.03.15 23:12, arnout cator wrote:
 Hi, I have the situation that I have 10+ web apps using JCS. I have this in
 cache.ccf:
 
  ###
 # Stylesheet settings
 ###
 #disable disk caching if WAS doesn't provide serialized dom
 #jcs.region.stylesheet=
 jcs.region.stylesheet=DC
 jcs.region.stylesheet.cacheattributes.MaxObjects=128
 ###
 
 I have no issues with all other regions defined, but I have a problem that
 sometimes amongst the 10 web apps, not consistently the same web apps, the
 stylesheet cache is not invalidated when I do a code release to the 10
 apps. I get over it by removing all disk cache files and restarting the app
 server.
 
 I wondered if it is possible that JCS sometimes reads the # line. Can that
 be causing this?

This is very unlikely because JCS uses the standard JDK methods to read
its configuration files.

 If not, why would just the stylesheet disk cache file not be invalidated
 sometimes? Did anyone in JCS user world see a similar event?

I'm not sure I understand your environment correctly. Do you generally
expect the cache contents to survive an application restart or not?

The disk cache will persist keys and data during an orderly shutdown so
that they can be reloaded on restart. This normally requires
JCSServletContextListener to be present in the web application. However
JCS also registers a shutdown hook to the JVM which may or may not work
in an app-server environment. This would explain the inconsistent
behavior you are experiencing.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

can # sometimes be ignored by JCS

[arnout cator]

Hi, I have the situation that I have 10+ web apps using JCS. I have this in
cache.ccf:

 ###
# Stylesheet settings
###
#disable disk caching if WAS doesn't provide serialized dom
#jcs.region.stylesheet=
jcs.region.stylesheet=DC
jcs.region.stylesheet.cacheattributes.MaxObjects=128
###

I have no issues with all other regions defined, but I have a problem that
sometimes amongst the 10 web apps, not consistently the same web apps, the
stylesheet cache is not invalidated when I do a code release to the 10
apps. I get over it by removing all disk cache files and restarting the app
server.

I wondered if it is possible that JCS sometimes reads the # line. Can that
be causing this?
If not, why would just the stylesheet disk cache file not be invalidated
sometimes? Did anyone in JCS user world see a similar event?

Re: [JCS] Dynamic Cache Expiration on get

[Thomas Vandahl]

Hi Jan,

On 16.01.15 17:12, Jan Swaelens wrote:
 Hello,
 
 I have a region set up to expire its data lets say after 60 seconds.
 There's also a shrink thread running every 100 seconds.
 
 We add an event handler when storing certain items, in this handler we
 implement some logic to re-insert the expired item on the same key.
 
 The problem is, when an item expires 'on get' the expiry handler fires
 async and we can't get the updated value in the requesting thread.
 
 Is it possible to act before the item is actually removed to take the
 keep/toss away call instead of re-inserting it? Any other suggestions for
 solving this pattern?

I understand you want to update your items when they expire, right? This
is normally done in the requesting thread, when the cache returns null
for the requested key. In my experience, this absolutely makes sense
because you will have connections, access rights and stuff available
there. This is usually not the case in a background thread.

That said, I'd like to add that you may add your own implementation of a
memory cache with the desired expiry behavior. See the way the key lists
are handled in LRUMemoryCache and MRUMemoryCache.

Bye, Thomas.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] disk persistence - same conf file, different results

[Tim Cronin]

Any ETA on when JCS 2.0 will be released?

On Mon, Nov 17, 2014 at 2:07 AM, Thomas Vandahl t...@apache.org wrote:

 On 14.11.14 19:14, joao tiago a. m. viegas wrote:
  thank you Thomas, but is there anyway to persist and reload the cache
 with
  1.3?

 Unfortunately not. Sorry. JCS 1.3 is full of static classes which are
 not re-initialized properly. I tried to address most of these problems
 in 2.0, but still a few remain.

 Bye, Thomas


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] disk persistence - same conf file, different results

[Thomas Vandahl]

On 17.11.14 14:49, Tim Cronin wrote:
 Any ETA on when JCS 2.0 will be released?

There is a vote running currently for 2.0 alpha 1.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] disk persistence - same conf file, different results

[Gary Gregory]

There is a mismatch in communication here:

What I see is a VOTE to release the current release JCS candidate candidate
labeled 2.0-RC1 as 2.0.

There is no alpha labeled software released or being released. What is in
trunk is just the latest.

Gary

On Mon, Nov 17, 2014 at 11:24 AM, Thomas Vandahl t...@apache.org wrote:

 On 17.11.14 14:49, Tim Cronin wrote:
  Any ETA on when JCS 2.0 will be released?

 There is a vote running currently for 2.0 alpha 1.

 Bye, Thomas.



 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [JCS] disk persistence - same conf file, different results

[Duncan Jones]

Hi João,

This is probably best addressed to the Commons user mailing list. I've
BCC'd the issues list so people know where this email thread went to.
Please also prefix the Commons component into the subject line (in
this case [JCS], which I've done for you).

Duncan

On 14 November 2014 11:25, joao tiago a. m. viegas jtvie...@gmail.com wrote:
 hello,

 I've been testing jcs, I want a cache that allows me to save all the
 eleemnts when I shutsown gracefully, and later when I create a new instance
 of the same cache I can get those same objects I had before in the first
 encarnation of that same cache.
 I made this test and I'm actually using two identical confs, but for some
 reason I'm getting different results.
 Could you please help me understanding why?

 tests are:

 private static final String[] configs = new String[]
 {ObjectPersistingInMemoryAndDisk_x1.ccf,
 ObjectPersistingInMemoryAndDisk_x2.ccf};

 private static final String[] expecteds = new String[] {null, null};

 private static final String region = OUR_REGION;
 private static final String key=key, value=value;

 .
 .

 @Test
 public void testObjectPersistingInMemoryAndDisk_1() throws Exception{

 performObjectPersistingInMemoryAndDisk(JCS_CONFIG_DIR + configs[0],
 expecteds[0]);
 }

 @Test
 public void testObjectPersistingInMemoryAndDisk_2() throws Exception{

 performObjectPersistingInMemoryAndDisk(JCS_CONFIG_DIR + configs[1],
 expecteds[1]);
 }

 private void performObjectPersistingInMemoryAndDisk(String configFile,
 String expected) throws Exception{


 System.out.println(---);

 System.out.println(testing with config file: + configFile);
 JCS.setConfigFilename(configFile);
 JCS cache = JCS.getInstance(region);
 cache.put(key, value);
 Thread.sleep(5000);
 Assert.assertNotNull(cache.get(key));
 Assert.assertEquals(value, cache.get(key));

 IStats stats = cache.getStatistics().getAuxiliaryCacheStats()[0];

 cache.freeMemoryElements(Integer.parseInt(stats.getStatElements()[0].getData()));
 Thread.sleep(5000);
 Assert.assertNotNull(cache.get(key));
 Assert.assertEquals(value, cache.get(key));
 System.out.println(cache.getStats());
 CompositeCacheManager.getInstance().shutDown();

 Thread.sleep(5000);

 JCS.setConfigFilename(configFile);
 cache = JCS.getInstance(region);
 Assert.assertEquals(expected, cache.get(key));

 System.out.println(cache.getStats());
 cache.clear();
 cache.dispose();
 CompositeCacheManager.getInstance().shutDown();
 }


 ...the confs are:

 -- ObjectPersistingInMemoryAndDisk_x1.ccf --
 # DEFAULT CACHE REGION
 jcs.default=DISK_REGION
 jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
 jcs.default.cacheattributes.MaxObjects=1000
 jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
 #jcs.default.cacheattributes.DiskUsagePatternName=UPDATE

 jcs.region.OUR_REGION=DISK_REGION
 jcs.region.OUR_REGION.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
 jcs.region.OUR_REGION.cacheattributes.MaxObjects=1000
 jcs.region.OUR_REGION.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
 jcs.region.OUR_REGION.cacheattributes.UseMemoryShrinker=true
 jcs.region.OUR_REGION.cacheattributes.MaxMemoryIdleTimeSeconds=3600
 jcs.region.OUR_REGION.cacheattributes.ShrinkerIntervalSeconds=60
 jcs.region.OUR_REGION.cacheattributes.MaxSpoolPerRun=500
 jcs.region.OUR_REGION.elementattributes=org.apache.jcs.engine.ElementAttributes
 jcs.region.OUR_REGION.elementattributes.IsEternal=false

 jcs.auxiliary.DISK_REGION=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
 jcs.auxiliary.DISK_REGION.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
 jcs.auxiliary.DISK_REGION.attributes.DiskPath=/tmp/jcs/cache
 jcs.auxiliary.DISK_REGION.attributes.maxKeySize=10


 -- ObjectPersistingInMemoryAndDisk_x2.ccf --
 # DEFAULT CACHE REGION
 jcs.default=DISK_REGION
 jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
 jcs.default.cacheattributes.MaxObjects=1000
 jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
 #jcs.default.cacheattributes.DiskUsagePatternName=UPDATE

 jcs.region.OUR_REGION=DISK_REGION
 jcs.region.OUR_REGION.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
 jcs.region.OUR_REGION.cacheattributes.MaxObjects=1000
 jcs.region.OUR_REGION.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
 jcs.region.OUR_REGION.cacheattributes.UseMemoryShrinker=true
 jcs.region.OUR_REGION.cacheattributes.MaxMemoryIdleTimeSeconds=3600
 jcs.region.OUR_REGION.cacheattributes.ShrinkerIntervalSeconds=60
 jcs.region.OUR_REGION.cacheattributes.MaxSpoolPerRun=500
 jcs.region.OUR_REGION.elementattributes=org.apache.jcs.engine.ElementAttributes
 jcs.region.OUR_REGION.elementattributes.IsEternal=false

 jcs.auxiliary.DISK_REGION

Re: [JCS] disk persistence - same conf file, different results

[joao tiago a. m. viegas]

I'll probably reformat this question in a simpler way.

The goal is to persist an element and retrieve it after restart of a new vm.

so simplifying the test:

 private void performSimplerObjectPersistingInMemoryAndDisk(String
 configFile, String expected) throws Exception {


 String key = key, value = value;

JCS.setConfigFilename(configFile);
 JCS cache = JCS.getInstance(OUR_REGION);

cache.put(key, value);
 Thread.sleep(5000);
 Assert.assertNotNull(cache.get(key));
 Assert.assertEquals(value, cache.get(key));
 System.out.println(cache.getStats());
 CompositeCacheManager.getInstance().shutDown();
 Thread.sleep(5000);
 JCS.setConfigFilename(configFile);
 cache = JCS.getInstance(OUR_REGION);
 Assert.assertEquals(expected, cache.get(key));
 System.out.println(cache.getStats());
 }



...I've been trying this test with a set of configuration files, last one:

# DEFAULT CACHE REGION
 jcs.default=DISK_REGION
 jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
 jcs.default.cacheattributes.MaxObjects=1000

 jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
 jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
 jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
 jcs.default.elementattributes.IsSpool=true
 jcs.default.elementattributes.IsRemote=false
 jcs.default.elementattributes.IsLateral=false
 jcs.default.elementattributes.IsEternal=true
 # CUSTOM REGION
 jcs.region.OUR_REGION=DISK_REGION

 jcs.region.OUR_REGION.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
 jcs.region.OUR_REGION.cacheattributes.MaxObjects=0

 jcs.region.OUR_REGION.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
 jcs.region.OUR_REGION.cacheattributes.UseMemoryShrinker=true
 jcs.region.OUR_REGION.cacheattributes.MaxMemoryIdleTimeSeconds=3600
 jcs.region.OUR_REGION.cacheattributes.ShrinkerIntervalSeconds=60
 jcs.region.OUR_REGION.cacheattributes.MaxSpoolPerRun=500

 jcs.region.OUR_REGION.elementattributes=org.apache.jcs.engine.ElementAttributes
 jcs.region.OUR_REGION.elementattributes.IsEternal=true
 jcs.region.OUR_REGION.elementattributes.IsSpool=true
 jcs.region.OUR_REGION.elementattributes.IsRemote=false
 jcs.region.OUR_REGION.elementattributes.IsLateral=false
 jcs.region.OUR_REGION.cacheattributes.DiskUsagePatternName=UPDATE
 # AUXILIARY

 jcs.auxiliary.DISK_REGION=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory

 jcs.auxiliary.DISK_REGION.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
 jcs.auxiliary.DISK_REGION.attributes.DiskPath=/tmp/jcs/cache
 jcs.auxiliary.DISK_REGION.attributes.maxKeySize=10
 jcs.auxiliary.DISK_REGION.attributes.OptimizeOnShutdown=true
 jcs.auxiliary.DISK_REGION.attributes.MaxPurgatorySize=8
 jcs.auxiliary.DISK_REGION.attributes.OptimizeAtRemoveCount=30
 jcs.auxiliary.DISK_REGION.attributes.MaxRecycleBinSize=7500
 jcs.auxiliary.DISK_REGION.attributes.OptimizeOnShutdown=true


anyone have an idea or example of how this could work?

thanking you in advance

os melhores cumprimentos / best regards / Mit freundlichen Grüssen / Saludos

joão tiago viegas

On 14 November 2014 11:56, Duncan Jones djo...@apache.org wrote:

 Hi João,

 This is probably best addressed to the Commons user mailing list. I've
 BCC'd the issues list so people know where this email thread went to.
 Please also prefix the Commons component into the subject line (in
 this case [JCS], which I've done for you).

 Duncan

 On 14 November 2014 11:25, joao tiago a. m. viegas jtvie...@gmail.com
 wrote:
  hello,
 
  I've been testing jcs, I want a cache that allows me to save all the
  eleemnts when I shutsown gracefully, and later when I create a new
 instance
  of the same cache I can get those same objects I had before in the first
  encarnation of that same cache.
  I made this test and I'm actually using two identical confs, but for some
  reason I'm getting different results.
  Could you please help me understanding why?
 
  tests are:
 
  private static final String[] configs = new String[]
  {ObjectPersistingInMemoryAndDisk_x1.ccf,
  ObjectPersistingInMemoryAndDisk_x2.ccf};
 
  private static final String[] expecteds = new String[] {null, null};
 
  private static final String region = OUR_REGION;
  private static final String key=key, value=value;
 
  .
  .
 
  @Test
  public void testObjectPersistingInMemoryAndDisk_1() throws Exception{
 
  performObjectPersistingInMemoryAndDisk(JCS_CONFIG_DIR + configs[0],
  expecteds[0]);
  }
 
  @Test
  public void testObjectPersistingInMemoryAndDisk_2() throws Exception{
 
  performObjectPersistingInMemoryAndDisk(JCS_CONFIG_DIR + configs[1],
  expecteds[1]);
  }
 
  private void performObjectPersistingInMemoryAndDisk(String configFile,
  String expected) throws Exception{
 
 
 
 System.out.println(---);
 
  System.out.println(testing

Re: [JCS] disk persistence - same conf file, different results

[Thomas Vandahl]

On 14.11.14 13:47, joao tiago a. m. viegas wrote:
 I'll probably reformat this question in a simpler way.
 
 The goal is to persist an element and retrieve it after restart of a new vm.

The disk caches persist the keys when the cache is shut down. So you
should call CompositeCacheManager.getInstance().shutDown(); before your
application ends.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] disk persistence - same conf file, different results

[Thomas Vandahl]

On 14.11.14 18:03, Thomas Vandahl wrote:
 On 14.11.14 13:47, joao tiago a. m. viegas wrote:
 I'll probably reformat this question in a simpler way.

 The goal is to persist an element and retrieve it after restart of a new vm.
 
 The disk caches persist the keys when the cache is shut down. So you
 should call CompositeCacheManager.getInstance().shutDown(); before your
 application ends.
 

To be precise: You cannot shut down the cache in the middle of a process
because with jcs 1.3 the cache will not re-initialize correctly. This
should have been fixed to a large extent in jcs 2.0 but still needs
further work.

Bye, Thomas


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] disk persistence - same conf file, different results

[joao tiago a. m. viegas]

thank you Thomas, but is there anyway to persist and reload the cache with
1.3?


os melhores cumprimentos / best regards / Mit freundlichen Grüssen / Saludos

joão tiago viegas

On 14 November 2014 17:29, Thomas Vandahl t...@apache.org wrote:

 On 14.11.14 18:03, Thomas Vandahl wrote:
  On 14.11.14 13:47, joao tiago a. m. viegas wrote:
  I'll probably reformat this question in a simpler way.
 
  The goal is to persist an element and retrieve it after restart of a
 new vm.
 
  The disk caches persist the keys when the cache is shut down. So you
  should call CompositeCacheManager.getInstance().shutDown(); before your
  application ends.
 

 To be precise: You cannot shut down the cache in the middle of a process
 because with jcs 1.3 the cache will not re-initialize correctly. This
 should have been fixed to a large extent in jcs 2.0 but still needs
 further work.

 Bye, Thomas


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: JCS Cache behaviour question

[Thomas Vandahl]

On 24.10.14 00:48, arnout cator wrote:
 Can someone tell me how JCS works to show Auxiliary hits and no data
 file size nor key size, considering my setup? 

JCS keeps the disk cache files open during operation. So depending on
your operating system, you may not see updates of the directory entries
of these files. If you shut down JCS properly, the files will be closed
and the size should reflect the actual content.

Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Remote Cache causes Tomcat Windows Service to hang on shutdown.

[Thomas Vandahl]

On 06.10.14 15:55, Art Thursland wrote:
 Here is the part of the log written during shutdown:
 
 09:42:18,899 INFO  [RemoteCacheStartupServlet] Shutting down remote cache
 09:42:18,903 INFO  [CompositeCache] In DISPOSE, [tokenCache] fromRemote 
 [false]
 Region Name = tokenCache
 HitCountRam = 0
 HitCountAux = 0
 ---LRU Memory Cache
 List Size = 0
 Map Size = 0
 Put Count = 0
 Hit Count = 0
 Miss Count = 0
 09:42:18,903 INFO  [CompositeCache] In DISPOSE, [tokenCache] disposing of 
 memory cache.
 09:42:18,903 INFO  [AbstractMemoryCache] Memory Cache dispose called.  
 Shutting down shrinker thread if it is running.
 

Could you please switch the log level to DEBUG and post the log section?

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: JCS cache benchmarking for performance

[Thomas Vandahl]

On 09.10.14 16:02, arnout cator wrote:
 What would be the best practice in monitoring JCS caching performance for
 production web applications? I am looking for a way to collect data and
 then give advice on sizing of web applications that heavily use JCS for
 caching of java objects.

Which version do you use?

If 1.3, then your best bet would be JCSAdminBean or JCSAdmin.jsp,
respectively. It can tell you about the filling level as well as hits,
fails, auxiliary hits and fails and much more. It will not give you
timing information, however.

In 2.0, you may use JMX to access this information.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

JCS cache benchmarking for performance

[arnout cator]

Hi,

I have the following question:

What would be the best practice in monitoring JCS caching performance for
production web applications? I am looking for a way to collect data and
then give advice on sizing of web applications that heavily use JCS for
caching of java objects.

Re: [JCS] event handler callback not getting called

[Thomas Vandahl]

On 19.03.14 18:25, sebb wrote:
 But when an element is evicted from JCS cache im not getting any callback
 though i know cache eviction has happened for element for sure.

 Is there anything else that i need to do apart from what is mentioned in
 the example.

Would you please open an issue in JIRA with this sample code and the
related configuration attached?

Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[JCS] event handler callback not getting called

[sebb]

Adding component marker (please remember to add the subject marker in future.
This list handles user questions for all the Commons components so it
is important that the specific component is identified.

(sorry, cannot help with the question itself)

On 18 March 2014 11:29, pushkar priyadarshi
priyadarshi.push...@gmail.com wrote:
 Hi ,

 I have used the code from example at
 http://commons.apache.org/proper/commons-jcs/ElementEventHandling.html for
 event handling.

 But when an element is evicted from JCS cache im not getting any callback
 though i know cache eviction has happened for element for sure.

 Is there anything else that i need to do apart from what is mentioned in
 the example.

 CacheAccessString, String jcs = JCS.getInstance( myregion );

 . . .

 MyEventHandler meh = new MyEventHandler();

 // this should add the event handler to all items as
 //they are created.
 // jcs.getDefaultElementAttributes returns a copy not a reference
 IElementAttributes attributes = jcs.getDefaultElementAttributes();
 attributes.addElementEventHandler( meh );
 jcs.setDefaultElementAttributes( attributes );

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Version 2 release

[Mat Jaggard]

OK, when I get some more time, I'll try to do that. Is there a version 2 of
the  documentation anywhere? At the moment, most pages seem to apply to
version 1.
On 8 Feb 2014 16:44, Thomas Vandahl t...@apache.org wrote:

 Gary,

 On 08.02.14 17:34, Gary Gregory wrote:
  Mat,
 
  I would suggest getting familiar with the code base in trunk. Can the
 code
  be released as is or are there problems? Should some issues in Jira be
  fixed for this release?
 
  Major releases like a 2.0 from 1.x are the only time APIs can break
 binary
  compatibility which means that the package name must change and the Maven
  coords as well.
 
  Does the current code even warrant the 2.0 label or would a 1.x dump be a
  better representation of what is in trunk?

 Rest assured that all these things have been taken care of. The API
 *has* changed and the modifications *are* substantial. A look into the
 commits of the last two years should show that.

 Mat,

 if you want to help, please check that the build and all tests are
 working fine for you. Note that some tests are disabled in the POM as
 they seem to be timing sensitive. I did my best to fix these problems,
 however. The documentation does not yet reflect the recent API changes.
 I'll fix this as soon as I can.

 Bye, Thomas.

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Version 2 release

[Thomas Vandahl]

On 04.02.14 16:52, Gary Gregory wrote:
 I think the biggest hurdle to releasing [JCS] 2.0 is finding a [Commons]
 committer willing to put in the time to go over the component and act as
 the release manager.

Well, I'm actually doing what I can. My hesitation partly comes from the
fact that the test results within the Continuum build are not in line
with mine. Any help will be appreciated as this is going to be my first
release within Apache Commons.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Version 2 release

[Mat Jaggard]

Well I don't have experience with Apache but if you want me to help with
testing, I'm happy to do what I can. What would be most helpful?

Mat.
On 8 Feb 2014 11:38, Thomas Vandahl t...@apache.org wrote:

 On 04.02.14 16:52, Gary Gregory wrote:
  I think the biggest hurdle to releasing [JCS] 2.0 is finding a [Commons]
  committer willing to put in the time to go over the component and act as
  the release manager.

 Well, I'm actually doing what I can. My hesitation partly comes from the
 fact that the test results within the Continuum build are not in line
 with mine. Any help will be appreciated as this is going to be my first
 release within Apache Commons.

 Bye, Thomas.



 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org

Re: [JCS] Version 2 release

[Gary Gregory]

Mat,

I would suggest getting familiar with the code base in trunk. Can the code
be released as is or are there problems? Should some issues in Jira be
fixed for this release?

Major releases like a 2.0 from 1.x are the only time APIs can break binary
compatibility which means that the package name must change and the Maven
coords as well.

Does the current code even warrant the 2.0 label or would a 1.x dump be a
better representation of what is in trunk?

The Clirr report should tell us if there are compatibility issues.

Are the Maven reports generates in target/site/ come up clean (by running
'mvn clean site').

I'm not even sure if this project uses PMD, FindBugs, Corbetura, and
Checkstyle. If it does not, it probably should.

Lot of details, I know...

Gary


On Sat, Feb 8, 2014 at 11:26 AM, Mat Jaggard matt...@jaggard.org.uk wrote:

 Well I don't have experience with Apache but if you want me to help with
 testing, I'm happy to do what I can. What would be most helpful?

 Mat.
 On 8 Feb 2014 11:38, Thomas Vandahl t...@apache.org wrote:

  On 04.02.14 16:52, Gary Gregory wrote:
   I think the biggest hurdle to releasing [JCS] 2.0 is finding a
 [Commons]
   committer willing to put in the time to go over the component and act
 as
   the release manager.
 
  Well, I'm actually doing what I can. My hesitation partly comes from the
  fact that the test results within the Continuum build are not in line
  with mine. Any help will be appreciated as this is going to be my first
  release within Apache Commons.
 
  Bye, Thomas.
 
 
 
  -
  To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
  For additional commands, e-mail: user-h...@commons.apache.org
 
 




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [JCS] Version 2 release

[Thomas Vandahl]

Gary,

On 08.02.14 17:34, Gary Gregory wrote:
 Mat,
 
 I would suggest getting familiar with the code base in trunk. Can the code
 be released as is or are there problems? Should some issues in Jira be
 fixed for this release?
 
 Major releases like a 2.0 from 1.x are the only time APIs can break binary
 compatibility which means that the package name must change and the Maven
 coords as well.
 
 Does the current code even warrant the 2.0 label or would a 1.x dump be a
 better representation of what is in trunk?

Rest assured that all these things have been taken care of. The API
*has* changed and the modifications *are* substantial. A look into the
commits of the last two years should show that.

Mat,

if you want to help, please check that the build and all tests are
working fine for you. Note that some tests are disabled in the POM as
they seem to be timing sensitive. I did my best to fix these problems,
however. The documentation does not yet reflect the recent API changes.
I'll fix this as soon as I can.

Bye, Thomas.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[JCS] Version 2 release

[Mat Jaggard]

Hi,
Can you tell me when version 2.0 of JCS is likely to be released? What are
the blocking issues? Is there anything I can do to help?

The main problem for me is using concurrent instead of the Java 5
equivalent.

Many thanks,
Mat.

RE: [JCS] Version 2 release

[Gary Gregory]

I do not think we have a schedule for 2.0. If you want to help push it out, I 
suggest you go through the Jira issues and see what you Figo should be 
addressed.  You can post your ideas here. If you want to provide patches, make 
sure you patch trunk and attach different files to Jira issues.

Gary

 Original message 
From: Mat Jaggard apa...@jaggard.org.uk 
Date:02/04/2014  06:16  (GMT-05:00) 
To: Commons Users List user@commons.apache.org 
Subject: [JCS] Version 2 release 

Hi,
Can you tell me when version 2.0 of JCS is likely to be released? What are
the blocking issues? Is there anything I can do to help?

The main problem for me is using concurrent instead of the Java 5
equivalent.

Many thanks,
Mat.

Re: [JCS] Version 2 release

[Mat Jaggard]

I can't actually see any relevant issues in JIRA. They all seem to either
relate to 1.3, be improvements rather than bugs or be an issue with Maven
testing rather than the product.

Are there any blocking issues or is it just testing time that's preventing
2.0 being released?


On 4 February 2014 15:16, Gary Gregory garydgreg...@gmail.com wrote:

 I do not think we have a schedule for 2.0. If you want to help push it
 out, I suggest you go through the Jira issues and see what you Figo should
 be addressed.  You can post your ideas here. If you want to provide
 patches, make sure you patch trunk and attach different files to Jira
 issues.

 Gary

  Original message 
 From: Mat Jaggard apa...@jaggard.org.uk
 Date:02/04/2014  06:16  (GMT-05:00)
 To: Commons Users List user@commons.apache.org
 Subject: [JCS] Version 2 release

 Hi,
 Can you tell me when version 2.0 of JCS is likely to be released? What are
 the blocking issues? Is there anything I can do to help?

 The main problem for me is using concurrent instead of the Java 5
 equivalent.

 Many thanks,
 Mat.

Re: [JCS] Version 2 release

[Gary Gregory]

I think the biggest hurdle to releasing [JCS] 2.0 is finding a [Commons]
committer willing to put in the time to go over the component and act as
the release manager.

Gary


On Tue, Feb 4, 2014 at 10:46 AM, Mat Jaggard matt...@jaggard.org.uk wrote:

 I can't actually see any relevant issues in JIRA. They all seem to either
 relate to 1.3, be improvements rather than bugs or be an issue with Maven
 testing rather than the product.

 Are there any blocking issues or is it just testing time that's preventing
 2.0 being released?


 On 4 February 2014 15:16, Gary Gregory garydgreg...@gmail.com wrote:

  I do not think we have a schedule for 2.0. If you want to help push it
  out, I suggest you go through the Jira issues and see what you Figo
 should
  be addressed.  You can post your ideas here. If you want to provide
  patches, make sure you patch trunk and attach different files to Jira
  issues.
 
  Gary
 
   Original message 
  From: Mat Jaggard apa...@jaggard.org.uk
  Date:02/04/2014  06:16  (GMT-05:00)
  To: Commons Users List user@commons.apache.org
  Subject: [JCS] Version 2 release
 
  Hi,
  Can you tell me when version 2.0 of JCS is likely to be released? What
 are
  the blocking issues? Is there anything I can do to help?
 
  The main problem for me is using concurrent instead of the Java 5
  equivalent.
 
  Many thanks,
  Mat.
 




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [jcs] Re: JCS disk only and expiration config question

[Thomas Vandahl]

On 25.09.13 19:25, JavaWebDev wrote:
 There doesn't seem to be a a DiskShrinker like there is a memory
 shrinker so it looks like the objects stored on disk will only be
 removed passively when retrieved and identified as expired? I'll look
 into the Recycle bin more.

See the method IndexedDiskCache.optimizeFile(). This will be called if
OptimizeAtRemoveCount  0 and removeCount  OptimizeAtRemoveCount.

Bye, Thomas.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[jcs] Re: JCS disk only and expiration config question

[Thomas Vandahl]

Hi JavaWebDev,

first of all, the usage of clear names of real persons would be very
much appreciated.

On 24.09.13 21:27, JavaWebDev wrote:
 First. The user and dev mailing lists haven't been active lately and the
 wiki seemed outdated in some sections. (ex: no longer a .commons
 package). Is JCS still being worked on? I chose it because it seems
 faster than ehcache and I need the disk cache to persist across servlet
 container restarts.

The latest commits were just four weeks ago. Currently, I'm maintaining
this alone. All contributions would be welcomed.

 Ideally I'd like to write cache to disk immediately in case the servlet
 crashes without being able to call dispose(). Should I set MaxObjects to
 0 in the region definition of cache.ccf?

See the documentation of the purgatory at
http://commons.apache.org/proper/commons-jcs/IndexedDiskAuxCache.html.
If you set the size of the purgatory to 0 your performance will suffer
seriously. Mind you, JCS is a cache, no data store.

 I'd like the objects in disk cache to expire after 7 days. Which
 configuration parameter(s) do I need to change?

Expiry is handled by the memory cache. Empty spots in the disk cache
will be reused. If you want to clean up every now and then, you may want
to play with the configuration options OptimizeAtRemoveCount and
MaxReycleBinSize.

HTH.
Bye, Thomas.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [jcs] Re: JCS disk only and expiration config question

[JavaWebDev]

Thomas,

Thanks for the quick reply. Some comments inline below...

On 9/25/2013 3:31 AM, Thomas Vandahl wrote:
The latest commits were just four weeks ago. Currently, I'm 
maintaining this alone. All contributions would be welcomed. 
I'll build from source and see if there's anything I can contribute 
along the way. One of the discrepancies I noticed was the packages in 
the wiki mentioned as org.apache.commons.jcs while in the jar I 
downloaded from the Downloads page (v1.3) the packages are org.apache.jcs.


I'm liking JCS more than ehcache. I used to use oscache but that's dead. 
If there's anything specifically that can be done to get a more recent 
release out please let me know.

Ideally I'd like to write cache to disk immediately in case the servlet
crashes without being able to call dispose(). Should I set MaxObjects to
0 in the region definition of cache.ccf?

See the documentation of the purgatory at
http://commons.apache.org/proper/commons-jcs/IndexedDiskAuxCache.html.
If you set the size of the purgatory to 0 your performance will suffer
seriously. Mind you, JCS is a cache, no data store.
I need to cache some data that takes a bit longer than I'd like to 
retrieve but does not update frequently and I do not need to store it 
indefinitely. Pulling it from a local drive is a lot faster than pulling 
it in normally.


I wound up digging through the code and found the DiskUsagePatternName 
property and set it to UPDATE in cache.ccs. I keep MaxObjects and 
MaxPergatorySize at 0 values but the objects get written to disk fairly 
quickly. Within a second or so of putting them in cache. This seems to 
accomplish what I need. It is a region property, not disk property and I 
eventually found the documentation for it at 
http://commons.apache.org/proper/commons-jcs/RegionProperties.html


From what I understand and what I'm seeing, now when I write to cache 
it goes into memory, then it goes to purgatory (also memory) and then to 
disk. Everything appears to still be done asynchronously but the disk 
write is done fast enough for my needs.

I'd like the objects in disk cache to expire after 7 days. Which
configuration parameter(s) do I need to change?

Expiry is handled by the memory cache. Empty spots in the disk cache
will be reused. If you want to clean up every now and then, you may want
to play with the configuration options OptimizeAtRemoveCount and
MaxReycleBinSize.
If I understand correctly, setting MaxLifeSeconds to 7 days (in seconds) 
will accomplish what I want. Whether the cache object comes from disk or 
memory JCS will check if the object has expired and return null if it has.


There doesn't seem to be a a DiskShrinker like there is a memory 
shrinker so it looks like the objects stored on disk will only be 
removed passively when retrieved and identified as expired? I'll look 
into the Recycle bin more.

HTH.
Bye, Thomas.

Helps a lot thanks. I think I got it working where I need to last night 
but the additional info will help me tune it better.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

JCS disk only and expiration config question

[JavaWebDev]

I'm new to using JCS and have some questions regarding configuring it 
the way I want.


First. The user and dev mailing lists haven't been active lately and the 
wiki seemed outdated in some sections. (ex: no longer a .commons 
package). Is JCS still being worked on? I chose it because it seems 
faster than ehcache and I need the disk cache to persist across servlet 
container restarts.


Ideally I'd like to write cache to disk immediately in case the servlet 
crashes without being able to call dispose(). Should I set MaxObjects to 
0 in the region definition of cache.ccf?


I'd like the objects in disk cache to expire after 7 days. Which 
configuration parameter(s) do I need to change?


Thanks.