Running a test on a new server and upgraded everything to PECL Memcache 3.0.8 -- BUT my test Drupal site is still reporting that Memcache is still running 2.2.7 for some reason.

Want to rule out it is the Drupal module. I have uninstalled and re-installed everything twice and the module still reports Memcache 2.2.7 on the status page.

Comments

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

The Drupal memcache module simply asks PHP which version of the PECL extension is installed:

$version = phpversion('memcache');

You should see the same thing at admin/reports/status/php. Be sure you're restarting Apache after upgrading the extension.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented
Status: Active » Postponed (maintainer needs more info)

I restarted Apache, the server, everything. The installed software still says PECL 3.0.8.

I am going to make sure everything is in order before... just wanted to make sure that you hadn't heard anything so far.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

Okay. This is weird. I tested with a local Drupal install (on same box as memcache) and everything seemed to work well. But when I tested connecting to the memcache server from remote web server (on same internal network) - it reports 2.2.7 -- even if 2.2.7 was never installed.

So this is a little bit of a mystery... Any ideas on how a remote web server connecting to the memcache server could report the wrong version info?

I tested on two new vps boxes and installed everything from scratch -- with a basic drupal install.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented
Status: Postponed (maintainer needs more info) » Active
JeffSheltren’s picture

JeffSheltren CreditAttribution: JeffSheltren commented

What OS is this on? Could you drop a script with '<?php phpinfo();' in your webroot and share that output as seen in your web browser?

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

Any ideas on how a remote web server connecting to the memcache server could report the wrong version info?

The version you're referring to is the client version, not the server version. Thus, the remote web server you're connecting from has the wrong version of the PECL extension installed. If you're sure you've installed the right version, then you've got multiple versions installed and PHP is finding the older one.

When I'm testing different versions of the PECL extension, I usually do something like:

$ sudo pecl uninstall memcache
$ sudo pecl install memcache
# now restart Apache
$ sudo pecl uninstall memcache
$ sudo pecl install memcache-beta
# restart Apache

Or, to install a specific version:

$ sudo pecl uninstall memcache
$ sudo pecl install channel://pecl.php.net/memcache-3.0.6
# restart Apache
joshuautley’s picture

joshuautley CreditAttribution: joshuautley commented

Is there a way to update memcache so that I don't have to reconfigure it?

I've looked around and it seems as stated above my only option is to uninstall and then install the specific version. I was going to try out 3.0.8.

Any advice / guidance would be appreciated.

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

The module won't stop working just because you're using an older unsupported version of memcache -- it just warns you that you're using a version with known bugs that impact the Drupal memcache module.

You should test all upgrades on a development or staging environment. If you're running 2.0.7 and planning to upgrade to 3.0.8, you will have to schedule minimal downtime to upgrade the PECL extension -- again, test this somewhere other than production.

joshuautley’s picture

joshuautley CreditAttribution: joshuautley commented

The sit eI'm using it for is in DEV now so no need to schedule down time. My instance stopped running once on a live site and the only thing that happened is it got slower until I restarted it. This is nice because if it took down my entire site that'd be a bigger concern. My client only has about 15K unique visitors a month and compared to other sites this is not a huge amount of traffic.

Regarding my question... Is there a way to "upgrade" vs uninstall then install ...is there?

Thank you for your time Jeremy.

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

iirc just running 'sudo pecl install memcache-beta' will work to "upgrade", without first specifically running 'uninstall' (which iirc is only required to downgrade). But the effect is the same, you replace the old version with the new, and you still have to restart Apache.

joshuautley’s picture

joshuautley CreditAttribution: joshuautley commented

Alright, sounds good. Thank you.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

Correct.

If you install memcache-beta, PECL will uninstall any installed library but I tend to do the uninstall manually first since I can confirm from the verbose output that it is indeed gone.

@JeffSheltren and @Jeremy,

I have finally ruled out that the servers are not running properly -- they are working quite fine. BUT, I have tested connecting to remote servers from a shared environment (not just from the webserver I built for testing Apache last night) and this is where my problem appears to stem from. If Apache is installed locally, and I set up the Drupal install to connect remotely, it still picks up on the local memcache installation.

So, I am wondering if I am configuring this wrong. Here is my latest config file that I am using for testing:

