Guaranteed persistence

[Tim Stibbs]

Hi,

I am looking into using JCS as a disk-based key-value store, and it seems to
work fine. However if the jvm is terminated, the .key file may not get
written to, and although the .data file has my data in, when I restart the
application it cannot access anything in the cache (presumably due to the
.key file being empty).

So, is there anyway to force the cache to immediately persist to disk?
Having MaxObjects=0 on the memory cache seems to help, but still doesn't
cause the .key file to be written.

I also though I might be able to use ICacheEventLogger to see when data has
actually been written to the disk store, but the logging stuff doesn't seem
to be in the released version, although it is in the documentation?

Does anyone know if it is even possible to do what I am trying to do, or
have any suggestions?

Thanks.

[Jorge Medina-5]

Look at :
http://jakarta.apache.org/jcs/RegionProperties.html
and
http://jakarta.apache.org/jcs/IndexedDiskCacheProperties.html

What are the properties of your disk cache ?


On Mon, Aug 2, 2010 at 4:51 AM, Tim Stibbs <stripybadger@...> wrote:

> Hi,
>
> I am looking into using JCS as a disk-based key-value store, and it seems to
> work fine. However if the jvm is terminated, the .key file may not get
> written to, and although the .data file has my data in, when I restart the
> application it cannot access anything in the cache (presumably due to the
> .key file being empty).
>
> So, is there anyway to force the cache to immediately persist to disk?
> Having MaxObjects=0 on the memory cache seems to help, but still doesn't
> cause the .key file to be written.
>
> I also though I might be able to use ICacheEventLogger to see when data has
> actually been written to the disk store, but the logging stuff doesn't seem
> to be in the released version, although it is in the documentation?
>
> Does anyone know if it is even possible to do what I am trying to do, or
> have any suggestions?
>
> Thanks.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...

[Tim Stibbs]

I am using CompositeCacheManager.getUnconfiguredInstance(); and configuring
it programatically with the following properties:

jcs.default=DC
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=0
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC.attributes.DiskPath=C:\path\etc
jcs.auxiliary.DC.attributes.MaxKeySize=1000
jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=1000

My main aims are:
- guaranteed persistence - once I've added it to the cache, even if the
application crashes, the key value pair will still be available when the app
starts up again
- a non-infinite cache - I want the number of items in the cache to not
exceed order of 1000 to conserve disk space, though the exact number is not
important.

Do these sound like something that is possible with JCS? I've looked through
all the documentation and can't find anything along these lines.

Thanks,

Tim.

On 3 August 2010 20:17, Jorge Medina <cerebrotecnologico@...> wrote:

> Look at :
> http://jakarta.apache.org/jcs/RegionProperties.html
> and
> http://jakarta.apache.org/jcs/IndexedDiskCacheProperties.html
>
> What are the properties of your disk cache ?
>
>
> On Mon, Aug 2, 2010 at 4:51 AM, Tim Stibbs <stripybadger@...> wrote:
> > Hi,
> >
> > I am looking into using JCS as a disk-based key-value store, and it seems
> to
> > work fine. However if the jvm is terminated, the .key file may not get
> > written to, and although the .data file has my data in, when I restart
> the
> > application it cannot access anything in the cache (presumably due to the
> > .key file being empty).
> >
> > So, is there anyway to force the cache to immediately persist to disk?
> > Having MaxObjects=0 on the memory cache seems to help, but still doesn't
> > cause the .key file to be written.
> >
> > I also though I might be able to use ICacheEventLogger to see when data
> has
> > actually been written to the disk store, but the logging stuff doesn't
> seem
> > to be in the released version, although it is in the documentation?
> >
> > Does anyone know if it is even possible to do what I am trying to do, or
> > have any suggestions?
> >
> > Thanks.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@...
> For additional commands, e-mail: jcs-users-help@...
>
>

[Horton Simon]

Hi Tim,

Try setting your MaxPurgatorySize to 0 so there is no asynchronous
caching of data written to the disk cache, it will reduce your
performance but means your data goes straight to disk.

jcs.auxiliary.DC.attributes.MaxPurgatorySize=0

