Welcome Guest, Not a member yet? Register   Sign In
redis driver _get_lock set lock_key problem
#1

Hi there,

i am using CI 3.1.6, latest php7.0-redis.

I get following error messages multiple times a day (30+ ajax requests per second):
- Session: Error while trying to obtain lock for ci_session:...
- Severity: Warning --> session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (tcp://localhost:6379) Unknown 0

I added debug information to the _get_lock method inside Session_redis_driver.
$ttl in line 338 is -2 but _redis->set($lock_key...) in line 345 returns FALSE because the lock_key already exists at this position (or it sets the key and returns FALSE for another reason).

Is it possible, that another task creates this lock_key meanwhile? What else could be the problem that _redis->set returns false but lock_key exists with ttl 300 after it?

(I tried to call session_write_close() in constructor of my application to remove the lock faster but then the above error is shown for that line of code)

Thanks a lot, best regards,
helot
Reply
#2

(10-12-2017, 03:00 AM)helot Wrote: Is it possible, that another task creates this lock_key meanwhile? What else could be the problem that _redis->set returns false but lock_key exists with ttl 300 after it?

Yes, this:

(10-12-2017, 03:00 AM)helot Wrote: (30+ ajax requests per second)
Reply
#3

Hi,

sorry, my mistake...
These ajax requests are not fired by the same device, there are 30+ devices, one ajax request each per second - they should have their own session_id - am i right?

Thank you
Reply
#4

Correct, they should have separate session IDs.

However, it's also important how much time these requests take to process. One hung request would block all subsequent ones from the same device, and you'll accumulate a lot of them with 1 per second.
Reply
#5

(10-13-2017, 02:19 AM)Narf Wrote: Correct, they should have separate session IDs.

However, it's also important how much time these requests take to process. One hung request would block all subsequent ones from the same device, and you'll accumulate a lot of them with 1 per second.

Hi,

the duration of one request is 70 ms.
The ajax requests are on a long poll basis - every request is waiting until the previous request has been completed.

What i found out is, that it could be a problem with loading images... Every image is getting its contents via .php url. There could be problems with redis while loading the image data and ajax calls meanwhile. Tests with session_write_close() at these points are running...

Thanks a lot
Reply
#6

Hi,

i went deeper and deeper into the redis driver handling (in CI 3.1.6.).
Why is it necessary to acquire a lock on read (Line 171 in libraries/Session/drivers/Session_redis_driver.php)?
In my opinion this line of code produces 99 % of all redis errors because the session is locked from the beginning of the first read until at least a session_write_close() call... -> locks are only needed for writing purposes, am i right?

Thank you Smile
Reply
#7

Locks are necessary because of writes, yes, but that doesn't mean they're only necessary during writes.
Reply
#8

(10-21-2017, 05:51 AM)helot Wrote: Hi,

i went deeper and deeper into the redis driver handling (in CI 3.1.6.).
Why is it necessary to acquire a lock on read (Line 171 in libraries/Session/drivers/Session_redis_driver.php)?
In my opinion this line of code produces 99 % of all redis errors because the session is locked from the beginning of the first read until at least a session_write_close() call... -> locks are only needed for writing purposes, am i right?

Thank you Smile

Were you able to conclude anything regarding this issue? I'm having exactly the same problem and wondering whether you found a solution?
Reply
#9

There's a few things you can do to reduce this, they won't fix it completely but it will help.

1) Upgrade to the latest versions of Redis and phpredis.
2) Call session_write_close() in every request as soon as you're done writing session data. You can still read session data after you call this just not write it.

Newer versions of phpredis seem to show this message less frequently. There's quite a few threads on here about it and I don't think anyone's definitively figured out what the cause is.
Reply
#10

(09-11-2018, 12:18 PM)spjonez Wrote: There's a few things you can do to reduce this, they won't fix it completely but it will help.

1) Upgrade to the latest versions of Redis and phpredis.
2) Call session_write_close() in every request as soon as you're done writing session data. You can still read session data after you call this just not write it.

Newer versions of phpredis seem to show this message less frequently. There's quite a few threads on here about it and I don't think anyone's definitively figured out what the cause is.

Thanks @spjonez. I've updated Redis and php redis and am not really seeing any change.

Been reading about the additional options available for session_start in PHP 7 on https://ma.ttias.be/php-session-locking-...-requests/

Specifically:

Code:
session_start([
   'read_and_close' => true,
]);

Is that something to try or am I completely on the wrong track?
Reply




Theme © iAndrew 2016 - Forum software by © MyBB