# Memcache
$conf['cache_backends'][] = 'sites/all/modules/memcache/memcache.inc';
$conf['lock_inc'] = 'sites/all/modules/memcache/memcache-lock.inc';
$conf['memcache_stampede_protection'] = TRUE;
$conf['cache_default_class'] = 'MemCacheDrupal';
$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';
$conf['page_cache_without_database'] = TRUE;
$conf['page_cache_invoke_hooks'] = FALSE;
$conf['memcache_key_prefix'] = 'testprefix';
$conf['memcache_servers'] = array( 'x.x.x.x:11211' => 'default' );
$conf['memcache_bins'] = array( 'cache' => 'default' );

There must be something here that I have set wrong or something I have forgotten. I am just trying to determine if there is a clash between a local apache memcache install and a remote one. The module should take this into account somehow.

Another question that popped to mind is, in order to connect to the remote memcache instance, do I still need a local installation of memcache to facilitate the remote connection? Perhaps one does... but I didn't install memcache on the web server yesterday and it connected fine without the local memcache daemon.

I may also be confusing myself.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

Ah, another thing. I was notified that in my shared environments they are using zlib to install memcache and not pecl. Not a huge thing but makes it difficult for me to do anything about the shared stuff.

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

Where the memcached server is, is irrelevant. Whether it's on the local server or a remote server, your configuration has Drupal talking to it via a network connection.

Please note that there's a memcache PECL extension which runs on the web server, and a memcache daemon which runs anywhere. On your Drupal website, go to admin/reports/memcache -- what you see reported next to PECL extension is the version of the PECL extension installed on your web server. The version reported next to Uptime is the version of the binary Memcache daemon.

Whether you set (localhost):

$conf['memcache_servers'] = array( '127.0.0.1:11211' => 'default' );

Or (remote host):

$conf['memcache_servers'] = array( '10.1.1.1:11211' => 'default' );

Does not affect the PECL extension installed on the web server. Installing the PECL extension on a remote server (ie, not on your web server) doesn't affect anything.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

Then why does the module complain about the local web server rather than show the settings for the remote server?

Shouldn't the module ignore the local installation of memcache (if it is installed) in favour of the remote one?

Does the local web server require memcache/memcached to be installed in order to connect remotely?

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

You seem to be confusing the memcache PHP extension and the memcache daemon. They are very different things. The PHP memcache extension is installed on the web server and allows PHP to communicate with the memcache server, installed anywhere. Please re-read #14; I'm unable to answer your question as it doesn't really make sense, sorry.

joshuautley’s picture

joshuautley CreditAttribution: joshuautley commented

#15 - I don't know if this will help you but after I'm done testing on my local I just comment out the local settings in my settings.php file then upload that file tot he server.

Now, I haven't updated my version of memcache on my server yet so I don't know if that helps. I know its a dirty work around but it may help for the time being.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

Let me clarify what I am talking about. I have been testing the module in various config environments.

So far, I have tested it in these configurations:

  1. Local Drupal installation with memcache 3.0.8 installed. Works as expected.
  2. Remote webserver (same network) connecting to remote memcache server with remote server having 3.0.8 installed. Works as expected.
  3. Shared environment (same network) and connecting to remote memcache server (same one I used in the second test) but the module is reporting 2.2.7 from the local Apache install in the shared environment rather than the remote installation.

I understand the difference between the daemon and the PECL library but what I am confused about is why the module is reporting the PHP version of the web server rather than version of the PECL on the remote box. Sure, the shared environment would better serve if the latest and greatest is installed but it isn't and shared environments tend not to install beta level software (at least in my experience).

I am merely trying to understand why it reports the local rather than the remote PECL library and how we can mitigate it to make sure people understand what the module is doing.

EDIT: I just re-read #14 and I think what you are saying is the daemon is more important and the PECL memcache library used is always local and it never uses the remote library?

EDIT 2: By the way, I could be missing a huge piece of how memcached and memcache work together. It is not documented particularly well in that respect. So, any education you think we need to know would be most helpful and would stop me from typing...

joshuautley’s picture

joshuautley CreditAttribution: joshuautley commented

#18 I was reading a discussion earlier this morning where a person was having a similar problem. I will look for it again and post the link here. Basically what was happening was that the two versions were installed in different directories. This could be the issue on the shared server.

