I'm not sure if this can be done at all.
I'm trying to set Dalli to delete a memcache after 3 seconds (just to experiment)
dalli = Dalli::Client.new
dalli.add("test1","value", 3)
dalli.get("test1").should eql "value"
sleep(10)
dalli.get("test1").should eql nil
In the code, I have set TTL for 3 seconds, and then I expect that after 3 seconds the "test1" would be deleted but apparently not. So, the test fails in the second assertion. How can I ask Dalli to expire a key/value after a certain amount of time?
Thanks a lot.
You can only explicitly remove a key by calling delete or implicitly via TTL.
Does this happen with a different key besides 'test1'? Try changing your 'add' command to a 'set' command. The add command is conditional, it only sets the value if doesn't already exist. Is it possible you already set that key previously (although unlikely from the code you provided) without specifying a TTL? If you didn't specify a TTL the item is cached indefinitely.
Put the following in your session_store.rb initializer
Rails.application.config.session_store ActionDispatch::Session::CacheStore, :expire_after => 20.minutes
That will expire the cache after 20 minutes.
Related
I have a question about Redis caching.
I wrote some code to cache some information and it works fine, but is there a way to check what's being stored inside of it through redis-cli? I just want to make sure that the value gets deleted after 10 minutes.
how I store stuff:
Cache::store('redis')->put('inventory_' . $this->user->steamid64, $items, 15);
Since you are using laravel's Cache class instead of Redis - then you need to check for the prefix. By default it ships like this in config/cache.php
'prefix' => env('CACHE_PREFIX', 'laravel')
If there is a prefix(and it is laravel) it is going to be like this (if there is no prefix then you may discard laravel: from the key names)
127.0.0.1:6379> get laravel:inventory_1
"somevalue"
127.0.0.1:6379> ttl laravel:inventory_1
(integer) 885
127.0.0.1:6379>
For the "development" purpose you may also use monitor command to see which commands are executed in redis. It is going to print like this;
127.0.0.1:6379> monitor
OK
1591091085.487083 [0 127.0.0.1:51828] "set" "myinventory_1" "myvalue" "EX" "900"
1591091091.143395 [0 127.0.0.1:51828] "get" "myinventory_1"
1591091095.280724 [0 127.0.0.1:51828] "ttl" "myinventory_1"
Side note: You don't need to call store method if your default cache driver is already redis.
Enter the redis-cli and use:
keys * to see list of all keys
TTL my_key_name to see remaining expire time of the key
You can execute any of Redis commands inside of the redis-cli. It's good tool for development.
I am trying to understand Laravels session handler and can't find anything online. At the moment, in session.php I am doing
'lifetime' => 10,
I have the session driver set to file. So from what I have read, this sets the idle timeout of the session to 10 minutes.
So what does idle mean in this case? I am assuming it means if no request is sent to the server within 10 minutes it will expire. Is this correct?
Also, how can it tell if no request has been sent within 10 minutes? I have taken a look at the session file within storage, and I do not see any timestamp.
So how exactly does all of this work?
Thanks
Yes you are correct: if you don't send any request after the lifetime config value the session will be destroyed.
The Illuminate\Session\FileSessionHandler class has a gc() function, it is a garbage collector function that has a probability to be called on every request, you can control the chances with the session.lottery config value. This function destroy each session file that has a modified timestamp older than now - lifetime.
You can find the Illuminate\Session\FileSessionHandler class in the file vendor/laravel/framework/src/Illuminate/Session/FileSessionHandler.php if you want to take a look at the source code.
Recently, I'm using Redis to cache token for OpenStack Keystone. The function is fine, but some expired cache data still in Redis.
my Keystone config:
[cache]
enabled=true
backend=dogpile.cache.redis
backend_argument=url:redis://127.0.0.1:6379
[token]
provider = uuid
caching=true
cache_time= 3600
driver = kvs
expiration = 3600
but some expired data in Redis:
Data was over expiration time, but still in here, because the TTL is -1.
My question:
How can I change settings to stop this rubbish data created?
Is some gracefully way to clean it up?
I was trying to use command 'keystone-manage token_flush', but after reading code, I realized this command just clean up the expired tokens in Mysql
I hope this question still relevant.
I'm trying to do the same thing as you are, and for now the only option I found working is the argument on dogpile.cache.redis: redis_expiration_time.
Checkout the backend dogpile.redis API or source code.
http://dogpilecache.readthedocs.io/en/latest/api.html#dogpile.cache.backends.redis.RedisBackend.params.redis_expiration_time
The only problem with this argument is that it does not let you choose a different TTL for different categories, for example you want tokens for 10 minutes and catalog for 24 hours or so. The other parameters on keystone.conf just don't work from my experience (expiration_time and cache_time on each category)... Anyway this problem isn't relevant if you are using redis to store only keystone tokens.
[cache]
enabled=true
backend=dogpile.cache.redis
backend_argument=url:redis://127.0.0.1:6379
// Add this line
backend_argument=redis_expiration_time:[TTL]
Just replace the [TTL] with your wanted ttl and you'll start noticing keys with ttl in redis and after a while you will see that they are no more.
about the second question:
This is maybe not the best answer you'll see, but you can use OBJECT idletime [key] command on redis-cli to see how much time the specific key wasn't used (even GET reset idletime). You can delete the keys that have bigger idletime than your token revocation using a simple script.
Remember that the data on Redis isn't persistent data, meaning you can always use FLUSHALL and your OpenStack and keystone will work as usual, but ofc the first authentications will take longer.
Currently i can use this below code to verify the object size:
expect((#page.elements).size).to eq(12)
But i want to use wait_for / wait_until command until those elements(collection of objects) loads. So i want to use like this below:
#page.wait_until_elements.size == 12
How can i do that? Please help.
A number of the Site-Prism methods support the Capybara query options. In this particular case, you can use the :count option to specify the exact number you want to wait for.
expect(#page).to have_elements :count => 12, :wait => 10
For more details, see the Using Capybara Query Options section of the documentation.
Worth pointing out that whilst the answers here are from a while ago (And for anyone else finding this answer since), the quality of capybara queries has vastly increased.
The best option here to use is probably minimum: 12 which would wait until you have at least 12 of them, and it would wait the Capybara.default_wait_time implicitly
If you wanted to use a waiter in-line you could also specify that with a wait key
#page.elements(wait: 3, minimum: 12) - This would wait up to 3 seconds before complaining the set of elements wasn't there or until you had 12. In which case it would continue.
Using the devel module I can see a lot of calls to cache_get() and cache_set(). After how long does a cached value need to be refreshed? Does the cache get invalidated every few minutes?
The module that is using cache_set sets the expiration in the call. Some things have explicit durations, others have permanent or semi-permanent lifetimes, based on the situation.
Caches get explicitly cleared when you invoke the method through the admin interface (or drush), or otherwise through the use of drupal_flush_all_caches or cache_clear_all.
Lately, I have been using a hook_cron to clear certain cache tables each night.
EDIT to answer comment:
To see which cache, I usually put this in a separate script somewhere:
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
header("Content-Type: text/plain; encoding=utf-8");
$user = user_load(1);
print "Modules implementing hook_cron:\n" . implode("\n", module_implements('cron'));
To see expirations, examine the various cache tables in the database and look at the expire column. Modules can set expirations on each individual call to cache_set, so it can vary entry by entry.