opened
hlubek
username_0
Implement a new option `maxLockWaitMicroseconds` for file cache backends. Acquiring a lock now repeats after failure and waits at least this amount of time before failing. As a sensible default we wait a millisecond which is roughly the same as the previous hard-coded loop with 3 iterations.

Important cache backends like session should use a higher value by default. It would be best to actually cause an exception instead of silently not finding a cache entry for these scenarios.

Up for discussion: should we make the delay interval / range configurable? E.g. we could add a base delay and jitter.

Fixes #1911
Bugfix: Suppport configuration of max lock wait time
issue
created
albe
username_1
Hi @username_0 , can you take a look at https://github.com/neos/flow-development-collection/pull/1817 and possibly clean that up? @username_2 already invested quite some time into this and it was already prettyy far, but unfortunately never finished (also due to my lack of further feedback at some point).
comment
created
hlubek
username_0
Well, I didn't see #1817 before writing this. Sadly I cannot contribute to that PR (not a maintainer anymore). But I could merge the existing PR in my branch so we could close #1817 and continue here.
comment
created
fcool
username_2
Let me know, if I can be of any help. It would be very nice to have this settled, finally :)
comment
created
hlubek
username_0
@username_2 Thanks for the offer, I'll try to merge your PR with some ideas of this branch if it's okay for you.
comment
created
fcool
username_2
Of course. Your aim is my aim ;) We both want to better cope with low latency file systems
comment
created
sorenmalling
username_3
Hi @username_2  and @username_0 :) How did this move along, did you merge your ideas into one pull request, that we can merge?
comment
created
bwaidelich
username_4
I missed the two PRs until now. I took the freedom to turn this into a `FEATURE` since it is clearly one :)
@username_0 @username_2 did you see the comment from @username_3?
comment
created
fcool
username_2
Well... I have a different opinion on that. Because it is just failing on high latency file systems. Which at least is unexpected and in current state there is no way to recover but to use better performing file systes.
But yes - the proposed solution is a feature. My original commit in #1817 raised the default waiting time as well, so addressing the problematic behavior directly.
comment
created
bwaidelich
username_4
@username_2 Ah I see, thanks for the explanation.
I would say it's _two_ things in that case:
a potential bugfix that raises the waiting time and a feature that allows fine grained control over it. Don't you think?
comment
created
hlubek
username_0
This would be something to be addressed to not fail silently but could cause a behaviour change, so it needs additional configuration etc.
comment
created
kdambekalns
username_5
(Re-trigger) TravisCI…
comment
created
albe
username_1
Would like to get this into 7.1 as a feature. Can someone merge master into this again and maybe adjust the docs as Karsten suggested?
comment