Ah, this is a fall-out of the new cache-slam protection.

It sort of assumes what you're doing is going to slam the cache (you are, in some sense) and fails.

how to bypass it?

Is it impossible?

No, just give > 1 seconds between apc_add()

But I realize that it's impossible to do this on a multi-process box.

apc_add() is a bad way to go about doing this actually. Let me think about a better API call to do what you want to achieve (i.e "mark caller $x as the owner of something with a time out") instead of break my last fix.

Gimme a bit more time to brainstorm.

Thanks in advance, I'm really looking forward solutions!

Are you sure that the problem is due to the cache-slam protection? In version 3.0.19 a situation similar

Can you try the latest SVN trunk of APC and see if this issue is resolved?

Issue remains :(

Sorry for my bad english. Issue is not resolved.

APC uses the timestamp at the start of the request for all subsequent cache operations in the script.  (The point of this is to cut down on "expensive" time() system calls.)  The drawback is unexpected behavior such as what you're seeing.

Example: The key 'foo' expires at 12:00:05.  You start your script at 12:00:01.  APC will use the timestamp 12:00:01 for the entire duration of the script, so no matter how long you sleep(), the key always expires "4 seconds from now".

The beta version of APC has a new configuration variable "apc.use_request_time" (default On), that you can use to disable this feature.

thanks askalski.  

info@: can you try upgrading and confirm if using this setting fixes your scenario?

Although I agree with Gopal, this probably isn't the best way to get exclusive access to resources.  Perhaps a wrapper around the new compare and swap would be better instead?  (ie: int apc_cas(string key, long old, long new))  Locking isn't easy so a more fail-proof use might be in order, what's the use case here btw?

I did think a lot about apc_cas, except for one critical part about a timeout expiring it out.

I'm actually thinking of a completely clean extension to handle mutexes and timeouts properly in php code?

With the new configuration variable "apc.use_request_time" = 0, this problem is solved!

Perhaps the best way to get exclusive access to resources would be to use a special command, such as apc_lock ( 'key_name') and apc_unlock ( 'key_name'), as is done in eAccelerator?

Marking this bug as closed, as the problem appears to be fixed with the user_request_time configuration option.  We'll have to think about the locking mechanisms and what can be done there, it seems this does come up regularly...