Purgatory
Writing to the disk cache is asynchronous and made efficient by using a
memory staging area called purgatory. Retrievals check purgatory then
disk for an item. When items are sent to purgatory they are
simultaneously queued to be put to disk. If an item is retrieved from
purgatory it will no longer be written to disk, since the cache hub will
move it back to memory. Using purgatory insures that there is no wait
for disk writes, unecessary disk writes are avoided for borderline
items, and the items are always available



-----Original Message-----
From: Tim Stibbs [mailto:stripybadger@...]
Sent: 04 August 2010 08:25
To: JCS Users List
Subject: Re: Guaranteed persistence

I am using CompositeCacheManager.getUnconfiguredInstance(); and
configuring
it programatically with the following properties:

jcs.default=DC
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
es
jcs.default.cacheattributes.MaxObjects=0
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
.lru.LRUMemoryCache
jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheF
actory
jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Indexe
dDiskCacheAttributes
jcs.auxiliary.DC.attributes.DiskPath=C:\path\etc
jcs.auxiliary.DC.attributes.MaxKeySize=1000
jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=1000

My main aims are:
- guaranteed persistence - once I've added it to the cache, even if the
application crashes, the key value pair will still be available when the
app
starts up again
- a non-infinite cache - I want the number of items in the cache to not
exceed order of 1000 to conserve disk space, though the exact number is
not
important.

Do these sound like something that is possible with JCS? I've looked
through
all the documentation and can't find anything along these lines.

Thanks,

Tim.

On 3 August 2010 20:17, Jorge Medina <cerebrotecnologico@...>
wrote:

> Look at :
> http://jakarta.apache.org/jcs/RegionProperties.html
> and
> http://jakarta.apache.org/jcs/IndexedDiskCacheProperties.html
>
> What are the properties of your disk cache ?
>
>
> On Mon, Aug 2, 2010 at 4:51 AM, Tim Stibbs <stripybadger@...>
wrote:
> > Hi,
> >
> > I am looking into using JCS as a disk-based key-value store, and it
seems
> to
> > work fine. However if the jvm is terminated, the .key file may not
get
> > written to, and although the .data file has my data in, when I
restart
> the
> > application it cannot access anything in the cache (presumably due
to the
> > .key file being empty).
> >
> > So, is there anyway to force the cache to immediately persist to
disk?
> > Having MaxObjects=0 on the memory cache seems to help, but still
doesn't
> > cause the .key file to be written.
> >
> > I also though I might be able to use ICacheEventLogger to see when
data
> has
> > actually been written to the disk store, but the logging stuff
doesn't
> seem
> > to be in the released version, although it is in the documentation?
> >
> > Does anyone know if it is even possible to do what I am trying to
do, or

> > have any suggestions?
> >
> > Thanks.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@...
> For additional commands, e-mail: jcs-users-help@...
>
>

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@...
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. [phone]. 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@...
For additional commands, e-mail: jcs-users-help@...

[Tim Stibbs]

Thanks Simon,

That's one of the options I had tried - for some reason it seems to result
in nothing being written to the cache at all. Is there another option that I
need to use in conjunction with MaxPurgatorySize?

On 4 August 2010 11:23, Simon Horton <Simon.Horton@...> wrote:

