| Session: Error while trying to free lock for ci_session |
So like this:
PHP Code: $this->session->set_userdata("notifications", $notifacations);But I have some AJAX calls that do nothing with writing to session but still response is 5s or maybe I am to tired? 
(05-20-2016, 06:34 AM)jcarpenter Wrote:(05-20-2016, 02:06 AM)Narf Wrote: Changing php.ini settings won't change anything. I don't see how this could happen with 3.0.6 unless there's an actual error while trying to free the lock in question ... (05-20-2016, 06:14 PM)consigliere Wrote: I have the same issue. That's not the same issue, and you're hijacking the thread.
Ok, I will refactor my code to use session_write_close(); after $this->session->set_userdata($data, $value);
If this is the reason why is working so slow? What about reading the session, does it do locking or I should not be worry about it? In php.ini, should I leave as it is or I need to change something?
(05-24-2016, 11:26 PM)Narf Wrote:(05-20-2016, 06:34 AM)jcarpenter Wrote:(05-20-2016, 02:06 AM)Narf Wrote: Changing php.ini settings won't change anything. So how do I determine if there is an "actual error while trying to free the lock in question"? (05-25-2016, 05:26 AM)jcarpenter Wrote:(05-24-2016, 11:26 PM)Narf Wrote: I don't see how this could happen with 3.0.6 unless there's an actual error while trying to free the lock in question ... Debugging it on your own? The error is caused by a delete() call failing for a reason different than RES_NOTFOUND - this is extremely easy to find if you just search for the error message. I can't help without more info ... You haven't given any details other than an obfuscated error message. How often does this happen? Under what conditions exactly? How do we reproduce it? (not that I have a Memcache instance to work with, but still ...) Is it reproducible at all?
I have been playing around with this and have concluded the following:
1) The problem doesn't occur if I use 'files' for sessions 2) The problem does occur if I use 'database' or 'memcached', which lead me to believe it was a locking issue 3) I have many calls occurring at once (ajax) but none conflict to the data being written into session 4) If I turn off memcached file locking the number of errors drops almost completely, but not entirely 5) I cannot re-produce the problem on demand and haven't determined yet what are the circumstances in which this occurs Thanks, Joe (05-25-2016, 05:50 AM)jcarpenter Wrote: I have been playing around with this and have concluded the following: This is generic info that we already have, can't really get anything from it. To elaborate: 1) We already know it's memcached-specific - the 'files' driver doesn't produce that message. 2) The 'database' driver too doesn't produce that error message, only memcached and redis do. And yes - it is related to locking ... the message says so. 3) Don't really get what you mean by that last part about conflicts but ... ok 4) What do you mean by "turn off memcached file locking"? Are you talking about Memcache server configuration? CI_Session_memcached_driver has nothing to do with files and (very intentionally) doesn't give you any control over locking - in that context, what you're saying doesn't make any sense. 5) That's the most important part really ... if we don't know how to reproduce it, we don't know anything. Unfortunately, until you figure out that last point, nobody would be able to help. (05-25-2016, 06:12 AM)Narf Wrote: Unfortunately, until you figure out that last point, nobody would be able to help. Can you think of any Redis settings that could cause this? What's really odd is that I never see the error when I'm developing locally with Redis installed on my machine. The only time I can produce the error is in our staging/production environments on AWS. Redis is a separate Elasticache Server it's not installed on the web nodes- they're load balanced with Elasticbeanstalk. Scratch that, I was able to trigger it on my local machine by triggering two concurrent AJAX requests. It doesn't happen every time I'll try to narrow down a set of actions that can trigger it reliably. On AWS I'm running Redis 2.8.24 the latest version they have available. Locally I've tried both 2.8.24 and 3.02 and cannot reproduce the error. It's difficult to reproduce on staging but happens very frequently on production. Could Redis be running out of memory? Here's a screenshot of the parameter group and some metrics, do either of these help? I managed to trigger it a few times on staging and attached the stack trace. Testing notes: 1. The error occurs with Redis installed on the same machine (Macbook) and when it's a separate server (AWS). 2. I can make our app fire 3 concurrent AJAX requests and it does not trigger the error. I was able to trigger it with two in dev, once. 3. It's not tied to aborting AJAX requests. I can make that happen with a certain set of actions and the error doesn't appear.
I'm not an experienced with managing Redis and/or Memcache servers, but yes - being cache stores, when they run out of memory, they'll just drop the oldest entries, so that's a possible cause.
With Memcached, this is unavoidable as it doesn't support any kind of persitance. Redis can persist data, but doesn't by default (dunno how the appropriate settings are named). In fact, I just stumbled upon this earlier today: https://medium.com/@adil/storing-session....6r43twd8x
After digging into the metrics I don't think my case is a memory issue. According to CloudWatch the production Redis server has never come close to capacity, and I've been able to trigger it on staging (same RAM as production and <2 users) and in dev (local single user).
When you built the library, what issues caused you to put that message in? Do you have any thoughts on what we can look for? |
| Welcome Guest, Not a member yet? Register Sign In |
