XF 1.4 Users getting logged out after moving sessions to Memcached

[DeltaHF]

I recently started using Memcached to store user sessions, and some Firefox and Android users are now reporting being logged out of their accounts intermittently and prematurely. I did some testing and was able to replicate the issue a few times with Firefox 36.0.4 on OS X. I have no idea how this could be browser related, but Chrome and many of my other users are not experiencing problems.

Here's my caching configuration in config.php:

// Cache
$config['cache']['enabled'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'gtpxf_';
$config['cache']['cacheSessions'] = true;
$config['cache']['backend'] = 'memcached';
$config['cache']['backendOptions'] = array(
    'compression' => false,
    'servers' => array(
        array(
            // your memcached server IP /address
            'host' => 'localhost',
           
            // memcached port
            'port' => 11211,
        )
    )
);

Here's my memcached stats...as you can see, there's plenty of memory available:


I have also attached my phpinfo page below.

One question/point of note...in my config.php, the backend is defined as 'memcached'. I've seen many others here use 'Libmemcached' instead. I don't really understand Libmemcached enough to know why it would be used there, but I believe it is installed with @eva2000's Centminmod (which I've used to set up the server). While troubleshooting, I switched config.php to use 'Libmemcached', but it broke the forums and filled the error logs with the following:

ErrorException: Memcached::get(): could not read long value, too big - library/Zend/Cache/Backend/Libmemcached.php:166

I'm not sure what to do next.

 

[Mike]

The change is entirely server side, so browsers won't be involved.

I do note that you only have 16MB allocated, so if a large number of sessions come in (such as from a bot), that could push other stuff out and that would cause the issue. You likely want to increase your allocation.

Alternatively, users can choose to stay logged in and that will effectively prevent the issue.

 

[DeltaHF]

I suspected memory might be an issue, but I immediately viewed the stats after I had personally experienced the problem, and consumption was well below 60% as displayed in the screenshot. I commented the 'cacheSessions' line in config.php last night, and the complaining users reported the problem was gone.

No memcached sessions for me, I suppose.

 

[MattW]

What version of Memcache are you using, and what options do you have set for the daemon?

In the frontend options, you can set a litetime. Set this to zero, and the session cache will not be cleared out prematurely.

$config['cache'] = array(
    'enabled'                      => true,
    'cacheSessions'                => true,
    'frontend'                     => 'Core',
    'frontendOptions'              => array(
        'caching'                  => true,
        'cache_id_prefix'          => 'mws_',
        'automatic_serialization'  => true,
        'lifetime'                 => 0),
    'backend'                      => 'Memcached',
    'backendOptions'               => array(
        'servers'                  => array(
            array(
                'host'             => 'localhost',
                'port'             => 11211,
                'weight'           => 1
            )
        )
    )
);

 

[DeltaHF]

Thanks, MattW. I'm going to try the 'lifetime' setting - any drawbacks to setting that to zero? I presume older entries are cleared by memcached as memory is needed?

Heres' the memcached version info and settings:



From /etc/init.d/memcached:

#!/bin/sh

# chkconfig: - 80 12

# description:  The memcached daemon is a network memory cache service.

# processname: memcached

BINNAME=memcached

BIN=/usr/local/bin/memcached

USER=nobody

LOGGING='n'

LOGFILE="/var/log/memcached.log"

LOGFILEB="/var/log/memcached2.log"

CON=1024

THREADS=4

MINSP=72

CHUNKF=1.25

PORT1=11211

PORT2=11212

MEMSIZE=16

SERVERCOUNT=1

SERVERIP='127.0.0.1'

OPTIONS='-o slab_reassign,slab_automove'



if [ -f /proc/user_beancounters ]; then

ulimit-s256

fi



DEBUG='n'

CPUSET='n'

#############################

 

[Mike Edge]

try changing the host from localhost to 127.0.0.1

 

[DeltaHF]

try changing the host from localhost to 127.0.0.1

Interesting. Could you expand on your reasoning behind that and why it would make a difference?

 

[Mike Edge]

Interesting. Could you expand on your reasoning behind that and why it would make a difference?

Just have had it happen with customers before. Same with MySQL kicking back invalid user/pass and changing to 127.0.0.1 have fixed both... Just one of life's mysteries i guess

 

[Jeremy P]

With MySQL, using localhost will connect via a socket, while 127.0.0.1 will connect using TCP/IP. Sockets must be setup properly to work, and when they aren't then using localhost won't work.


This may apply to memcached too, but I'm not sure.

 

[DeltaHF]

Hmmm, good to know; thanks, guys. I will make the change in my tests and report back.

@eva2000 This is a Centminmod box; is there any reason sockets might be unreliable?

 

[MattW]

Hmmm, good to know; thanks, guys. I will make the change in my tests and report back.

@eva2000 This is a Centminmod box; is there any reason sockets might be unreliable?

If you are set up using Centminmod, it doesn't use the socket, it's TCP based.

/usr/local/bin/memcached -d -m 64 -l 127.0.0.1 -p 11211 -c 1024 -t 4 -n 72 -f 1.25 -u nobody -o slab_reassign slab_automove