Welcome Guest, Not a member yet? Register   Sign In
Session: Error while trying to free lock for ci_session
#11

(This post was last modified: 05-24-2016, 08:41 PM by consigliere.)

So like this:
PHP Code:
$this->session->set_userdata("notifications"$notifacations);
session_write_close();
//this is ok to do?
echo $this->session->userdata["lang"]; 
Basically after every call set_user_data("foo", "bar) I have to use session_write_close()?
But I have some AJAX calls that do nothing with writing to session but still response is 5s or maybe I am to tired? Smile
Reply
#12

(05-20-2016, 06:34 AM)jcarpenter Wrote:
(05-20-2016, 02:06 AM)Narf Wrote: Changing php.ini settings won't change anything.
Which CI version are you using? If it's not the latest, upgrade to it.

We are on the latest version, 3.0.6

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.
Our site is hosted on AWS and we have ELB with 5 servers behind.
Yesterday we upgraded CI on 3.0.6 version.
We are using memcached for handling sessions.
In php.ini session handler is setup for memcached .
When I try to use CI with memcached site is loading forever.
But when I setup CI for using files the site is loading normally but have some weird issues.
For example on one page is fine but when I click on the other I have been logout or even use some previous users which I was logged in.
What should I do to make this work as it is supposed to work.
Thanks

That's not the same issue, and you're hijacking the thread.
Reply
#13

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?
Reply
#14

(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.
Which CI version are you using? If it's not the latest, upgrade to it.

We are on the latest version, 3.0.6

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.
Our site is hosted on AWS and we have ELB with 5 servers behind.
Yesterday we upgraded CI on 3.0.6 version.
We are using memcached for handling sessions.
In php.ini session handler is setup for memcached .
When I try to use CI with memcached site is loading forever.
But when I setup CI for using files the site is loading normally but have some weird issues.
For example on one page is fine but when I click on the other I have been logout or even use some previous users which I was logged in.
What should I do to make this work as it is supposed to work.
Thanks

That's not the same issue, and you're hijacking the thread.

So how do I determine if there is an "actual error while trying to free the lock in question"?
Reply
#15

(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 ...

So how do I determine if there is 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?
Reply
#16

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
Reply
#17

(05-25-2016, 05:50 AM)jcarpenter Wrote: 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

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.
Reply
#18

(This post was last modified: 05-25-2016, 01:05 PM by spjonez.)

(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.

Attached Files Thumbnail(s)
       
Reply
#19

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
Reply
#20

(This post was last modified: 05-25-2016, 10:34 AM by spjonez.)

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?
Reply




Theme © iAndrew 2016 - Forum software by © MyBB