> Hi Tim,
>
> Try setting your MaxPurgatorySize to 0 so there is no asynchronous
> caching of data written to the disk cache, it will reduce your
> performance but means your data goes straight to disk.
>
> jcs.auxiliary.DC.attributes.MaxPurgatorySize=0
>
> Purgatory
> Writing to the disk cache is asynchronous and made efficient by using a
> memory staging area called purgatory. Retrievals check purgatory then
> disk for an item. When items are sent to purgatory they are
> simultaneously queued to be put to disk. If an item is retrieved from
> purgatory it will no longer be written to disk, since the cache hub will
> move it back to memory. Using purgatory insures that there is no wait
> for disk writes, unecessary disk writes are avoided for borderline
> items, and the items are always available
>
>
>
> -----Original Message-----
> From: Tim Stibbs [mailto:stripybadger@...]
> Sent: 04 August 2010 08:25
> To: JCS Users List
> Subject: Re: Guaranteed persistence
>
> I am using CompositeCacheManager.getUnconfiguredInstance(); and
> configuring
> it programatically with the following properties:
>
> jcs.default=DC
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
> es
> jcs.default.cacheattributes.MaxObjects=0
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
> .lru.LRUMemoryCache
> jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheF
> actory
> jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Indexe
> dDiskCacheAttributes
> jcs.auxiliary.DC.attributes.DiskPath=C:\path\etc
> jcs.auxiliary.DC.attributes.MaxKeySize=1000
> jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=1000
>
> My main aims are:
> - guaranteed persistence - once I've added it to the cache, even if the
> application crashes, the key value pair will still be available when the
> app
> starts up again
> - a non-infinite cache - I want the number of items in the cache to not
> exceed order of 1000 to conserve disk space, though the exact number is
> not
> important.
>
> Do these sound like something that is possible with JCS? I've looked
> through
> all the documentation and can't find anything along these lines.
>
> Thanks,
>
> Tim.
>
> On 3 August 2010 20:17, Jorge Medina <cerebrotecnologico@...>
> wrote:
>
> > Look at :
> > http://jakarta.apache.org/jcs/RegionProperties.html
> > and
> > http://jakarta.apache.org/jcs/IndexedDiskCacheProperties.html
> >
> > What are the properties of your disk cache ?
> >
> >
> > On Mon, Aug 2, 2010 at 4:51 AM, Tim Stibbs <stripybadger@...>
> wrote:
> > > Hi,
> > >
> > > I am looking into using JCS as a disk-based key-value store, and it
> seems
> > to
> > > work fine. However if the jvm is terminated, the .key file may not
> get
> > > written to, and although the .data file has my data in, when I
> restart
> > the
> > > application it cannot access anything in the cache (presumably due
> to the
> > > .key file being empty).
> > >
> > > So, is there anyway to force the cache to immediately persist to
> disk?
> > > Having MaxObjects=0 on the memory cache seems to help, but still
> doesn't
> > > cause the .key file to be written.
> > >
> > > I also though I might be able to use ICacheEventLogger to see when
> data
> > has
> > > actually been written to the disk store, but the logging stuff
> doesn't
> > seem
> > > to be in the released version, although it is in the documentation?
> > >
> > > Does anyone know if it is even possible to do what I am trying to
> do, or
> > > have any suggestions?
> > >
> > > Thanks.
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jcs-users-unsubscribe@...
> > For additional commands, e-mail: jcs-users-help@...
> >
> >
>
> 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@...
> 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. [phone]. 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@...
> For additional commands, e-mail: jcs-users-help@...
>
>

[Horton Simon]

Hi Tim,

I know you've set MaxObjects to zero so no items go to the memory cache,
but you may want to also set the DiskUsagePatternName to UPDATE in
conjunction with the MaxPurgatorySize setting from before?

jcs.default.cacheattributes.DiskUsagePatternName=UPDATE

The UPDATE usage pattern allows items to go to disk on an update. It
disables the swap. This allows you to persist all items to disk.

http://jakarta.apache.org/jcs/RegionProperties.html



-----Original Message-----
From: Tim Stibbs [mailto:stripybadger@...]
Sent: 04 August 2010 11:46
To: JCS Users List
Subject: Re: Guaranteed persistence

Thanks Simon,

That's one of the options I had tried - for some reason it seems to
result
in nothing being written to the cache at all. Is there another option
that I
need to use in conjunction with MaxPurgatorySize?

On 4 August 2010 11:23, Simon Horton <Simon.Horton@...>
wrote:

> Hi Tim,
>
> Try setting your MaxPurgatorySize to 0 so there is no asynchronous
> caching of data written to the disk cache, it will reduce your
> performance but means your data goes straight to disk.
>
> jcs.auxiliary.DC.attributes.MaxPurgatorySize=0
>
> Purgatory
> Writing to the disk cache is asynchronous and made efficient by using

a
> memory staging area called purgatory. Retrievals check purgatory then
> disk for an item. When items are sent to purgatory they are
> simultaneously queued to be put to disk. If an item is retrieved from
> purgatory it will no longer be written to disk, since the cache hub
will

> move it back to memory. Using purgatory insures that there is no wait
> for disk writes, unecessary disk writes are avoided for borderline
> items, and the items are always available
>
>
>
> -----Original Message-----
> From: Tim Stibbs [mailto:stripybadger@...]
> Sent: 04 August 2010 08:25
> To: JCS Users List
> Subject: Re: Guaranteed persistence
>
> I am using CompositeCacheManager.getUnconfiguredInstance(); and
> configuring
> it programatically with the following properties:
>
> jcs.default=DC
>

jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
> es
> jcs.default.cacheattributes.MaxObjects=0
>
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
> .lru.LRUMemoryCache
>
jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheF
> actory
>
jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Indexe
> dDiskCacheAttributes
> jcs.auxiliary.DC.attributes.DiskPath=C:\path\etc
> jcs.auxiliary.DC.attributes.MaxKeySize=1000
> jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=1000
>
> My main aims are:
> - guaranteed persistence - once I've added it to the cache, even if
the
> application crashes, the key value pair will still be available when
the
> app
> starts up again
> - a non-infinite cache - I want the number of items in the cache to
not
> exceed order of 1000 to conserve disk space, though the exact number
is

> not
> important.
>
> Do these sound like something that is possible with JCS? I've looked
> through
> all the documentation and can't find anything along these lines.
>
> Thanks,
>
> Tim.
>
> On 3 August 2010 20:17, Jorge Medina <cerebrotecnologico@...>
> wrote:
>
> > Look at :
> > http://jakarta.apache.org/jcs/RegionProperties.html
> > and
> > http://jakarta.apache.org/jcs/IndexedDiskCacheProperties.html
> >
> > What are the properties of your disk cache ?
> >
> >
> > On Mon, Aug 2, 2010 at 4:51 AM, Tim Stibbs <stripybadger@...>
> wrote:
> > > Hi,
> > >
> > > I am looking into using JCS as a disk-based key-value store, and

it

> seems
> > to
> > > work fine. However if the jvm is terminated, the .key file may not
> get
> > > written to, and although the .data file has my data in, when I
> restart
> > the
> > > application it cannot access anything in the cache (presumably due
> to the
> > > .key file being empty).
> > >
> > > So, is there anyway to force the cache to immediately persist to
> disk?
> > > Having MaxObjects=0 on the memory cache seems to help, but still
> doesn't
> > > cause the .key file to be written.
> > >
> > > I also though I might be able to use ICacheEventLogger to see when
> data
> > has
> > > actually been written to the disk store, but the logging stuff
> doesn't
> > seem
> > > to be in the released version, although it is in the

documentation?
> > >
> > > Does anyone know if it is even possible to do what I am trying to
> do, or
> > > have any suggestions?
> > >
> > > Thanks.
> > >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: jcs-users-unsubscribe@...
> > For additional commands, e-mail: jcs-users-help@...
> >
> >
>
> 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@...
> 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. [phone]. 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@...
> For additional commands, e-mail: jcs-users-help@...
>
>

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@...
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. [phone]. 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@...
For additional commands, e-mail: jcs-users-help@...

[Tim Stibbs]

Thanks for that Simon, I had missed the UsagePattern.

However, it doesn't seem to make any difference to the results.

MaxObjects=0 and MaxPurgatorySize=0 together seem to prevent anything going
into either memory or disk cache (so if I do a put, immediately followed by
a get on the same key I get back null). Remove either option and that
doesn't happen.

With either or both or neither of the options above, it all works if I
follow the puts with a small sleep - this would suggest that it is still
running asynchronously.

Thanks again,

Tim.

On 4 August 2010 12:09, Simon Horton <Simon.Horton@...> wrote:

