-
-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix file cache concurrency #420
Conversation
This commit also removes the `await` from every stream creation. The eviction will be handled totally assyncronously. The only drawback is the possibility of exceeding the cache limit for a moment, until the next execution of `evictOldest`. This will only be a problem if the cache is set too close to the remaining disk space, which I wouldn't recomend. I also removed the recursion.
(Strict mode in TS 4.4 enables useUnknownInCatchVariables, so this is redundant.)
I made a number of changes, let me know what you think.
Logging now looks like:
|
@@ -58,10 +61,14 @@ export default class FileCacheProvider { | |||
const stats = await fs.stat(tmpPath); | |||
|
|||
if (stats.size !== 0) { | |||
await fs.rename(tmpPath, finalPath); | |||
} | |||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, do we need to be catching and silently continuing here? I don't think this would throw because of race conditions anymore.
Each guild has a player. The error might occur if two or more guilds are using the bot at the same time (yes, I had this problem when I was testing with the mutex). |
I have a tendency of overthinking sometimes. What I thought was about a possible delay before returning the write stream, but as you said, |
Ah, should have been thinking about multiple guilds. Makes sense. |
I'll update my bot and test it today. |
Today the bot died with the same error. I don't think this will happen in clean installs, but it might be worth to expect this kind of error (file in the database but not in the folder) to avoid crashes. |
You're probably right. Would it make sense to update |
I think it should check both directions, but I don't like the idea of checking some files twice. It might impact the startup time of bots with big caches.
This is only an example, I don't know if it would be faster than looping through every file and looping through every database record, because of the update to the database. I might be overthinking again lol 😄 |
Just pushed an update that checks both directions, let me know how that works. I think adding a column is probably overkill and could lead to race conditions if you have multiple instances of Muse sharing the same database for some reason. |
I think this can be merged. |
Looks like I'll have to re-evaluate my approach to the GitHub Workflows I just added since it seems Secrets aren't accessible when running from a forked repo. |
Released in v0.1.1. |
Fixes #419
I was going to open the PR after my tests, but I decided to open it now to get feedback about the code.
Changes
Use
p-queue
to avoid the execution ofevictOldestIfNecessary
concurrently.I also removed the recursion from the function.
I don't like recursion and prefer to avoid it, only using it if it's really necessary. I always think of the possibility of a stack overflow.
I removed the
await
when callingevictOldestIfNecessary
.I want some feedback about this change. See the commit message for more info if needed.