----- Original Message -----
From: "Perrin Harkins" <[EMAIL PROTECTED]>
On Sun, 2006-04-02 at 23:19 -0400, John (Versimedia) wrote:
I have been playing around with Apache::Session and had it working with
MySQL -- then decided to switch to Memcached
Hmmm. Do you know what memcached is? It's not advisable to store data
that has no backup in it.
Yes, I am aware -- Im only using it to track non-important user data such as
keeping track if a user has logged out. All of the users actual data will
be in the dbase and with a session key int he cookie, the system will
automatically recreate a new session ID if memcached has been reset.
Memcached is about 20% faster than using MySQL for session IDs.
If I telnet to the memcached port and type "stats" to see the statistics,
I
see that curr_connections is high and stays that way -- I believe this is
due to mod_perl keeping the connections open for each process.
Lots of connections is not a problem for memcached. It is built to work
that way.
Yes, I understand this -- but that is not the concern I have -- my concern
is that the connections are not being closed when used in Mason/Apache for
some reason -- they are staying persistent.
I removed
the "Apache::DBI" library option to make sure that was not causing
persistant connections, but the curr_connections continued to stay high
after many reloads of a webpage.
DBI and Apache::DBI have no connection to memcached.
Ok, that helps track down the problem.
It seems the failures occur after i kill and restart the memcached
daemon,
but not restart Apache.
Any time you restart the memcached daemon, all of your data goes away.
Yes, I am well aware of that -- however imagine this scenario:
I have a 10 process Apache server running mason and using session as
described... then:
* I load the page over and over very fast -- using up all 10 processes so
they all have opened a connection to memcached. The Session ID stays
constant since it is in the cookie and each hit it is verified in memcached
so does not change.
* I kill the memcached daemon and restart it -- at this point my valid
session ID stored in the cookie (for example "A1" no longer exists.
* The next time I reload apache, the session ID should change to a new one,
for example B1 -- and each time I reload the page after that, it should stay
B1 since Apache::Session has now created and stored the new ID.
However, this is not what is happening -- as I reload the page over and
over, the ID keeps changing on each load. I believe the reason has to do
with the original 10 processes having connections left "open" to
memcached -- since memcached was reset, all the connections are now bad --
as I reload the page, Apache::Session is trying to verify the key and it
fails since the connections to memcached are stale and old, and it generates
a new key each time. The only way to solve it is to HUP apache so that the
connections get restored.
It seems that Apache::Session::Memcached either needs to detect the
connectin is bad and should try to re-establish after a failure, or it
should report the failure to me in some way.
Oh one other question -- anyone know how to detect a failure to connect
to
memcached?... it seems that if memcached is not up, that it just returns
the
error that the object does not exist, rather than a connection failure
error?
That's intentional. Memcached expects your program to be written so
that it still works if the cache goes away.
Yes, but the Apache::Session::Memcached should be detecting the connectin to
the server failed so that it can report back to the system somehow --
otherwise there is no way to know that the key being returned is really
invalid -- if it is not being stored somewhere (such as memcached or a
dbase), it is worthless(?)
-John
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
