getURLContentAsync cache [#15259]

Post a reply


In an effort to prevent automatic submissions, we require that you complete the following challenge.
Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: getURLContentAsync cache [#15259]

Re: getURLContentAsync cache

by MiPi » Thu Dec 13, 2018 7:32 am

It is current behavior. But it will be addressed soon I think. It should be probably part of DB maintenance, that will remove old entries, which only take place and won't be used to speed up requests, because they expired. Thanks for reminder, I have inserted Mantis entry for this: https://www.ventismedia.com/mantis/view.php?id=15259

getURLContentAsync cache [#15259]

by TIV73 » Sat Dec 01, 2018 12:18 pm

Hi there,
I recently stumbled over the URLRequestCache table in the MM5 DB and noticed that all requests I ever made with the getURLContentAsync function seem to be permanently stored there. At this point the table has close to 2.000 entries, dating back to 2017.
I mean, I'm not worried about functionality here - cached data is properly invalidated once the cacheTimeout period is passed and 2K entries isn't really a lot when thinking in DB dimensions. In addition I was (and still am) working on two plugins for the new auto-tag framework since 2017, so maybe my use case is just above average.

Nevertheless, I'm wondering if this is intended behavior - is the cached data meant to be stored permanently? Or is the caller of the getURLContentAsync function responsible to do some housekeeping later - and if so, how?

Top