Using membase as PHP session handler

Markus,

I am working on getting a workaround for you and will get back to you soon.

Bhawana

Markus,

You can set expiration to your session keys and they will be cleaned up.

tap.py should work just fine. Can you please let me know how you are using the program and what errror do you see?

Bhawana

Hi Bhawana,

For my Tap.py problem I opened the following bug yesterday: http://bugs.membase.org/browse/MB-2725

In the php.ini the session cleanup settings are already set:

• session.gc_probability = 1


• session.gc_divisor = 1000


• session.gc_maxlifetime = 1440


• session.cache_expire = 180

But it seems to be that php is only able to cleanup sessions which are held in the file system.
 

To workaround my problem I need a possibility to get all the keys from a vBucket and their last usage time.
This would give me the possibility to cleanup the old keys from membase via the memcached protocol.

Markus

 I have found the source of the problem within PHP and it's memcached client.
We are going to report this bug and the fix to the PHP PECL team and to the Ubuntu package maintainer.

Description and Solution:

I did a little trace with Tshark and found out that the php memcached client always adds sessions with an expiration time of 0 (-> no expiration).
Even if the session.gc_maxlifetime (php.ini) was set to another value than 0 (1440 for example).
The programmers of the client used a wrong call to get the values from the ini file and so always uses the default value 0.

In php_memcached.c :

    // Wrong version
    // sess_lifetime = zend_ini_long(ZEND_STRL("session.gc_maxlifetime"), 0);
    // BUGFIX:
    sess_lifetime = zend_ini_long("session.gc_maxlifetime", sizeof("session.gc_maxlifetime"), 0);

The reason for the problem is explained here: http://stackoverflow.com/questions/1288525/reading-php-ini-using-zend-for-php-extension-not-php-language

But it would good if there is way getting all session keys and last usage time from membase!

In response to that bug, can you confirm whether you have a default bucket configured?

The current tap.py does not work with buckets other than the default, we will be fixing this soon.

Perry

Hi Perry,

unfortunately I have deleted the default bucket. (I created a new bucket with another name.)
But even when I recreate a new bucket called default it seems to be not working.

Is there a description for the tap.py?
 

Markus

Thanks Markus.  I just tested this myself and recreating the default bucket allowed the tap.py script to work.  It takes a few seconds for the bucket to come up after being created, perhaps you didn't wait long enough before trying out the tap script?

We're working on enhancing it both in terms of funcionality and usability.  For now, the best description is avialable here: http://wiki.membase.org/display/membase/TAP+Protocol

Hope that helps, please let me know what else I can do.

Perry

 Hi Perry,

you were right I just made a mistake: I recreated the bucket on the wrong test server and tried the tap connection from another server..

But even I could make a connection to the TAP stream now I don't know how to use the tap.py Tool since there is only a description for the protocoll in the wiki not the tools..
I wondered if it is possible to get all older keys from membase via the TAP protocoll.

Background:
I need to remove "lost data" from the cache without a flush_all..

Regards

Markus

@font-face {
font-family: "Cambria";
}p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: "Times New Roman"; }div.Section1 { page: Section1; }

Markus,

To use TAP, we provide a script: "/opt/membase/bin/ep_engine/management/tap.py <IP>:11210" which will begin streaming out all of the data within the Membase server located at <IP>.  It will send all the data in the server and then continue streaming all incoming updates. You may write a script to identify the "lost data" that you are interested in from this stream. We recommend running this locally on a Membase node to make it as fast as possible and also to avoid adding any unnecessary traffic to the network.  You can read more about TAP here: http://wiki.membase.org/display/membase/TAP+Protocol

Please let me know if you have more questions about using the tap tool.

Bhawana

 I was going to start a new thread, but it seemed relevant for me and for anyone how stumbles upon this thread.

Does PHP/libmemcached delete sessions that are expired, currently or does that need to be completed in a cronjob via tap.py.   I am finding that it does not, no matter how i set the gc_propability,gz_divisor and gc_maxlifetime ini settings.  Currently i have them as gc_maxlifetime = 10 (seconds), and the others ensuring a 100% probability the garbage collector will run.

Thanks!

The php5-memcached module would if there were not this coding error:

It tries to read the gc_maxlifetime settings from the php.ini file.
But this line of code has a bug.

Original Code:

sess_lifetime = zend_ini_long(ZEND_STRL("session.gc_maxlifetime"), 0);

Bugfix:

sess_lifetime = zend_ini_long("session.gc_maxlifetime", sizeof("session.gc_maxlifetime"), 0);

The problem is that the ZEND_STRL makro returns the lengths of the string without the terminating zero.
In order to fix that bug you have to download the exact source code version of your module make the changes, compile it and replace the original module with the patched one.
 

We used Ubuntu server edition 10.04 LTS x64 and I already created a patched memcached.so (version 1.0.0).
Just let me know if you need my patched binary version.
 

Markus

Thanks I have patched and recompiled and that seems to work well.  

Good to know that your problem is resolved. Please let us know if you have any more questions.

Thanks

Bhawana

I am having a similar problem, but with a slightly different configuration...

Versions:
CentOS 5;5
Apache 2.2.15 (prefork)
PECL Memcache 3.0.4 (also tried 3.0.3)
PHP 5.2.13
Moxi 1.6.5
Membase 1.6.5

GC:
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440

I am seeing other items put things age out as appropriate, but sessions are seemingly hanging around forever.

Want's sure if I should start a new thread or not...so I'll start here.

Thanks!

 Hi, have you updated your PHP code with the bug fix as described earlier in this thread?

I think that bug fix is for the memcached extension and not the memcache extension... 

 It's quite possible the same bug exists in the memcache extension right?

Not in the sense that you can apply the patch above...  I can root around the code a bit I suppose. There is a cache delete bug fixed in 3.0.5, but I am not sure it's related.

To ADESTIS (Markus)

I am running the same configuration (Ubuntu 10.04LTS) and would appreciate the patched binary of memcached.so you mentioned.

Additional:
I attempted to set min_data_age using mbflushctl in hopes that it would solve this. Since I wouldn't expect sessions to last more than a day, could I set:
mbflushctl localhost:11211 set min_data_age 86400

Is the min_data_age in units of seconds, hours, days?