forked from eliotsykes/page_cache
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CHANGELOG
34 lines (29 loc) · 1.66 KB
/
CHANGELOG
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
CHANGELOG
---------
2010-05-11
- Rake page_cache:update task now outputs benchmark times
- Introduced thread local variable CachedPage.current
- Introduced CacheUpdater, used by rake page_cache:update
- For improved performance, CacheUpdater will only request the content of
a page if the cached page is out-of-date.
- Leaked request detection now more accurate thanks to thread local variable set
in CacheUpdater, no longer assume that all non-local requests are leaks.
2010-05-10
- Added :ttl and :block_leaked_requests options to cached_pages.
- Introduced concept of "leaked requests" which is what happens when requests
that you want to be served by the Apache+cached-file sporadically get through
to the Rails app.
- Removed lock file optimization from rake page_cache:update task as this does
not work with :ttl option.
2010-04-20
- Sometimes requests are getting thorough to the Rails application for pages
that are cached and served statically by Apache. Unsure as to why this happens
though it coincides with when the rake page_cache:update task runs, so probably
something to do with overwriting a file in the 'live' cache directory that
Apache is simultaneously trying to serve. Perhaps this writing operation is
not atomic. Anyway, rather than risk spending too much time investigating
I've decided to change the behaviour to write a warning to the Rails log
file when this happens, instead of raising an exception that bubbles up to the
user. In this way the cached page will be served dynamically while the static
file is unavailable, although this defeats one of the main advantages of the
plugin over the standard Rails page cache behaviour.