Uh oh!
There was an error while loading. Please reload this page.
Fix DAV stat cache to properly cache 404 - #26324
Conversation
mention-bot
commented
Oct 10, 2016
@PVince81, thanks for your PR! By analyzing the history of the files in this pull request, we identified @DeepDiver1975, @icewind1991 and @LukasReschke to be potential reviewers. |
PVince81
commented
Oct 10, 2016
also:
|
PVince81
commented
Oct 10, 2016
Okay, the storage impl is covered by the DAV ext storage tests at least. The bug itself wouldn't trigger any failure since it was a caching issue. |
DeepDiver1975
commented
Oct 11, 2016
|
| $this->statCache->clear($path . '/'); | ||
| $this->statCache->set($path, false); | ||
| throw $e; | ||
| } catch (ClientHttpException $e) { |
There was a problem hiding this comment.
Is this change intentional? I find strange that we're catching "NotFound" exceptions and removing "ClientHttpException" ones except here 😕
There was a problem hiding this comment.
It's a bit messy...
Basically Sabre's propfind itself only ever throws ClientHttpException or ClientException, never NotFound (that one belongs to sabre server, not sabre client btw).
But here we do want to throw a known exception for the consumers of our own $this->propfind, so we throw NotFound and they all catch it.
Maybe it would be cleaner to simply rethrow ClientHttpException as is to avoid confusion ?
There was a problem hiding this comment.
I'd rather keep consistency on the client side: if client expects a "NotFound" exception then we throw that exception.
There was a problem hiding this comment.
The client doesn't expected NotFound exception, only the consumers of $this->propFind do, and they're all within this single class.
There was a problem hiding this comment.
Argh, looks like I can't easily replace with only ClientHttpException, because when a 404 propfind was cached, I'd need to create a virtual ClientHttpException to simulate failure here: https://github.com/owncloud/core/pull/26324/files#diff-eaf59cbf225a9e583d7cda98942ed6abR253
That's the reason why I picked this exception. Not sure if there is a better solution.
There was a problem hiding this comment.
If there is no easy solution, let's go with this. Just write a comment to remind why we've chosen this decision.
There was a problem hiding this comment.
Now the tricky part: create a virtual ClientHttpException considering that it takes a ResponseInterface in its constructor... I considered either creating a class that extends ClientHttpException or one that implements ResponseInterface but it all goes too far, too many methods.
I'll see if simply returning false from propfind and handling this outside would be better. (outside being inside the class as propfind is private)
651f3e3 to
af14eedComparePVince81
commented
Oct 20, 2016
Oh, PHP 7.1 specific failure... fancy! |
PVince81
commented
Oct 20, 2016
hmm, tests pass for me in PHP 7.0.12... will need to setup PHP 7.1 then |
PVince81
commented
Oct 21, 2016
I've setup 7.1.0RC4 with phpenv (yay, it worked!) but the tests do pass. If it fails again, then we can try upgrading Jenkins to 7.1.0RC4. |
PVince81
commented
Oct 21, 2016
This is the failure on Jenkins: |
af14eed to
19f38c2ComparePVince81
commented
Oct 21, 2016
Rebased, let's hope the test magically passes now... |
PVince81
commented
Oct 24, 2016
Even with PHP 7.1.0RC1 the problem doesn't appear on my local env. So it seems that all I can do now is guessing and trial and error. |
PVince81
commented
Oct 24, 2016
The failure itself seems completely unrelated to this change. |
PVince81
commented
Oct 24, 2016
Jenkins PR: #26466 Let's see if it also fails if restarted in that separate test env... |
PVince81
commented
Oct 25, 2016
Ha, the Jenkins PR healed it... |
PVince81
commented
Oct 25, 2016
@jvillafanez I decided to use the Please rereview. |
PVince81
commented
Oct 28, 2016
@jvillafanez please re-review |
| * @return array propfind response | ||
| * | ||
| * @throws NotFound | ||
| * @throws ClientHttpException |
There was a problem hiding this comment.
This doc should be updated with the conditions under it returns "false"
jvillafanez
commented
Nov 7, 2016
I don't see anything strange so 👍 |
19f38c2 to
0ab699fComparePVince81
commented
Nov 7, 2016
Adjusted comment, squashed and rebased. |
PVince81
commented
Nov 7, 2016
Grrrr, that unrelated failure again: Jenkins PR for the rescue: #26564 |
404 errors were not properly cached due to catching the wrong exception. Now catching ClientHttpException and checking the error code. In case of 404, adjust the stat cache accordingly.
0ab699f to
48093efComparePVince81
commented
Nov 8, 2016
Tests passed here #26574 and travis failure unrelated. |
PVince81
commented
Dec 7, 2016
stable9.1: #26791 |
PVince81
commented
Dec 7, 2016
stable9: #26792 |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
404 errors were not properly cached due to catching the wrong
exception. Now catching ClientHttpException and checking the error
code. In case of 404, adjust the stat cache accordingly.
Since now the local propfind() call throws NotFound, there is no need
to catch ClientHttpException everywhere any more but need to catch
NotFound exception instead and act accordingly.
Related Issue
Fixes#26323
Motivation and Context
Improve performance when creating new file/folders which usually first do a PROPFIND on the remote server to check for file/folder existence. Not caching these 404 would cause at least 6 additional PROPFIND requests to get the status. (this is because we use a lot of
file_existscall everywhere...)How Has This Been Tested?
See issue steps.
Screenshots (if appropriate):
Types of changes
Checklist:
Backports
@DeepDiver1975@butonic@jvillafanez