Hi Benjamin, On 04/22/2009 10:00 AM Benjamin Eberlei wrote:
> its the locking. A Cachegrind analysis shows usleep() taking up 99,99% of > the execution time. I have that one at home though, so i can only send it > to you later this day. How is file locking implemented? are there .lock > files of all the files in the filesystem? Is it a good idea to release > locks through a cronjob on lock aquire time > 60 mins or something? I can imagine that this problem occurs if you kill your web server while a certain WebDAV request is still running. Ususally the lock should be released no matter what happens during the request (exceptions or similar). There is a global lock file for the whole back end directory, which is used when you acquire or release a Webdav lock or perform certain operations on locked entities. The lock only lasts for a certain part of the request. Locking is neccessary here, since the lock plugin performs multiple requests on the backend, which must occur like an atomic operation. You're right, it should be in the hand of an admin to free such dangling locks, if they occur. You can simply delete them and the server should be running properly again. If you experience this issue reproducably again, please trace it and send me the trace so I can see what's going wrong. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer t...@ez.no | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
