One thought I'd had was to possibly try forcing Cm_RedisSession to not use phpredis (since some similar-ish Cm_Cache_Backend_Redis issues are apparently solved by forcing it to not use phpredis), but there's not an option I can find for it.

from cm_redissession.

@jonathanvaughn The option is called force_standalone.

from cm_redissession.

I didn't see it anywhere in Cm_RedisSession though - if we set that will it be passed through to CRedis?

from cm_redissession.

Oops, my bad, that doesn't seem to be an option for sessions. Just for the cache backend.

from cm_redissession.

Yeah, though it's exactly the first thing I looked for when first trying to debug this :D

from cm_redissession.

I believe I have previously seen @colinmollenhour mention this is a common side effect of AJAX in the media manager. (Which means it is annoying and pollutes the logs but isn’t outright a sign of problems.)

from cm_redissession.

We're getting "an error processing your request" Magento error page with stack trace though, so... it breaks stuff. -_-

Honestly not sure whether the client is seeing this entirely randomly or randomly on a specific page though, now that you mention it. I'll find out ...

from cm_redissession.

On second thought, that stacktrace indicates an issue with the cache backend. Is there a particular reason you suspect sessions to be the problem?

from cm_redissession.

Oops, I think I posted an old / wrong stack. Let me find and update the OP.

edit: done.

from cm_redissession.

After reading some of @colinmollenhour's answers at the phpredis repository, you may want to try to add $this->_redis->forceStandalone(); just after this line and see if that solves it.

from cm_redissession.

Thanks, we may try that.

The obvious just occurred to me: I could just disable phpredis module and graceful Apache, that would also force standalone, surely? This particular site is only using Redis via Credis and it's Cm_* friends, so assuming Cm_RedisSession properly falls back to standalone on it's own this should be testable without code changes.

from cm_redissession.

Yes, disabling the extension and reloading Apache should have the desired effect safely. phpredis does offer significantly better performance though.

As to the read errors I really don't know.. I see these myself sometimes but they are very far and few between (like once or twice a week with a very busy server). So, I don't really know what to make of it..

If you're really determined to get to the bottom of it a couple things you could try:

• Monitor traffic with redis-cli monitor to see what the last command logged in Redis is.
• Monitor traffic with tcpdump to see if there is anything weird going on with requests/responses.

I can't reproduce the issue anywhere near enough to do the above... Sorry I don't have any better ideas..

It seems like in general Redis is just not 100% reliable when it comes to requests/responses.. You just don't ever see this issue with MySQL, MongoDb, etc.. At least not without some explanation and an error in the log files to accompany it..

from cm_redissession.

I can confirm this issue. We see this also.

Continuous error: Read error on connection and logged out backend (after upgrade)

Since upgrade (22-1-2-15) we see many logging

** Next exception 'CredisException' with message 'read error on connection'

** and users complaining about being logged out in backend

Logging below

Next exception 'CredisException' with message 'read error on connection' in /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/lib/Credis/Client.php:919
Stack trace:
#0 /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/lib/Credis/Client.php(586): Credis_Client->__call('select', Array)
#1 /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/code/Model/Session.php(415): Credis_Client->select(2)
#2 [internal function]: Cm_RedisSession_Model_Session->write('ec31cf667c0b8f1...', '')
#3 /home/shirts350/domains/webstore.com/public_html/app/code/core/Mage/Core/Model/Resource/Session.php(97): session_write_close()
#4 [internal function]: Mage_Core_Model_Resource_Session->__destruct()
#5 {main}
2015-01-14T11:05:51+00:00 ERR (3):
exception 'RedisException' with message 'read error on connection' in /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/lib/Credis/Client.php:901
Stack trace:
#0 [internal function]: Redis->select(2)
#1 /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/lib/Credis/Client.php(901): call_user_func_array(Array, Array)
#2 /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/lib/Credis/Client.php(586): Credis_Client->__call('select', Array)
#3 /home/shirts350/domains/webstore.com/public_html/.modman/Cm_RedisSession/code/Model/Session.php(415): Credis_Client->select(2)
#4 [internal function]: Cm_RedisSession_Model_Session->write('3c0ca6f2d3d4c56...', '')
#5 /home/shirts350/domains/webstore.com/public_html/app/code/core/Mage/Core/Model/Resource/Session.php(97): session_write_close()
#6 [internal function]: Mage_Core_Model_Resource_Session->__destruct()
#7 {main}

from cm_redissession.

@colinmollenhour is there maybe a way to debug all calls and replies from REDIS? Maybe this way I can help to debug this issue /// see what is going on

from cm_redissession.

Yes, use:

redis-cli monitor

Also set the log_level to 7 in your config and you will get a lot of logging in redis_session.log

from cm_redissession.

Hi, our update

** we upgraded REDIS and PHPREDIS ....

** turned on logging, but don't see any errors

** the problem however persists, users are kicked out of backend frequently .... and as I understand also sometimes in frontend cart-> checkout

** Turning off redis session seems to fix the issue

from cm_redissession.

Perhaps check that the session data is not growing to be unusually large due to some bug or unruly extension. Enable compression if not already to reduce data transfer. Otherwise, I don't know what the issue would be attributed to and I'd consider trying another backend that has more reliable connections than Redis such as MySQL (it can be configured to use a separate database/connection).

from cm_redissession.

I hope this is solved for us now. Still waiting.... to see it again

We had persistent connection turned on @ same server, different database (now off)
and realized that session.gc_maxlifetime was set to 30 mins (and apparently Magento takes this is a max too).

http://stackoverflow.com/questions/4022952/set-session-time-out-limit-for-magento-frontend

Hope our issue is solved now

from cm_redissession.