…k file has been released (mpdude)

This PR was squashed before being merged into the 2.3 branch (closes #16312).

Discussion
----------

[HttpKernel] clearstatcache() so the Cache sees when a .lck file has been released

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #15813
| License       | MIT
| Doc PR        | n/a

I've been trying to debug #15813 and modified the Store in a way to keep unique request IDs in the .lck file. That way, I was hoping to find out which request is blocking and/or if the request is actually still running.

It turned out that `is_file()` would claim that a lock file still exists, but a subsequent attempt to read the information from that file returned "file not found" errors.

So, my assumption is that the `is_file()` result is based on the fstat cache and wrong once a process has seen the lock file.

@jakzal said in #15813 (comment) that `unlink()`ing the lock file should clear the statcache, but I doubt this is true across PHP processes.

Commits
-------

982710f [HttpKernel] clearstatcache() so the Cache sees when a .lck file has been released

…k file has been released (mpdude)

This PR was squashed before being merged into the 2.3 branch (closes #16312).

Discussion
----------

[HttpKernel] clearstatcache() so the Cache sees when a .lck file has been released

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #15813
| License       | MIT
| Doc PR        | n/a

I've been trying to debug #15813 and modified the Store in a way to keep unique request IDs in the .lck file. That way, I was hoping to find out which request is blocking and/or if the request is actually still running.

It turned out that `is_file()` would claim that a lock file still exists, but a subsequent attempt to read the information from that file returned "file not found" errors.

So, my assumption is that the `is_file()` result is based on the fstat cache and wrong once a process has seen the lock file.

@jakzal said in symfony/symfony#15813 (comment) that `unlink()`ing the lock file should clear the statcache, but I doubt this is true across PHP processes.

Commits
-------

982710f [HttpKernel] clearstatcache() so the Cache sees when a .lck file has been released

…ased after two second wait (jakzal)

This PR was merged into the 2.3 branch.

Discussion
----------

[HttpKernel] Lookup the response even if the lock was released after two second wait

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

While looking into #15813 I noticed that we [wait for the lock to be released for five seconds, but then only do a lookup if the lock was released in two seconds](https://github.com/symfony/symfony/blob/fa604d3c6f16f264863a42c200391ab996640296/src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php#L540-L562), no more.

I think it's worth to make both values the same (so either two or five seconds). I see no reason why we should wait for the lock for five seconds, but then only do a lookup if we waited for two. One way the wait either takes too long, the other way we loose the opportunity to actually return a response.

Commits
-------

9963170 [HttpKernel] Lookup the response even if the lock was released after 2 seconds

This PR was merged into the 2.7 branch.

Discussion
----------

[HttpKernel] Use flock() for HttpCache's lock files

| Q             | A
| ------------- | ---
| Branch?       | 2.7
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | no
| Fixed tickets | #16777, #15813 and #16312 are also related
| License       | MIT
| Doc PR        |

When a PHP process crashes or terminates (maybe the OOM killer kicks in or other bad things ™️ happen) while the `HttpCache` holds a `.lck` file, that lock file may not get `unlink()`ed.

The result is that other requests trying to access this cache entry will see a few seconds delay while waiting for the lock; they will eventually continue but send 503 status codes along with the response. The sudden buildup of PHP processes caused by the additional delay may cause further problems (sudden load increase).

As `LockHandler` is using `flock()`-based locking, locks should be released by the OS when the PHP process terminates.

I wrote this as bugfix against 2.7 because every once in a while I encounter situations (not always reproducible) where `.lock` files are left over and keep the cache locked.

Commits
-------

2668edd [HttpKernel] Use flock() for HttpCache's lock files