The cache (apps/common/runtime/cache) never clear. ver: 1.3.9.9

M

Manovra76

New Member
Hi, with the new version of mailwizz, the application does not delete the files in the cache folder periodically (apps/common/runtime/cache). This behavior generates XGb of files at each send campaign, which accumulates in the folder. Before the upgrade to version 1.3.9.9 this did not happen.

Help me please.
 
We're using cache more heavily now in the app, you should not remove those cache files. If disk space is an issue, please add more. We got a lot of performance improvements and we won't trade it for disk space.
 
@twisted1919

This seems to be the case already for previous version(s).

How is the distinction made between 'outdated/not-needed-anymore' and 'uptodate/in-use' cache?

In one case, there were over 50k .lock files in the mutex folder (and even though these files are empty, they count as disk occupation and increase various overheads). Re runtime cache, there were 'only' nearly 10k of 20b-2mb size. The oldest of these files goes back to October 2016, so the issue of carrying old cache files around seems to be not only from the latest version. Not sure how important this is, but perhaps the info helps.

Could the daily cleaner perhaps take care of this, even if only with a few days delay?
 
Last edited:
@frm.mwz - it's fine, i have fixed the caching issues for upcoming release which i'll make these days containing other small fixes as well.
 
HI,
I have read version 1.4.1 changelog there are no changes on cache duration. Waiting for an automatic cleanup of the cache folder by the program I wanted to ask if there is any problem clearing the cache folder (12 Gb in 5 days) and the mutex folder (600K files in 5 days)
 
@Manovra76 - Feel free to delete the cache folder, it's safe. But do it while no campaign is running.
As for the mutex folder, try not to delete that.
 
@frm.mwz - usually there is absolutely no need to empty the mutex folder, those file are empty so they won't occupy space.
if you want to delete the mutex files, you'd better do it when the whole app is idle and nothing happens in it.
 
frm.mwz said:
When is it safe to delete those mutex files? When all camps finished + ARs stopped + whole app offline?
Click to expand...

I use the following (which deletes Mutex files older than a day) via a once a day cronjob (I run it at 1am where we do nothing)
Code: 
find /[PATH_TO_MAILWIZZ]/apps/common/runtime/mutex/ -type f -mtime +1 -name '*.lock' -execdir rm -- {} +

Although the app is idle, I do not find that it cleans up mutex files - for example I would find files there from 22nd May (yesterday) and 21st May (day before yesterday). This sounds concerning to me as a mutex-lock should be a temporary lock and in case a lock fails/expires the mutex lock should be deleted. Not sure how PHP does it, but in other languages the mutex-cleanup is automatic (as part of a finally when an exception is thrown or when a process terminates).
 
twisted1919 said:
you'd better do it when the whole app is idle and nothing happens in it
Click to expand...
Yeah, had that sense...but wonder if that is so when 'all camps finished + ARs stopped + whole app offline' or what would be the minimal condition?
When are those mutex files created, what are they used for? This might help understand when not to touch them.

bidorbuy said:
I use the following (which deletes Mutex files older than a day) via a once a day cronjob (I run it at 1am where we do nothing)
Code: 
find /[PATH_TO_MAILWIZZ]/apps/common/runtime/mutex/ -type f -mtime +1 -name '*.lock' -execdir rm -- {} +

Although the app is idle, I do not find that it cleans up mutex files - for example I would find files there from 22nd May (yesterday) and 21st May (day before yesterday). This sounds concerning to me as a mutex-lock should be a temporary lock and in case a lock fails/expires the mutex lock should be deleted. Not sure how PHP does it, but in other languages the mutex-cleanup is automatic (as part of a finally when an exception is thrown or when a process terminates).
Click to expand...
This seems really good, more or less the way I go about it as well (but your cron is nicer!), simply to give either some time (1d) or totally stop the app (e.g. coinciding with a move).
 
bidorbuy said:
This sounds concerning to me as a mutex-lock should be a temporary lock and in case a lock fails/expires the mutex lock should be deleted. Not sure how PHP does it, but in other languages the mutex-cleanup is automatic
Click to expand...
Nothing to be concerned about, the mutex implementation uses php's flock() function to lock. The flock() functions needs a resource to operate on, and that resource is given using php's fopen() function which basically creates a file if it does not exist and returns a handler to the file to be used by flock(). When flock is done with the lock, fclose() is called to close the file handle, so the lock is removed but the file remains there. Next time when a lock with same name tries to be acquired, since the file exists, it won't be created anymore, only the lock will be acquired on it. That's the explanation in simple terms, and that's why i don't see a real reason for why the lock files to be removed.

@frm.mwz - "In computer programming, a mutex is a program object that allows multiple program threads to share the same resource, such as file access, but not simultaneously. When a program is started, a mutex is created with a unique name."
A theoretical example is a bank application. Say the customer has $10 in his account and opens a browser window where he starts an action to withdraw $10, then he opens another one to withdraw $10 more. If he does the actions one at a time, then he withdraws $10 and in the second window when he tries again, the system is going to tell him that he has $0 left, which is what you'd expect. However, if you start both actions at the same time, chances are that the system is not able to update the fact you removed $10 in before the second request to withdraw $10 more, so in the end, you'd had $10 in your account and you'd withdraw $20, which wouldn't be nice for bank apps, would it ?
That's why we need a mutex here, so that when a request to withdraw money starts, we lock it till it ends so that no further request can ask for more money till we are done completely and we update the current account balance to show $10 less.
See this answer of mine on stackoverflow a few days ago to a similar question: https://stackoverflow.com/questions...to-avoid-race-condition-for/44017076#44017076
 
You must log in or register to reply here.
Back
Top