creating severe load on system by logging thousands of unlink errors in DB log

I also get simillar warning:

warning: unlink(/tmp/cache_lock) [function.unlink]: No such file or directory in /gg_w/www/guoguo_beta/sites/all/modules/cacherouter/Cache.php on line 124.
warning: unlink(/tmp/cache_views_lock) [function.unlink]: No such file or directory in /gg_w/www/guoguo_beta/sites/all/modules/cacherouter/Cache.php on line 124.

I've seen a similar problem currently. Looking at possible fixes.

I've made a simple edit to the unlock method to say:

function unlock() {
if (file_exists($this->lock)) {
unlink($this->lock);
}
}
}

and it seems to remove this pesky warning from bloating the logs.

subscribing...
My error lists /tmp/cache_content_lock
Technically, it is correct; there is no such file in /tmp.

If you are using a check to see if file exists (as suggested in #2) then won't it increase diskio further decreasing performance?

I am getting same error while using APC and it creates drastic load on the server. Not because of the change you suggested, just by just installing cacherouter since it is creating hundreds of error messages in the log. I am using APC as engine.

Why it is trying to unlink files when I am not using file engine at all?

Same error has been reported with xcache too. #575920: Xcache - unlink errors

function unlock() {
if (file_exists($this->lock)) {
unlink($this->lock);
}
}

Even with the above change, I am getting some errors:

It appears that the origin of the error is a module Ive written ('twilio.module') that uses a jquery plugin invoked via the jq module, which attempts to use D6 core's cache_set, which meanders through APC (which I am obviously using) and on to the unlink error.

Is this related to the other unlink errors in the issue queue?
Is there any way to mitigate it at this time?

Thanks.

I do not have your twilo module still I see the error. :)

yeah I tried to word my post ("origin" !== "culprit" ) so as not to blame my own module, ;)

The file might be unlinked by another concurrent request right between file_exists() and unlink() - unless we use locks on deletion of files. I would try an atomic @unlink() instead.

There is a thread on the D7 issue queue regarding the implementation of a lock system to avoid race conditions like these, using semaphores. (http://drupal.org/node/251792)
There is a patch for D6.14 (http://drupal.org/files/issues/lock-251792-224-D6.patch) that implements the locking framework and fixes a few race conditions (menu_rebuild(), and something to do with translations).
Perhaps this would be helpful in this case?

I am not sure this is a good long-term option, because it remains to be seen whether this will make it into D6 core at all.

EDIT: It is curious to me that, if this is indeed due to a race condition, that it has never been reported before - this is a type of module that should be used on a high-volume site, and one would think that this situation would occur frequently on such a site. The project that I've rolled cacherouter out on is new, and besides se spider traffic, I've had only maybe 1,000 hits in the past 5 days.

I don't think this is a race condition related to file unlink. Please note the issue is against APC cache. The issue is cache router is trying to unlink APC cache entry as if it was a file. And it can't because there is no file by that name.

e.g in #4 above "unlink(/tmp/www_-cache_filter_lock)", "www_-cache_filter_lock is a memory based entry in user data portion of APC not a disk based file under /tmp.

So cacherouter somehow needs to understand it is dealing with APC and should delete the cache entry instead of "unlinking" thinking it is a file. It should not even try to do any diskIO to check if the file exists since it can't exist. That is why #6 is not a solution. It will just supress the error message but 1) it won't delete the cache entry when it is supposed to and 2) unnecessarily increase disk io, negating the very reason APC is used.

I never really used APC, but from reading the code I see, that this is quite not the case. Apart from storing actual data in APC, cache router also implements a locking mechanism to avoid collisions between concurrent requests. This is implemented with the use of dummy empty files in tmp directory (with a good descriptive names employing a "lock" suffix), and obtaining flock() locks on these. Unless APC have some native locking mechanism (I really don't know this bit), this implementation is fine. The unlink only just removes the dummy file when the lock is lifted (which is in fact just a cleanup operation, not strictly required).

Looking at the code I can see your point. However looking at engines/memcache.php it has own implementation of lock() and unlock() which does not use filesystem at all. So perhaps APC need similar handling of lock /unlock?

Ok the orginal version before rc1 , APC engine had its own locking mechanism. This was specifically deleted by this commit http://drupal.org/cvs?commit=259630
"tweaked apc/eacc/xcache to use files for locks for better reliability and true atomic locks."

see the diff
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cacherouter...

So since it no longer has lock/unlock implementation in the file, it executes the default one from from parent class.

Subscribing.

I installed Cache Router last night and was alarmed to wake up to a screen full of error messages.

I've suppressed the error messages for now, but I agree that if no call to the file system is necessary it should be avoided.

@ajayg: I'm not sure I understand. If there are files for locks, why are we all getting these messages? Is there nothing that needs to be deleted, or are there files being created but not deleted?

It seems the files are for lock but some how they don't exists or getting deleted somehow before cacherouter needs to delete at appropriate time. Perhaps they are not getting created as part of lock and unlock is trying to delete.

I haven't see any lock file getting created at all, but I could be just looking at wrong moment after they are deleted.

subscribe

This will fix your problem. We need to unlock the file first, close the handle and then unlink the file. I think this problem only occurs on windows system.

Using a debian box here, still have the problem.

try the fix. does it solve ur pb ?

why? cause cache needs to know where to store files. thats why you have error "no such file in directory" etc

FWIW, facebook uses the pthread mutex lock option.

I've also been seeing some issues with this new locking system in place. I think the default APC file locking system is supposed to be pretty efficient.

I am also seeing these errors. Mostly for cache_filter_lock.

The proposed fix in #18 did not work for me. I am on a CentOS system and it gives me:
PHP Parse error: syntax error, unexpected $end, expecting T_FUNCTION in /var/www/vhosts/domain.com/httpdocs/sites/default/modules/cacherouter/Cache.php on line 131

Also, I have set my path as suggested in #21 to no avail. I am still getting errors for files in /tmp and nothing is created in the defined path.
Setting "lock_dir" (called at line 48 of Cache.php) does change the error to show the defined directory
(ie - 'lock_dir' => 'sites/default/files/filecache',). Using this I had to manually create the filecache directory. However, I still get the errors.

I am seeing the files being created and deleted from time to time though.

Same problem here:

Warning: unlink(/tmp/cache_lock) [function.unlink]: No such file or directory in /var/www/drupal2/sites/all/modules/cacherouter/Cache.php on line 124

Cacherouter 6.x-1.0-rc1
Drupal 6.14
CentOS 5.3

change the path for cache it may work then.

@fred it looks like a parse error, maybe you don't update the code properly ?

We're seing this too. Is the maintainer available for a reply?

Unfortunately maintainer hasn't replied for two months.