fastcgi?

Ah my bad, I'm using Litespeed with the Litespeed sApi

I'm not sure I understand the problem here, are you saying that APC is fetching deleted entries from the cache and returning them?

Hey shire :) Long time since I submitted this bug. But what I recall was that 'random' cache entries that were apc_delete:ed we're still in the cache. I used the cache to store a sql call that checks if a user had new messages or not... When a user then clicks on his inbox it deletes the cache + sets it to 0 in the db. Then it's of cource supposed to re-cache the 0 into apc, but many users experienced this bit very flaky. And I saw it too in the apc.php user_cache entries. I even found a cache entry and when hitting the reload button the cache was randomly switched from 0 to 5 (or the amount of new messages) in the apc.php ... I should have taken screenshots as it's hard to believe :).

I will be releasing a new version of my site where I can retry this part of my code, since it's random it's hard to reproduce and does not give you guys much to go after.. So I'll test this on my new setup using nginx -> php-fpm + latest apc and php version just to be sure it wasn't a random incident. I can report back when it's tested.

Hey thanks for the quick response.  Yeah sorry for the delay on getting back to this we have some delinquent bugs ;-)

It sounds to me like this is likely to be some application race-condition related bug, rather than something internal to APC.  

So you're storing these values and then using the apc_delete() call to delete them from the cache until they get re-inserted by apc_store() again on another request? (which should then be 0 ?).  Is it possible another process is running at the same time that's modifying these values? ie: updating it with a value while after the value is deleted from apc, but before it's updated in the database?

It would be great if you could do the retest as you suggest and let us know what you find, or if you're lucky enough to come across a reproduction.  Thanks!

I'm sure it can be a race condition problem. Each update is made from another process. 

1. recieving user has an ajax call asking the server if any new messages have arrived.
2. recieving user deletes cache when hitting the inbox button.
3. senders delete the recievers cache when sending him a message to make his ajax call show correct amount of new messages.

That's basically it, the sucky part is that when switching to memcached without modifying anything other than the cache class, this procedure worked 100% and still does today.. That's why I figured it must be APC related. And since I'm on 1 server, this gives me a huge performance loss because of not being able to use APC cache :)

Have you taken a look at the apc_add() functionality?  http://us.php.net/manual/en/function.apc-add.php

This allows you to add an entry, but only if it's not already in the cache.  Perhaps this, or some other combination of functionality, would help you solve your race condition?  We've also added a set of atomic increment and decrement functions, these might be useful as well.  (I don't think they are documented yet so you can dig into php_apc.c for prototypes or ping me and I'll get them for you).

This isn't sounding like an APC bug so I'll proabbly mark this as bogus unless we come across something else, but let's try to see if we can resolve your problem here as we should be able to make this work with APC.

yea the apc_add won't help as I do a if(!apc_get) then mysq_get & apc_store.. So it's basically an apc_add :) 

Anyways I tested it yday on my old code just to see if it had been fixed. And it seemed like it did. The reason could be that I'm not on litespeed sapi anymore, or a newer version of php/apc, or that i turned of the require_once apc feature. 
But whatever it was it seems to be gone and I can finally have apc only cache! Nice to see you active shire, love reading your blog :)

You may set the ticket to closed.