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
Cache list of Tracker plugins in tracker than config file #6065
Comments
FYI I'll most likely not use tracker cache but another cache which is already loaded during tracking anyway (PersistentCache). This also brings the advantage that it is invalidated only every 12hours and not every 4 minutes as Cache should be invalidated on activate/deactivate/uninstall anyway. The actual problem with Tracker cache is the following: Imagine we are in PluginManager and we are trying to load the tracker plugins. Therefore we are asking the tracker cache to get the general cache and if PluginsTracker is not there yet, we are adding the it to this cache. Problem: We are calling The PersistentCache should be perfect for this and even faster as the |
…in a file. Wondering which test will fail...
PersistentCache just makes sense, nice one |
FYI: Each UI and API request is on my local instance about 40-80ms faster (2-10% - depends on which page/API is loaded) as we no longer have to check for tracker plugins on each request. |
… in tests? As glob will return files in any order it pleases. It is only a wrapper for libc glob() function
Should work. See comment in pull request re update file |
👍 |
We hit a bug caused by the fact that Tracker Plugins are stored in the config file.
It makes sense to dynamically cache the list of tracker plugins in the tracker cache instead.
As a result, Tracking servers will pull the list of plugins dynamically rather than rely on content of config file which may be wrong (if config file was not synchronised properly). Note: loading all plugins take 50ms which is too slow, so we must only load Tracker plugins.
Tasks
Plugins_Tracker
from config file on upgradePlugins_Tracker
in codebasesee also #6063
The text was updated successfully, but these errors were encountered: