Session: Error while trying to free lock for ci_session

@Narf

what about API calls and storing data to Session?
When user logs in app I store his data in session. Because I do not want to call API to fetch user data on every single request specially because users do not change their information very often. Just as example, when user changes the data, call API (before call I need to check is user logged in or not), wait for api, if there is no error in API response update the Session. This is really huge problem with locking. My app have 3 platforms, Android, IOS nad Website.
I can not store data in session immediately after the request like this guy has described it here: http://konrness.com/php5/how-to-prevent-...-requests/
Our app is on AWS, have 5 servers behind ELB and using memcached for sessions.
I am trying to fix this for 3 days with no success.
Added session_write_close() after set_userdata call but still 5s response time.
I hope it is clear, now.
Maybe BUT maybe I am doing something wrong or this is total mess up.

When you say API are you using CI's session library methods to get/set data or did you build a layer on top of that? You could sticky file sessions by setting it on your load balancer until you can figure out the root cause.

For us (using Redis not Memcache) requests went from 1-2s down to the normal 100-200ms adding session_write_close.

API is not using sessions, on website in Session is saved api_key for authorization. API is rest service (POST and GET), which is on another ELB.
On AWS we are using their ELB, how can I setup there sticky file sessions?
Maybe I will try with Redis, who knows maybe I will have more luck

It's a setting on the load balancer. On the main dashboard click EC2, then Load Balancers under Load Balancing on the left, select a load balancer, then click the edit link under Port Configuration.

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?

It's unexpected behavior and as such it has to be logged - that's all the reasoning there needs to be.

This looks fishy though:

Code:

{
      "file":"\/var\/app\/current\/codeigniter\/application\/libraries\/Session\/MY_Session.php",
      "line":9,
      "function":"session_write_close",
      "args":[

      ]
   },

It's unexpected behavior and as such it has to be logged - that's all the reasoning there needs to be.

I understand what you're getting at but that response is not useful for debugging...

I didn't want to mix raw session commands with CI's so I overloaded the session library to add a method:

Code:

    public function write_close( ) {
        session_write_close( );
    }

This is seriously ridiculous.
No one here reported any solution for my problem.
I did everything as it should be with session_write_close() but just don't work.
Maybe creators will do something in future with this, who knows.

@spjonez
Thanks but that is bad practice
Anyway, what to add in CI Configuration for this? Maybe to add with ELB for some time until I setup up NFS.
Most probably I will go with files and NFS like GlusterFS and pray for AWS to release EFS in Ireland.

It's unexpected behavior and as such it has to be logged - that's all the reasoning there needs to be.

I understand what you're getting at but that response is not useful for debugging...

I didn't want to mix raw session commands with CI's so I overloaded the session library to add a method:

Code:

    public function write_close( ) {
        session_write_close( );
    }

Well, I don't have another response.
If I did, we'd have the whole thing figured out by now.

@spjonez
Thanks but that is bad practice

How so? If you're using CI's $this->session->userdata or flashdata methods I don't see how adding a $this->session->write_close method by overloading the session library (MY_Session not hacking core files) to continue that trend is bad form.

Well, I don't have another response.
If I did, we'd have the whole thing figured out by now.

Is there anything else I can provide that would be useful to you as a core developer or are we on our own?

@spjonez

because ELB will stick with one EC2 instance for single user as long as session is live.
In highly load apps that could be a problem.
I will try for sure.
But what to put in CI Session config file and how to setup php.ini for this?