Action Cache plugin bug fixes

I’ve just checked in three fixes for the action_cache plugin.

  1. Don’t send cookie headers when serving cached responses (the original response will be untouched)
  2. Always use 2 cache fragments for action cache entries. This avoids the escape/unescape overhead for the body and speeds cache serving up and reduces the code complexity a little
  3. Remove use of the returning method. Older versions of Rails don’t have this method.

I’ve also added a specific page to this site for details about the action_cache

Thanks to Paul Haddad and Timur Vafin for bug reports.

This entry was posted on Wed, 21 Mar 2007 04:48:06 GMT . You can follow any any response to this entry through the Atom feed. You can leave a comment or a trackback from your own site.
Tags


Trackbacks

Use the following link to trackback from your own site:
http://blog.craz8.com/trackbacks?article_id=action-cache-plugin-bug-fixes&day=20&month=03&year=2007

Comments

Leave a response

  1. Pete about 1 month later:

    Thanks for the great plugin.

    A question, or possibly a bug:

    My before_filters don’t run when an action specifies response.time_to_live. They run when response.time_to_live is absent. The before_filter calls are made before the call to caches_action. Is this a bug, or am I doing something wrong?

    Worst case scenario we’ll sweep the cache through backgroundrb or chron or something :)

    Thanks again!

  2. tom about 1 month later:

    This should work the way you expect it to.

    I’ll take a look to see why this isn’t working as expected.

  3. tom about 1 month later:

    Here’s a thought: When time_to_live is set, the plugin sets the Cache-Control header to the time_to_live value on the response. This will cause the browser to not make the request at all until the time_to_live has expired.

    Can you see if the request is even getting to your server when your before_filters aren’t being called?

  4. Pete about 1 month later:

    That makes sense. We’re trying to record hits for access to certain model instances, so we’ll have to decide if the same person viewing the same object within the TTL is a significant statistic. If so, monkey-patching the plugin to not set the Cache-Control header should work. Do you forsee any problems with that approach?

  5. tom about 1 month later:

    If you set the Cache-control header to have a value of max-age=0 somewhere in the initial request, then the plugin won’t change it.

    response.headers['Cache-Control'] = "max-age=0"
  6. Fabio 9 months later:

    Hey,

    I don’t know if anyone else’s using your plugin, I for one still am, a lot. So somewhere from 1.2.3 to 2.0, render (and some other controller stuff) is protected so action_cache.rb #148 send_not_modified would not access render via controller.render.

    This would work, tho:

    def send_not_modified(controller)
  controller.logger.info "Send Not Modified" 
  #controller.render(:text => "", :status => 304)
  controller.send(:render, :text => "", :status => 304)
end

    I don’t know if there’s anything else not working in the Edgy world, I’ll let you know if I bump into anything else!

  7. tom 9 months later:

    That should fix it for Rails 2.0.

    I haven’t spent any time on 2.0 yet, and I’m now using a different way of caching that works around the expiry issues with action caching in general, and more so with my plugin.

  8. Nate 10 months later:

    I believe there is also a problem with this plugin as is, because Rails 2.0 also tweaked filters:

    http://ryandaigle.com/articles/2007/10/22/what-s-new-in-edge-rails-filters-get-tweaked

    So returning false in a before filter doesn’t halt execution of the action chain. I looked at what the ActionController is doing in its renders and it sets a @performed_render to signal that the render has been done. So you could add a:

    controller.instance_variable_set(:@performed_render, true)

    at line 122 of action_cache.rb just before returning false in the before filter so that execution is halted as desired. “send_not_modified” already uses render_text so this was working fine, but the other “sends” in this plugin don’t use the render methods.

Leave a comment