> Hi Tim,
>
> I know you've set MaxObjects to zero so no items go to the memory cache,
> but you may want to also set the DiskUsagePatternName to UPDATE in
> conjunction with the MaxPurgatorySize setting from before?
>
> jcs.default.cacheattributes.DiskUsagePatternName=UPDATE
>
> The UPDATE usage pattern allows items to go to disk on an update. It
> disables the swap. This allows you to persist all items to disk.
>
> http://jakarta.apache.org/jcs/RegionProperties.html
>
>
>
> -----Original Message-----
> From: Tim Stibbs [mailto:stripybadger@...]
> Sent: 04 August 2010 11:46
> To: JCS Users List
> Subject: Re: Guaranteed persistence
>
> Thanks Simon,
>
> That's one of the options I had tried - for some reason it seems to
> result
> in nothing being written to the cache at all. Is there another option
> that I
> need to use in conjunction with MaxPurgatorySize?
>
> On 4 August 2010 11:23, Simon Horton <Simon.Horton@...>
> wrote:
>
> > Hi Tim,
> >
> > Try setting your MaxPurgatorySize to 0 so there is no asynchronous
> > caching of data written to the disk cache, it will reduce your
> > performance but means your data goes straight to disk.
> >
> > jcs.auxiliary.DC.attributes.MaxPurgatorySize=0
> >
> > Purgatory
> > Writing to the disk cache is asynchronous and made efficient by using
> a
> > memory staging area called purgatory. Retrievals check purgatory then
> > disk for an item. When items are sent to purgatory they are
> > simultaneously queued to be put to disk. If an item is retrieved from
> > purgatory it will no longer be written to disk, since the cache hub
> will
> > move it back to memory. Using purgatory insures that there is no wait
> > for disk writes, unecessary disk writes are avoided for borderline
> > items, and the items are always available
> >
> >
> >
> > -----Original Message-----
> > From: Tim Stibbs [mailto:stripybadger@...]
> > Sent: 04 August 2010 08:25
> > To: JCS Users List
> > Subject: Re: Guaranteed persistence
> >
> > I am using CompositeCacheManager.getUnconfiguredInstance(); and
> > configuring
> > it programatically with the following properties:
> >
> > jcs.default=DC
> >
> jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttribut
> > es
> > jcs.default.cacheattributes.MaxObjects=0
> >
> jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory
> > .lru.LRUMemoryCache
> >
> jcs.auxiliary.DC=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheF
> > actory
> >
> jcs.auxiliary.DC.attributes=org.apache.jcs.auxiliary.disk.indexed.Indexe
> > dDiskCacheAttributes
> > jcs.auxiliary.DC.attributes.DiskPath=C:\path\etc
> > jcs.auxiliary.DC.attributes.MaxKeySize=1000
> > jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=1000
> >
> > My main aims are:
> > - guaranteed persistence - once I've added it to the cache, even if
> the
> > application crashes, the key value pair will still be available when
> the
> > app
> > starts up again
> > - a non-infinite cache - I want the number of items in the cache to
> not
> > exceed order of 1000 to conserve disk space, though the exact number
> is
> > not
> > important.
> >
> > Do these sound like something that is possible with JCS? I've looked
> > through
> > all the documentation and can't find anything along these lines.
> >
> > Thanks,
> >
> > Tim.
> >
> > On 3 August 2010 20:17, Jorge Medina <cerebrotecnologico@...>
> > wrote:
> >
> > > Look at :
> > > http://jakarta.apache.org/jcs/RegionProperties.html
> > > and
> > > http://jakarta.apache.org/jcs/IndexedDiskCacheProperties.html
> > >
> > > What are the properties of your disk cache ?
> > >
> > >
> > > On Mon, Aug 2, 2010 at 4:51 AM, Tim Stibbs <stripybadger@...>
> > wrote:
> > > > Hi,
> > > >
> > > > I am looking into using JCS as a disk-based key-value store, and
> it
> > seems
> > > to
> > > > work fine. However if the jvm is terminated, the .key file may not
> > get
> > > > written to, and although the .data file has my data in, when I
> > restart
> > > the
> > > > application it cannot access anything in the cache (presumably due
> > to the
> > > > .key file being empty).
> > > >
> > > > So, is there anyway to force the cache to immediately persist to
> > disk?
> > > > Having MaxObjects=0 on the memory cache seems to help, but still
> > doesn't
> > > > cause the .key file to be written.
> > > >
> > > > I also though I might be able to use ICacheEventLogger to see when
> > data
> > > has
> > > > actually been written to the disk store, but the logging stuff
> > doesn't
> > > seem
> > > > to be in the released version, although it is in the
> documentation?
> > > >
> > > > Does anyone know if it is even possible to do what I am trying to
> > do, or
> > > > have any suggestions?
> > > >
> > > > Thanks.
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jcs-users-unsubscribe@...
> > > For additional commands, e-mail: jcs-users-help@...
> > >
> > >
> >
> > 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@...
> > 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. [phone]. 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@...
> > For additional commands, e-mail: jcs-users-help@...
> >
> >
>
> 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@...
> 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. [phone]. 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@...
> For additional commands, e-mail: jcs-users-help@...
>
>

