Strange, unrepeatable error with dynamic datasource

[kanduvisla]

I had a case today where a dynamic datasource didn't show any content, whereas it worked fine yesterday.

After exploring in the debugger to look what the output of the datasource was, It showed the error:

<error>
    fopen([...]/manifest/tmp/12c5fb13948b6080285c444e6c454456.lock): failed to open stream: File exists
</error>

The file existed, but was empty. There was also another hashed .lock-file. That file had the content MUTEX FILE - DO NOT DELETE, or something like that. Regardless, deleting both files fixed the issue and my dynamic datasource started to work again.

Anyone knows what might have caused this problem? Anyone else experienced something like this before?

[ahwayakchih]

Looks like mutex was not unlocked last time. Strange thing is that, depending on cache life time, old lock should be removed next time there is time to refresh cache. Can you check if there are lock files left behind after visiting page with a single dynamic data-source?

[kanduvisla]

I'm having the problem again. It occurs with a dynamic datasource which loads a twitter xml-feed. The cache is set to 5 minutes for this datasource. Could that have something to do with it? Does Mutex have it's own caching time?

[brendo]

What currently happens is that when a Dynamic XML DS goes to fetch a new result, a lock file is created that will live as long as the timeout of the datasource. When the result comes back, the lock is released. The idea behind this is that if multiple requests happen at the same time, they won't all try and fetch the URL and potentially place excessive load on the server.

I have pushed a commit that will allow old data to return in the scenario where multiple requests hit the server in succession while a lock is in place. This old data will be marked as stale so that in your XSLT you could alert a user. The error message returned should be The Mutex class failed to acquire a lock..

Please reopen if you can reproduce your original issue.