Memecache/APC Caching issue, customers checkout details not passed through to backoffice

[leopm]

I have an issue when enabling APC or Memecached on prestahop.

Basically if the cart is idle for any short period of time and the customer checks out, lets say bankwire for example, the order will go through, however, the issue is that their address information does not appear in the backoffice and then ofcourse the confirmation emails etc will not show their address either. 

 

I initially had the issue when using Memecached.. then I thought switching over to APC cache would solve the issue.. however the issue remains on both. If I restart my Memecache the address will the appear as it should in the backoffice.. but not until then.

 

Has anyone ever came across this issue... I've tried everything I can think of and searched extensively online... I don't see this issue popping up anywhere else.

 

Any help at all would be greatly appreciated!

[GuusMichielsen]

I'm experiencing more or less the same problem.

When I use APC cache, the address-information won't refresh until I manually clear the APC-cache. This happens when the customer creates a new address or updates an address.

 

For instance, as long as the APC-cache isn't cleared manually after updating the address, the customer keeps seeing his/her old address.

[the.rampage.rado]

Very strange issue.

What version of APC or apcu are you both using? Also which PS version?

[GuusMichielsen]

Prestashop: 1.6.1.4
PHP: 5.4.45
APC: 3.1.13

(I've also tried PHP 5.5 with APCu, same issue there)

I'm currently doing some extensive testing, I'll get back to you once I've got some more details.

[Dh42]

Are you using APCu with both installations? If so, don't use it. It is caching the database queries. 

[leopm]

Its the same for me, if I restart memcache, after each order the issue is not there, also if when customers details are not populated in backoffie, retarting memcache will make them appear, I've tried all PHP versions from 5.3 to 7.0 with APC, APCU and memecache.. they all carry the same issue.

I'm running 1.6.1.6 latest build. Ive even tested on a new build just to see if it was a bad module or database on my current build. However, the issue is replicated in new build also.

Its a real shame considering the overall performance increase I get from either Memcache or APC.

I ended up purchasing a page cache module so I could get similar perfomance.. however, its a anoying not to be able to use either of the caches mentioned. 

If you manage to crack it please let me know, I'm all out of ideas.

[Dh42]

The problems you are having is what is considered normal behavior. What you should do is set memcache up not to cache the admin directories on your shop. Same with APCu as well. That will solve your problem and let you use them. 

[leopm]

Thanks Dh42, Thing is, Im on a shared server and connect to memcache via a shared socket, so I dont think I can control the settings of memcache.

[Dh42]

Then that is a problem. This might help things a bit, http://www.webhostingtalk.com/showthread.php?t=1346546

[leopm]

Thanks so much, Ill give that a look now!

[the.rampage.rado]

I'm currently on php7 with latest apcu and I fail to see similar issues.

 

As soon as we receive an order everything is shown in BO, all emails are sent. The notification on top takes a while to show if we don't refresh the current BO page but this is normal I think.

 

I had the same behavior with PHP 5.6 and APC... Haven't tested much with memcache

[GuusMichielsen]

In my case, the BO works as expected. It is the FO I'm worried about.
It does indeed seem like the queries are cache, which as I understand it isn't bad behavior (or is it?).

What I'm worried about, is that when personal information changes (i.e. the customers address), this should trigger a purge of the cached value.
The code in for instance classes/address.php does reflect this (as far as I understand it). In the update-function for instance, before updating the information it calls Customer::resetAddressCache(...). Shouldn't this purge the cached query?

It's very likely I'm interpreting things wrong, I'm far from an IT-expert. But I'm willing to learn .

 

Thanks for taking a look at this.

Edited September 6, 2016 by GuusMichielsen (see edit history)

[the.rampage.rado]

In my case, the BO works as expected. It is the FO I'm worried about.

It does indeed seem like the queries are cache, which as I understand it isn't bad behavior (or is it?).

 

What I'm worried about, is that when personal information changes (i.e. the customers address), this should trigger a purge of the cached value.

The code in for instance classes/address.php does reflect this (as far as I understand it). In the update-function for instance, before updating the information it calls Customer::resetAddressCache(...). Shouldn't this purge the cached query?

 

It's very likely I'm interpreting things wrong, I'm far from an IT-expert. But I'm willing to learn .

 

Thanks for taking a look at this.

Everything is OK for me there also. The customer can create new address, changes city, post code, country. Everything is displayed right away when the customer gets to /addresses or in the address itself (when editing).

 

Is your browser cache enabled and configured properly?

[GuusMichielsen]

Ok, I'm making some progress...

I'm starting to think there is something entirely different going on in my case, I think it's a third-party module that's playing fast and loose with the addresses.
Storing temporary addresses, removing them later on, storing permanent changes, etc..

I think this causes problems while having APC activated. Not so much because I'm retrieving old cached results, but because the module is confused by the caching.

I'll get back to you when I understand what is going on , because now I'm confused as heck.