My advice... move away from the shared server environment if you can. It will save you time in the long run.

And.. here ya go. This may be your answer here...

http://forums.cpanel.net/f5/update-memcached-how-252361.html#post1051801

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented

I understand the difference between the daemon and the PECL library but what I am confused about is why the module is reporting the PHP version of the web server rather than version of the PECL on the remote box.

The PECL extension is used by PHP on the web server (the client) to talk to the remote memcache server (the sever). It is the minimum version of the PECL extension that matters, because the Drupal memcache module is written in PHP and talking to the remote memcache server through the PECL extension on the web server.

If you're installing the memcache daemon on a remote server, installing the PECL PHP memcache extension on that remote server does nothing.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

@joshuautley,

I have several hundred clients on shared environments, so, that isn't going to happen any time soon -- and nor should this module force people to move. My original ask on a previous issue about the update in Beta 5 is that Drupal modules shouldn't "see red" just because the developers don't agree with shared environments.

The message the module should produce a yellow warning that specifically states the issue and what they may potentially be able to do about it. People on shared environments like GoDaddy, Rackspace, Bluehost, 1&1, etc... shouldn't be punished for that. 99% of clients I have are on shared environments and they are all over the place. It would be awesome if everyone could afford their own servers but they simply don't want to spend that kind of capital.

Not to mention, red warning messages cause phone calls, which cause explanations... which cause headaches.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

@Jeremy,

Then I go back to my original comments in the issue you closed. I think you need to reconsider the message that the module produces. It should be a warning message rather than a red message as most Drupal users would probably freak out at that.

I think it is unreasonable to expect users of the module to configure their websites in a way that may not be possible.

Jeremy’s picture

Jeremy CreditAttribution: Jeremy commented
Status: Active » Closed (works as designed)

As stated before, this works as designed. The red message is there to alert you that you are running an unsupported configuration with known bugs. At your own risk, you can disable the memcache module and everything will keep working as it always has (the memcache functionality is controlled via settings.php) and the red will go away.

joshuautley’s picture

joshuautley CreditAttribution: joshuautley commented

@Shane - I run Rackspace Cloud Site in conjunction with a Rackspace server. It cost me $10/month for the Rackspace Server which is only used for memcache.

With other companies you can get a server and VPN in and do as you will.

My thoughts were to help you and by no means was I trying to insist on anything. No one is "frocing you" to do anything. I for one am very appreciative for what all module maintainers such as Jeremy do. I, as them, are trying to help you. So, please keep things in perspective here.

Shane Birley’s picture

Shane Birley CreditAttribution: Shane Birley commented

@joshuautley,

I am very appreciative of the people in the community but I am also making sure that the community doesn't overlook the non-nerds among us. I am also not fighting with you both on this, I am just making sure someone is playing the advocate for users who utilize modules but don't necessarily understand how they work. I refer, of course, to the "just turn it on" group.

Picture it this way:

  • Someone running the Memcache module that just "follows the documentation" and gets it working. They are happy.
  • They do a typical module update. Everything goes well and they head back into the admin pages.
  • But wait, this is weird. I now have a red warning message, something must be broken.
  • Upgrade? But I can't. GoDaddy runs the server and I can't update PECL Memcache to version 3.0.6 -- what is PECL anyway?
  • Oh, those Drupal nerds can help. I will go post an issue in the Memcache issue queue. (Potentially rinse and repeat a bazillion times and another issue queue is flooded and becomes overwhelming to deal with.)

I never assume that Drupal/WordPress/Joomla users will ever fully understand the issues running in any environment and I have suggested that we make it clear why the message is there. Telling them it is "unsupported" and they should "update" is fine but if they can't (such as Cloud Sites users) it just wastes time for everyone.

And I am not losing perspective because I am not really concerned for me. I have been playing and contributing to Drupal since the early days. I am merely wanting to make sure the community doesn't kick some of our user base in the butt without attempting to consider things from as many perspectives as possible and provide adequate documentation as to why things happen after updates, newer technologies, etc...

...that's just the way I roll.

EDIT: Also just another note, I banged the module through two sessions of different configs yesterday to help out because I wanted to contribute not criticize. I am reporting what I found and I think shared hosting users will be problematic.