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 trekmbikes <sp...@slickapps.com> on 2008/05/21 19:04:40 UTC
Hot / on-the-fly update of config
Hello,
My project needs to add flexibility such that when our real data source goes
offline, JCS continues to return the cached items until some point later
when we bring the DB back online. We will handle the condition gracefully
when a non-cached item is requested during the downtime. The idea is to keep
the content flowing for those users who are already logged in and are only
requesting cached items.
The items returned by the cache are normally time-bound (in fact, they are
user session objects) - so we normally use the cache parameter
"MaxLifeSeconds" so they expire automatically. Is there a way to disable the
MaxLifeSeconds parameter and re-enable it later?
If not, I'm also considering storing wrapper objects for everything in the
cache, that contain both the real object I'm storing and an insertion millis
value. We would perform the timeout logic ourselves - and remove the
MaxLifeSeconds completely. Has anyone tried this?
--
View this message in context: http://www.nabble.com/Hot---on-the-fly-update-of-config-tp17364367p17364367.html
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: Hot / on-the-fly update of config
Posted by Joshua Szmajda <jo...@loki.ws>.
I have need to track what keys are present in my cache, and I use a
combination of an ArrayList of what keys I'm using and a lock to avoid
two servers updating that arraylist simultaneously. I don't track all
keys in my caches this way, but for the cache where this matters it
works quite well, and is quick.
It would be convenient if there were an API-level method for creating
this behavior on certain regions, however. I'd love to see a
configuration option present. It would be fairly trivial to implement, I
think.
-Josh
trekmbikes wrote:
> From Aaron Smuts, developer of JCS, via email:
>
> ---------------------------------------------------
>
> I've never encountered your need before--to update the
> element attributes on all the items in the cache.
> Perhaps there is a better solution to your larger
> problem.
>
> Retrieving all keys can be problematic if you have a
> remote configuration. I don't want API calls that
> only work for some configurations. I'm still thinking
> about this, and have been for some time.
>
> The best way to to update the element attributes for
> all the items, would be to have the cache do it for
> you. It can make sure none slip through during the
> process, etc. This would be expensive for the disk
> cache!
>
> Let's move the discussion to the list.
>
> Aaron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: Hot / on-the-fly update of config
Posted by trekmbikes <sp...@slickapps.com>.
>From Aaron Smuts, developer of JCS, via email:
---------------------------------------------------
I've never encountered your need before--to update the
element attributes on all the items in the cache.
Perhaps there is a better solution to your larger
problem.
Retrieving all keys can be problematic if you have a
remote configuration. I don't want API calls that
only work for some configurations. I'm still thinking
about this, and have been for some time.
The best way to to update the element attributes for
all the items, would be to have the cache do it for
you. It can make sure none slip through during the
process, etc. This would be expensive for the disk
cache!
Let's move the discussion to the list.
Aaron
--
View this message in context: http://www.nabble.com/Hot---on-the-fly-update-of-config-tp17364367p17460803.html
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: Hot / on-the-fly update of config
Posted by trekmbikes <sp...@slickapps.com>.
Niall, those are some great ideas. I will put those all down as proposals,
particularly the last one is appealing since I wouldn't have to move from
region to region. There may be some synchronization issues, e.g. if
something requests it from the cache after I've removed it but before I've
restored it.
Can one of the JCS authors comment on the live reconfiguration of the
isEternal attribute, or the MaxTimeSeconds attribute?
Thanks!
I know that you can configure cache attributes for each element (object)
you store in the cache programmatically.
There's an example of programmatic configuration here:
http://jakarta.apache.org/jcs/ElementAttributes.html
I don't know if attributes can be changed once configured however.
Personally, we aren't configuring elements programmatically, we just let
them inherit the region settings, and all servers are deployed with the
same region settings.
You basically want to set IsEternal=true for all your cached elements
when your DB goes offline.
Say in the worst case you can't reconfigure settings, as an alternative
you could...
Pre-configure (in the .ccf file) a new region called "DBOfflineRegion"
or something with IsEternal=true, but otherwise with settings similar to
those you use when your DB is online.
When your code detects that the DB is down, it iterates through all
cached items in your normal region, and copies them into the
DBOfflineRegion. It could remove them from the normal region as it
copies them, to save memory I guess.
Subsequently while the DB is down, your code is programmed to fetch data
from the DBOfflineRegion, as long as the DB remains down. When the DB
comes back online your code reverts back to using the normal region, and
clears the DBOfflineRegion.
Of course none of this would be necessary if you can just change
IsEternal or MaxLifeSeconds settings on-the-fly. You might be able to
effectively do that by retrieving everything from your normal region and
re-putting objects back into the same region with different attributes.
In general re-configuring everything in a distributed cache might
complicate things. Someone else could advise if it's supported.
--
View this message in context: http://www.nabble.com/Hot---on-the-fly-update-of-config-tp17364367p17375334.html
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: Hot / on-the-fly update of config
Posted by Niall Gallagher <ni...@switchfire.com>.
I know that you can configure cache attributes for each element (object)
you store in the cache programmatically.
There's an example of programmatic configuration here:
http://jakarta.apache.org/jcs/ElementAttributes.html
I don't know if attributes can be changed once configured however.
Personally, we aren't configuring elements programmatically, we just let
them inherit the region settings, and all servers are deployed with the
same region settings.
You basically want to set IsEternal=true for all your cached elements
when your DB goes offline.
Say in the worst case you can't reconfigure settings, as an alternative
you could...
Pre-configure (in the .ccf file) a new region called "DBOfflineRegion"
or something with IsEternal=true, but otherwise with settings similar to
those you use when your DB is online.
When your code detects that the DB is down, it iterates through all
cached items in your normal region, and copies them into the
DBOfflineRegion. It could remove them from the normal region as it
copies them, to save memory I guess.
Subsequently while the DB is down, your code is programmed to fetch data
from the DBOfflineRegion, as long as the DB remains down. When the DB
comes back online your code reverts back to using the normal region, and
clears the DBOfflineRegion.
Of course none of this would be necessary if you can just change
IsEternal or MaxLifeSeconds settings on-the-fly. You might be able to
effectively do that by retrieving everything from your normal region and
re-putting objects back into the same region with different attributes.
In general re-configuring everything in a distributed cache might
complicate things. Someone else could advise if it's supported.
On Wed, 2008-05-21 at 10:04 -0700, trekmbikes wrote:
> Hello,
>
> My project needs to add flexibility such that when our real data source goes
> offline, JCS continues to return the cached items until some point later
> when we bring the DB back online. We will handle the condition gracefully
> when a non-cached item is requested during the downtime. The idea is to keep
> the content flowing for those users who are already logged in and are only
> requesting cached items.
>
> The items returned by the cache are normally time-bound (in fact, they are
> user session objects) - so we normally use the cache parameter
> "MaxLifeSeconds" so they expire automatically. Is there a way to disable the
> MaxLifeSeconds parameter and re-enable it later?
>
> If not, I'm also considering storing wrapper objects for everything in the
> cache, that contain both the real object I'm storing and an insertion millis
> value. We would perform the timeout logic ourselves - and remove the
> MaxLifeSeconds completely. Has anyone tried this?