liuzqt opened a new pull request, #40982:
URL: https://github.com/apache/spark/pull/40982
<!--
Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, please read our contributor guidelines:
https://spark.apache.org/contributing.html
2. Ensure you have added or run the appropriate tests for your PR:
https://spark.apache.org/developer-tools.html
3. If the PR is unfinished, add '[WIP]' in your PR title, e.g.,
'[WIP][SPARK-XXXX] Your PR title ...'.
4. Be sure to keep the PR description updated to reflect all changes.
5. Please write your PR title to summarize what this PR proposes.
6. If possible, provide a concise example to reproduce the issue for a
faster review.
7. If you want to add a new configuration, please read the guideline first
for naming configurations in
'core/src/main/scala/org/apache/spark/internal/config/ConfigEntry.scala'.
8. If you want to add or modify an error type or message, please read the
guideline first in
'core/src/main/resources/error/README.md'.
-->
### What changes were proposed in this pull request?
Create `NonFateSharingCache` to wrap around Guava cache with a KeyLock to
synchronize all requests with the same key, so they will run individually and
fail as if they come one at a time.
Wrap cache in `CodeGenerator` as an example. Feel free to use this in other
places where we used Guava cache and don't want fate-sharing behavior.
Also, instead of implementing Guava Cache and LoadingCache interface, let's
define our own narrower APIs so that we can control at compile time what cache
operations are allowed and make sure all cache loading action go through our
narrow waist code path with key lock. Feel free to add new APIs when needed.
### Why are the changes needed?
Guava cache is widely used in spark, however, it suffers from fate-sharing
behavior: If there are multiple requests trying to access the same key in the
cache at the same time when the key is not in the cache, Guava cache will block
all requests and create the object only once. If the creation fails, all
requests will fail immediately without retry. So we might see task failure due
to irrelevant failure in other queries due to fate sharing.
This fate sharing behavior might lead to unexpected results in some
situation.
### Does this PR introduce _any_ user-facing change?
No
### How was this patch tested?
UT
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
