You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Chandri Krishnan <ch...@gmail.com> on 2007/08/16 23:32:49 UTC
asynchronous updates
Hello,
I am having as issue with a prototype distributed cache that I am
building with JCS. I am running JCS with one remote server and two
clients. I am using a standalone driver that communicates with these
clients. The clients create, retrieve, update and remove hundreds of
objects (each of size few hundred bytes) based on commands received
from the driver.
I noticed that some objects inserted into the cache in one client is
not available from the other. Sometimes updates aren't reflected. I
looked at all the cached objects in both the caches using
cache.getGroupKeys and the numbers are never the same. Shouldn't the
updates be available immediately to both the clients? I found that
puts and removals occur asynchronously with the Remote server setting,
but gets are synchronous.
Any help will be appreciated.
Thanks,
Chandri
Here is my remote.cache.ccf used in the remote server:
--------------------------------------------------------------------------------------------
# remote.cache.ccf
registry.host=localhost
registry.port=11102
remote.cache.service.port=11102
remote.cluster.LocalClusterConsistency=true
remote.cluster.AllowClusterGet=true
jcs.default=RCluster
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=10000
jcs.auxiliary.RCluster=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.RCluster.attributes=org.apache.jcs.auxiliary.remote.RemoteCacheAtt
ributes
jcs.auxiliary.RCluster.attributes.RemoteTypeName=CLUSTER
jcs.auxiliary.RCluster.attributes.RemoveUponRemotePut=false
jcs.auxiliary.RCluster.attributes.GetOnly=false
--------------------------------------------------------------------------------------------
Here is the cache.ccf file used in the clients (both of them use the same)
--------------------------------------------------------------------------------------------
jcs.default=RServer
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=200001
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRU
MemoryCache
jcs.default.cacheattributes.UseMemoryShrinker=true
jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
jcs.default.elementattributes.IsEternal=false
jcs.default.elementattributes.MaxLifeSeconds=700
jcs.default.elementattributes.IsSpool=true
jcs.default.elementattributes.IsRemote=true
jcs.default.elementattributes.IsLateral=true
jcs.auxiliary.RServer=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.RServer.attributes=org.apache.jcs.auxiliary.remote.RemoteCacheAttr
ibutes
jcs.auxiliary.RServer.attributes.FailoverServers=localhost:11102
jcs.auxiliary.RServer.attributes.RemoveUponRemotePut=false
jcs.auxiliary.RServer.attributes.RemoteTypeName=LOCAL
jcs.auxiliary.RServer.attributes.GetOnly=false
jcs.auxiliary.RServer.attributes.Receive=true
--------------------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
cache keys from disk cache after restart
Posted by Tim Cronin <tc...@interwoven.com>.
I can see that the load function is called upon process restart.
is there anyway to read the keys from the disk cache?
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
is something wrong with my config.
Posted by Tim Cronin <tc...@interwoven.com>.
I noticed the following in the cache info statement
219 [main] INFO control.CompositeCache - Constructed cache with name
[component] and cache attributes [ useLateral = true, useRemote = true,
useDisk = true, maxObjs = 256, maxSpoolPerRun = 500, diskUsagePattern =
0 ]
but in my config:
jcs.region.component.elementattributes.IsRemote=false
jcs.region.component.elementattributes.IsLateral=false
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: Best practice for linking Cache elements
Posted by Tim Cronin <tc...@interwoven.com>.
thanks I'm looking into that.
-----Original Message-----
From: Horton Simon [mailto:Simon.Horton@uk.mizuho-sc.com]
Sent: Wednesday, August 29, 2007 6:25 AM
To: JCS Users List
Subject: RE: Best practice for linking Cache elements
Hi Tim,
If you are able to use a String instead of an object as a key you could
take advantage of the following JCS feature. If you have written your
code to use the JCS cache via your own utility helper class, you could
perform the toString conversion of your object key to a String key in
this one place and not have to touch the rest of your code.
Below is from am older response which Aaron gave on the email group to
somebody else and could be just what you are after.
Q: Can I remove multiple entries from Cache in a single go?
A:Yes, but it is somewhat expensive, since some of the auxiliaries will
have to iterate over their keysets.
Although all the auxiliaries honor this, it is not
part of the auxiliary API. There is no method along
the lins of "removeStartingWith", but all the remove
methods can do it.
By default, the hierarchical key delimiter used in JCS
is a colon. You cannot add a String key that ends
with a colon. If you call remove with a String key
that ends in a colon, everything that has a key that
starts with the argument will be removed.
If your keys are in this format
TYPE:SOURCE:OBJECT
And you put n objects in the cache with keys like this
"ABC:123:0" to "ABC:123:n"
then you could remove all the obejcts by calling
jcs.remove( "ABC:123:" );
Regards,
Simon
-----Original Message-----
From: Tim Cronin [mailto:tcronin@interwoven.com]
Sent: Tuesday, August 28, 2007 7:01 PM
To: JCS Users List
Subject: Best practice for linking Cache elements
We have a hierarchical structure of cache elements.
Sites contain pages and page contain components so
when we get a cache invalidation for a site we need to
flush all page and component entries for that site.
Our cache key is not a simple string.
I see there is grouping but comments in the code
say that this is going away.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this message in error please delete it
and any files transmitted with it, after notifying
postmaster@uk.mizuho-sc.com
Any opinions expressed in this message may be those of the author and
not necessarily those of the company. The company accepts no
responsibility for the accuracy or completeness of any information
contained herein. This message is not intended to create legal relations
between the company and the recipient.
Recipients should please note that messages sent via the Internet may be
intercepted and that caution should therefore be exercised before
dispatching to the company any confidential or sensitive information.
Mizuho International plc Bracken House, One Friday Street, London EC4M
9JA. TEL. 020 72361090. Wholly owned subsidiary of Mizuho Securities
Co., Ltd. Member of Mizuho Financial Group. Authorised and regulated by
the Financial Services Authority. Member of the London Stock Exchange.
Registered in England No. 1203696. Registered office as above.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: Best practice for linking Cache elements
Posted by Horton Simon <Si...@uk.mizuho-sc.com>.
Hi Tim,
If you are able to use a String instead of an object as a key you could
take advantage of the following JCS feature. If you have written your
code to use the JCS cache via your own utility helper class, you could
perform the toString conversion of your object key to a String key in
this one place and not have to touch the rest of your code.
Below is from am older response which Aaron gave on the email group to
somebody else and could be just what you are after.
Q: Can I remove multiple entries from Cache in a single go?
A:Yes, but it is somewhat expensive, since some of the auxiliaries will
have to iterate over their keysets.
Although all the auxiliaries honor this, it is not
part of the auxiliary API. There is no method along
the lins of "removeStartingWith", but all the remove
methods can do it.
By default, the hierarchical key delimiter used in JCS
is a colon. You cannot add a String key that ends
with a colon. If you call remove with a String key
that ends in a colon, everything that has a key that
starts with the argument will be removed.
If your keys are in this format
TYPE:SOURCE:OBJECT
And you put n objects in the cache with keys like this
"ABC:123:0" to "ABC:123:n"
then you could remove all the obejcts by calling
jcs.remove( "ABC:123:" );
Regards,
Simon
-----Original Message-----
From: Tim Cronin [mailto:tcronin@interwoven.com]
Sent: Tuesday, August 28, 2007 7:01 PM
To: JCS Users List
Subject: Best practice for linking Cache elements
We have a hierarchical structure of cache elements.
Sites contain pages and page contain components so
when we get a cache invalidation for a site we need to
flush all page and component entries for that site.
Our cache key is not a simple string.
I see there is grouping but comments in the code
say that this is going away.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error please delete it and any files transmitted with it, after notifying postmaster@uk.mizuho-sc.com
Any opinions expressed in this message may be those of the author and not necessarily those of the company. The company accepts no responsibility for the accuracy or completeness of any information contained herein. This message is not intended to create legal relations between the company and the recipient.
Recipients should please note that messages sent via the Internet may be intercepted and that caution should therefore be exercised before dispatching to the company any confidential or sensitive information.
Mizuho International plc Bracken House, One Friday Street, London EC4M 9JA. TEL. 020 72361090. Wholly owned subsidiary of Mizuho Securities Co., Ltd. Member of Mizuho Financial Group. Authorised and regulated by the Financial Services Authority. Member of the London Stock Exchange.
Registered in England No. 1203696. Registered office as above.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Best practice for linking Cache elements
Posted by Tim Cronin <tc...@interwoven.com>.
We have a hierarchical structure of cache elements.
Sites contain pages and page contain components so
when we get a cache invalidation for a site we need to
flush all page and component entries for that site.
Our cache key is not a simple string.
I see there is grouping but comments in the code
say that this is going away.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: asynchronous updates
Posted by Horton Simon <Si...@uk.mizuho-sc.com>.
Hi,
> When it is set to false, does it mean that
>changes made in other caches are ignored and stale objects can be
>returned?
Yes, I think that when RemoveUponRemotePut=false, if the object is in
your local cache it will use this, even if this is stale compared to
your remote cache. When the data in your local cache expires it goes off
to the remote cache and checks there, picking up your latest version,
therefore eventually catching up.
>Also, when it is true,
>changes made in other caches causes the value to be set as null. When
>a get is made on the same key, does it retrieve the value from the
>remote cache?
Yes, from what I have seen, if RemoveUponRemotePut=true and you put
something in your local cache, lets call it cache A, that object is
propagated to the remote cache, and if the object key is in another
local cache, say cache B, it is removed from cache B (if it was there).
When cache B tries to get the object using the same key, it doesn't have
it anymore in its local cache, so goes to the remote cache and gets it
from there, storing it after retrieval in local cache B for future use
so it doesn't have to go back to the remote cache, until the next put
causes a removal again.
Regards,
Simon
-----Original Message-----
From: Chandri Krishnan [mailto:chandri@gmail.com]
Sent: Monday, August 20, 2007 10:23 PM
To: JCS Users List
Subject: Re: asynchronous updates
Thanks Simon, that works! I'm not sure I understand the semantics of
RemoveUponRemotePut. When it is set to false, does it mean that
changes made in other caches are ignored and stale objects can be
returned? In what scenario is this useful? Also, when it is true,
changes made in other caches causes the value to be set as null. When
a get is made on the same key, does it retrieve the value from the
remote cache?
Thanks,
Chandri
On 8/20/07, Horton Simon <Si...@uk.mizuho-sc.com> wrote:
> Hi Chandri,
>
> Have you tried setting the RemoveUponRemotePut=true to see if that
> resolves your issue? (Your RServer and RCluster have this attribute
> specified below)
>
> Regards,
> Simon
>
> -----Original Message-----
> From: Chandri Krishnan [mailto:chandri@gmail.com]
> Sent: Monday, August 20, 2007 6:19 PM
> To: jcs-users@jakarta.apache.org
> Subject: Re: asynchronous updates
>
> A small correction in my previous email. The sizes of my objects vary
> from 8-12KB.
>
> Chandri
>
> On 8/16/07, Chandri Krishnan wrote:
> > Hello,
> >
> > I am having as issue with a prototype distributed cache that I am
> > building with JCS. I am running JCS with one remote server and two
> > clients. I am using a standalone driver that communicates with these
> > clients. The clients create, retrieve, update and remove hundreds of
> > objects (each of size few hundred bytes) based on commands received
> > from the driver.
> >
> > I noticed that some objects inserted into the cache in one client is
> > not available from the other. Sometimes updates aren't reflected. I
> > looked at all the cached objects in both the caches using
> > cache.getGroupKeys and the numbers are never the same. Shouldn't the
> > updates be available immediately to both the clients? I found that
> > puts and removals occur asynchronously with the Remote server
setting,
> > but gets are synchronous.
> >
> > Any help will be appreciated.
> >
> > Thanks,
> > Chandri
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error please delete it and any files transmitted with it, after notifying postmaster@uk.mizuho-sc.com
Any opinions expressed in this message may be those of the author and not necessarily those of the company. The company accepts no responsibility for the accuracy or completeness of any information contained herein. This message is not intended to create legal relations between the company and the recipient.
Recipients should please note that messages sent via the Internet may be intercepted and that caution should therefore be exercised before dispatching to the company any confidential or sensitive information.
Mizuho International plc Bracken House, One Friday Street, London EC4M 9JA. TEL. 020 72361090. Wholly owned subsidiary of Mizuho Securities Co., Ltd. Member of Mizuho Financial Group. Authorised and regulated by the Financial Services Authority. Member of the London Stock Exchange.
Registered in England No. 1203696. Registered office as above.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: asynchronous updates
Posted by Chandri Krishnan <ch...@gmail.com>.
Thanks Simon, that works! I'm not sure I understand the semantics of
RemoveUponRemotePut. When it is set to false, does it mean that
changes made in other caches are ignored and stale objects can be
returned? In what scenario is this useful? Also, when it is true,
changes made in other caches causes the value to be set as null. When
a get is made on the same key, does it retrieve the value from the
remote cache?
Thanks,
Chandri
On 8/20/07, Horton Simon <Si...@uk.mizuho-sc.com> wrote:
> Hi Chandri,
>
> Have you tried setting the RemoveUponRemotePut=true to see if that
> resolves your issue? (Your RServer and RCluster have this attribute
> specified below)
>
> Regards,
> Simon
>
> -----Original Message-----
> From: Chandri Krishnan [mailto:chandri@gmail.com]
> Sent: Monday, August 20, 2007 6:19 PM
> To: jcs-users@jakarta.apache.org
> Subject: Re: asynchronous updates
>
> A small correction in my previous email. The sizes of my objects vary
> from 8-12KB.
>
> Chandri
>
> On 8/16/07, Chandri Krishnan wrote:
> > Hello,
> >
> > I am having as issue with a prototype distributed cache that I am
> > building with JCS. I am running JCS with one remote server and two
> > clients. I am using a standalone driver that communicates with these
> > clients. The clients create, retrieve, update and remove hundreds of
> > objects (each of size few hundred bytes) based on commands received
> > from the driver.
> >
> > I noticed that some objects inserted into the cache in one client is
> > not available from the other. Sometimes updates aren't reflected. I
> > looked at all the cached objects in both the caches using
> > cache.getGroupKeys and the numbers are never the same. Shouldn't the
> > updates be available immediately to both the clients? I found that
> > puts and removals occur asynchronously with the Remote server setting,
> > but gets are synchronous.
> >
> > Any help will be appreciated.
> >
> > Thanks,
> > Chandri
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
RE: asynchronous updates
Posted by Horton Simon <Si...@uk.mizuho-sc.com>.
Hi Chandri,
Have you tried setting the RemoveUponRemotePut=true to see if that
resolves your issue? (Your RServer and RCluster have this attribute
specified below)
Regards,
Simon
-----Original Message-----
From: Chandri Krishnan [mailto:chandri@gmail.com]
Sent: Monday, August 20, 2007 6:19 PM
To: jcs-users@jakarta.apache.org
Subject: Re: asynchronous updates
A small correction in my previous email. The sizes of my objects vary
from 8-12KB.
Chandri
On 8/16/07, Chandri Krishnan wrote:
> Hello,
>
> I am having as issue with a prototype distributed cache that I am
> building with JCS. I am running JCS with one remote server and two
> clients. I am using a standalone driver that communicates with these
> clients. The clients create, retrieve, update and remove hundreds of
> objects (each of size few hundred bytes) based on commands received
> from the driver.
>
> I noticed that some objects inserted into the cache in one client is
> not available from the other. Sometimes updates aren't reflected. I
> looked at all the cached objects in both the caches using
> cache.getGroupKeys and the numbers are never the same. Shouldn't the
> updates be available immediately to both the clients? I found that
> puts and removals occur asynchronously with the Remote server setting,
> but gets are synchronous.
>
> Any help will be appreciated.
>
> Thanks,
> Chandri
>
> Here is my remote.cache.ccf used in the remote server:
>
------------------------------------------------------------------------
--------------------
> # remote.cache.ccf
> registry.host=localhost
> registry.port=11102
> remote.cache.service.port=11102
> remote.cluster.LocalClusterConsistency=true
> remote.cluster.AllowClusterGet=true
>
> jcs.default=RCluster
>
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
es
> jcs.default.cacheattributes.MaxObjects=10000
>
>
jcs.auxiliary.RCluster=org.apache.jcs.auxiliary.remote.RemoteCacheFactor
y
>
jcs.auxiliary.RCluster.attributes=org.apache.jcs.auxiliary.remote.Remote
CacheAtt
> ributes
> jcs.auxiliary.RCluster.attributes.RemoteTypeName=CLUSTER
> jcs.auxiliary.RCluster.attributes.RemoveUponRemotePut=false
> jcs.auxiliary.RCluster.attributes.GetOnly=false
>
------------------------------------------------------------------------
--------------------
>
> Here is the cache.ccf file used in the clients (both of them use the
same)
>
------------------------------------------------------------------------
--------------------
> jcs.default=RServer
>
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
es
> jcs.default.cacheattributes.MaxObjects=200001
>
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
.lru.LRU
> MemoryCache
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsEternal=false
> jcs.default.elementattributes.MaxLifeSeconds=700
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsRemote=true
> jcs.default.elementattributes.IsLateral=true
>
>
jcs.auxiliary.RServer=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
>
jcs.auxiliary.RServer.attributes=org.apache.jcs.auxiliary.remote.RemoteC
acheAttr
> ibutes
> jcs.auxiliary.RServer.attributes.FailoverServers=localhost:11102
> jcs.auxiliary.RServer.attributes.RemoveUponRemotePut=false
> jcs.auxiliary.RServer.attributes.RemoteTypeName=LOCAL
> jcs.auxiliary.RServer.attributes.GetOnly=false
> jcs.auxiliary.RServer.attributes.Receive=true
>
>
------------------------------------------------------------------------
--------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error please delete it and any files transmitted with it, after notifying postmaster@uk.mizuho-sc.com
Any opinions expressed in this message may be those of the author and not necessarily those of the company. The company accepts no responsibility for the accuracy or completeness of any information contained herein. This message is not intended to create legal relations between the company and the recipient.
Recipients should please note that messages sent via the Internet may be intercepted and that caution should therefore be exercised before dispatching to the company any confidential or sensitive information.
Mizuho International plc Bracken House, One Friday Street, London EC4M 9JA. TEL. 020 72361090. Wholly owned subsidiary of Mizuho Securities Co., Ltd. Member of Mizuho Financial Group. Authorised and regulated by the Financial Services Authority. Member of the London Stock Exchange.
Registered in England No. 1203696. Registered office as above.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: asynchronous updates
Posted by Chandri Krishnan <ch...@gmail.com>.
A small correction in my previous email. The sizes of my objects vary
from 8-12KB.
Chandri
On 8/16/07, Chandri Krishnan wrote:
> Hello,
>
> I am having as issue with a prototype distributed cache that I am
> building with JCS. I am running JCS with one remote server and two
> clients. I am using a standalone driver that communicates with these
> clients. The clients create, retrieve, update and remove hundreds of
> objects (each of size few hundred bytes) based on commands received
> from the driver.
>
> I noticed that some objects inserted into the cache in one client is
> not available from the other. Sometimes updates aren't reflected. I
> looked at all the cached objects in both the caches using
> cache.getGroupKeys and the numbers are never the same. Shouldn't the
> updates be available immediately to both the clients? I found that
> puts and removals occur asynchronously with the Remote server setting,
> but gets are synchronous.
>
> Any help will be appreciated.
>
> Thanks,
> Chandri
>
> Here is my remote.cache.ccf used in the remote server:
> --------------------------------------------------------------------------------------------
> # remote.cache.ccf
> registry.host=localhost
> registry.port=11102
> remote.cache.service.port=11102
> remote.cluster.LocalClusterConsistency=true
> remote.cluster.AllowClusterGet=true
>
> jcs.default=RCluster
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=10000
>
> jcs.auxiliary.RCluster=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
> jcs.auxiliary.RCluster.attributes=org.apache.jcs.auxiliary.remote.RemoteCacheAtt
> ributes
> jcs.auxiliary.RCluster.attributes.RemoteTypeName=CLUSTER
> jcs.auxiliary.RCluster.attributes.RemoveUponRemotePut=false
> jcs.auxiliary.RCluster.attributes.GetOnly=false
> --------------------------------------------------------------------------------------------
>
> Here is the cache.ccf file used in the clients (both of them use the same)
> --------------------------------------------------------------------------------------------
> jcs.default=RServer
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
> jcs.default.cacheattributes.MaxObjects=200001
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRU
> MemoryCache
> jcs.default.cacheattributes.UseMemoryShrinker=true
> jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
> jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
> jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
> jcs.default.elementattributes.IsEternal=false
> jcs.default.elementattributes.MaxLifeSeconds=700
> jcs.default.elementattributes.IsSpool=true
> jcs.default.elementattributes.IsRemote=true
> jcs.default.elementattributes.IsLateral=true
>
> jcs.auxiliary.RServer=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
> jcs.auxiliary.RServer.attributes=org.apache.jcs.auxiliary.remote.RemoteCacheAttr
> ibutes
> jcs.auxiliary.RServer.attributes.FailoverServers=localhost:11102
> jcs.auxiliary.RServer.attributes.RemoveUponRemotePut=false
> jcs.auxiliary.RServer.attributes.RemoteTypeName=LOCAL
> jcs.auxiliary.RServer.attributes.GetOnly=false
> jcs.auxiliary.RServer.attributes.Receive=true
>
> --------------------------------------------------------------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org