[Thomas Vandahl-2]

On 02.08.10 10:51, Tim Stibbs wrote:
> I am looking into using JCS as a disk-based key-value store, and it seems to
> work fine. However if the jvm is terminated, the .key file may not get
> written to, and although the .data file has my data in, when I restart the
> application it cannot access anything in the cache (presumably due to the
> .key file being empty).

If you shut down your cache manager in an orderly fashion (dispose()),
the .key file will be written to disk. In a general application, a
shutdown-hook would be a good place to do this. If your application is a
web application, see
http://jakarta.apache.org/jcs/apidocs/org/apache/jcs/utils/servlet/JCSServletContextListener.html
for an alternative.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...

[Tim Stibbs]

Thanks Thomas, it is a webapp, and thanks for the link, but I am concerned
about the case where the webapp terminates abnormally - e.g if the physical
machine crashes - in which case I can't rely on any kind of shut down hooks
running.

Cheers,

Tim.

On 8 August 2010 17:11, Thomas Vandahl <tv@...> wrote:

> On 02.08.10 10:51, Tim Stibbs wrote:
> > I am looking into using JCS as a disk-based key-value store, and it seems
> to
> > work fine. However if the jvm is terminated, the .key file may not get
> > written to, and although the .data file has my data in, when I restart
> the
> > application it cannot access anything in the cache (presumably due to the
> > .key file being empty).
>
> If you shut down your cache manager in an orderly fashion (dispose()),
> the .key file will be written to disk. In a general application, a
> shutdown-hook would be a good place to do this. If your application is a
> web application, see
>
> http://jakarta.apache.org/jcs/apidocs/org/apache/jcs/utils/servlet/JCSServletContextListener.html
> for an alternative.
>
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@...
> For additional commands, e-mail: jcs-users-help@...
>
>

[Thomas Vandahl-2]

On 09.08.10 10:05, Tim Stibbs wrote:
> Thanks Thomas, it is a webapp, and thanks for the link, but I am concerned
> about the case where the webapp terminates abnormally - e.g if the physical
> machine crashes - in which case I can't rely on any kind of shut down hooks
> running.

Well, JCS is a cache after all. My understanding of a cache is that it
only carries data that can be reproduced from somewhere with more or
less effort. If your data is so important that you cannot afford to
loose it, a cache is not the right place to put it, IMO.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...

[Tim Cronin-2]

We need to disable certain caches for an application depending on the
system setup.

Can this be achieved through configuration or by creating a memory
plugin?

If by plugin anyone have a good example, was looking at extending the
LRUMemoryCache
And the just overriding the specific get and set but it's not clear
which functions
Are leveraged by the composit cache for this.

Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...

[Thomas Vandahl-2]

On 27.08.10 21:02, Tim Cronin wrote:
> We need to disable certain caches for an application depending on the
> system setup.
>
> Can this be achieved through configuration or by creating a memory
> plugin?

I would try to set the cache sizes for the respective caches to 0 and
see what happens.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...

[Tim Cronin-2]

Thanks I'm trying with the base AuxCachFactory AuxCache and MemoryCache
interfaces.

I'll post if it works.

-----Original Message-----
From: Thomas Vandahl [mailto:tv@...]
Sent: Saturday, August 28, 2010 3:54 AM
To: JCS Users List
Subject: Re: good example of disabling caching without moding code?

On 27.08.10 21:02, Tim Cronin wrote:
> We need to disable certain caches for an application depending on the
> system setup.
>
> Can this be achieved through configuration or by creating a memory
> plugin?

I would try to set the cache sizes for the respective caches to 0 and
see what happens.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...

[Tim Cronin-2]

In IndexedDiskCacheAttributes (from jad)

    public AuxiliaryCacheAttributes copy()
    {
      try
      {
        return (AuxiliaryCacheAttributes)clone();
      }
      catch(Exception e)
      {
        return this;
      }
    }

Would expect that CloneNotSupportedException means the system is
foobared but
With any other exception returning "this" could create even more
problems and
Not be easily tracked down.

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@...
For additional commands, e-mail: jcs-users-help@...