I have seen similar posts but with no clear answer:
https://github.com/spring-projects/spring-session/issues/1017,
https://github.com/spring-projects/spring-session/issues/1103
on our environment whenever we create a session the commands that are executed on our redis are the below:
1589154520.098715 [0 127.0.0.1:35190] "HMSET" "spring:session:player-api:service:sessions:ca14663d-f49d-481f-aebd-61e1722eb4df" "lastAccessedTime" "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01r\x00\xfd\x9c\"" "maxInactiveInterval" "\xac\xed\x00\x05sr\x00\x11java.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\a\b" "creationTime" "\xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01r\x00\xfd\x9c\"" "sessionAttr:SPRING_SECURITY_CONTEXT" "\xac\xed\x00\x05sr\x00=org.springframework.security.core.context.SecurityContextImpl\x00\x00\x00\x00\x00\x00\x01\xa4\x02\x00\x01L\x00\x0eauthenticationt\x002Lorg/springframework/security/core/Authentication;xpsr\x00Pcom.openbet.api.player.security.shared.authentication.OpenbetAuthenticationToken\xfb\x0c\xde\xad]cL\xcf\x02\x00\x02L\x00\x0bcredentialst\x00\x12Ljava/lang/Object;L\x00\tprincipalq\x00~\x00\x04xr\x00Gorg.springframework.security.authentication.AbstractAuthenticationToken\xd3\xaa(~nGd\x0e\x02\x00\x03Z\x00\rauthenticatedL\x00\x0bauthoritiest\x00\x16Ljava/util/Collection;L\x00\adetailsq\x00~\x00\x04xp\x01sr\x00&java.util.Collections$UnmodifiableList\xfc\x0f%1\xb5\xec\x8e\x10\x02\x00\x01L\x00\x04listt\x00\x10Ljava/util/List;xr\x00,java.util.Collections$UnmodifiableCollection\x19B\x00\x80\xcb^\xf7\x1e\x02\x00\x01L\x00\x01cq\x00~\x00\x06xpsr\x00\x13java.util.ArrayListx\x81\xd2\x1d\x99\xc7a\x9d\x03\x00\x01I\x00\x04sizexp\x00\x00\x00\x00w\x04\x00\x00\x00\x00xq\x00~\x00\rpt\x00\x00t\x00\ranonymousUser"
1589154520.099238 [0 127.0.0.1:35190] "SADD" "spring:session:player-api:service:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:anonymousUser" "\xac\xed\x00\x05t\x00$ca14663d-f49d-481f-aebd-61e1722eb4df"
1589154520.099801 [0 127.0.0.1:35190] "APPEND" "spring:session:player-api:service:sessions:expires:ca14663d-f49d-481f-aebd-61e1722eb4df" ""
1589154520.100706 [0 127.0.0.1:35190] "PEXPIRE" "spring:session:player-api:service:sessions:expires:ca14663d-f49d-481f-aebd-61e1722eb4df" "1800000"
1589154520.100908 [0 127.0.0.1:35190] "PEXPIRE" "spring:session:player-api:service:sessions:ca14663d-f49d-481f-aebd-61e1722eb4df" "2100000"
Issue 1: First of all we noticed that through our health checks spring is creating sessions for anonymous users. Is there a way to prevent redis to create sessions for anonymous users?
Issue 2: Second we see that for all users redis is creating a key with no expiration time:
127.0.0.1:6380> ttl "spring:session:player-api:service:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:4759e891-8d67-4a32-9df2-654e192fd78e"
(integer) -1
According to here: https://docs.spring.io/spring-session/docs/1.3.0.RELEASE/reference/html5/#api-redisoperationssessionrepository-storage :
"SADD" "spring:session:player-api:service:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME:anonymousUser" "\xac\xed\x00\x05t\x00$ca14663d-f49d-481f-aebd-61e1722eb4df"
no similar sadd command is executed.
For our logged in users when they logged out then all related keys are deleted from redis. But when waiting for session to timeout , the keys with no expiration time are not deleted
Why this key is created? Why it has no expiration time? and how/when redis finally deletes it?Cause according to the cleanup cron job the keys are deleted according to expiration time.
Thanks in advance,
Lena
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 searched a lot but could not find anything suitable. i found this Redis::command('flushdb'); but this flush all of my others keys too which will needed to complete queued job.
Since OP said it is related to horizon, it keeps the failed jobs in a the redis under multiple keys.
Get your HORIZON_PREFIX from the configuration file; let's say it is foo.
You either invoke the following commands in your codebase (tinker maybe)
Redis::connection()->del('foo:failed:*');
Redis::connection()->del('foo:failed_jobs');
Or you can use redis-cli
127.0.0.1:6379> del foo:failed:* foo:failed_jobs
(integer) 1
127.0.0.1:6379>
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.
I've got a Redis client subscribed to __keyevent#0__:expired notifications. It works perfectly, either when the key expires by itself (ttl reached) or when I expire them manually with a number of seconds greater than 0, like so:
EXPIRE myKey 1
The subscriber sees the expired event and can therefore take some actions.
However, if I want to manually delete the key and have the subscriber notified, I use EXPIRE with 0 as the number of seconds:
EXPIRE myKey 0
The key gets deleted, but the subscriber doesn't receive anything.
I can't see anything related to this in the doc. Can anyone explain this behavior?
From reviewing the source code (expire.c, ~252), setting an expiry value of <=0 (or using EXPIREAT with a time in the past) results in a deletion of the key rather than an expiry (and accordingly a DEL notification rather than an EXPIRED event).
This behavior is indeed undocumented and it would be good if you could submit a PR that fixes that to the documentation repo (https://github.com/antirez/redis-doc).
How to completely disable the lock users in SAP? What setting controls this (login / failed_user_auto_unlock)?
As far as I can see, that's not possible. You can try to set login/fails_to_user_lock to 99 and login/failed_user_auto_unlock to 1, but this will only mean that users will be licked after 99 failed attempts and unlocked again at midnight.
See http://help.sap.com/saphelp_470/helpdata/en/22/41c43ac23cef2fe10000000a114084/frameset.htm for a list of the parameters related to users and security.