-
Notifications
You must be signed in to change notification settings - Fork 16
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
stapi::refresh_ctable doesn't rewrite the TSV cachefile #50
Comments
With a long-running process, the in-memory speedtable is used. ISTR this was created to avoid having short-running processes beating on the speedtable server. How would you envision long-running processes using the cache? |
On restart of the process, to reduce the recovery time? Loading from the
cache seems to be substantially faster than loading by running the query.
|
If the in-core table is completely up to date (re #51 ) then this would be worthwhile doing. If you know the in-core table is valid because you're performing a complete reload or because you know there are no deletions, then updating the table would be worthwhile. This could be done automatically in reload_ctable or manually (with an update_cache call) after refresh_ctable. |
Should probably have set this to a non-zero value, originally.
|
Have you tried setting the -timeout value (seconds) which is supposed to refresh the tsv file after $timeout seconds when you open it? |
Have a look at bc8513c |
The TSV cachefile gets written once during ::stapi::open_cached, but then it never appears to get updated, even if you're calling ::stapi::refresh_ctable.
So for long-running processes that periodically refresh, the cache rarely gets used.
The text was updated successfully, but these errors were encountered: