ActiveScaffold doesn't delete session vars, 500 internal server error?

76 views
Skip to first unread message

Fiend

unread,
Nov 3, 2009, 1:33:41 PM11/3/09
to ActiveScaffold : Ruby on Rails plugin
Take a look at this ancient thread:

http://groups.google.com/group/activescaffold/browse_thread/thread/4d05202808be9404/a0f5a74411babebf?lnk=gst&q=session#a0f5a74411babebf

It describes everything ActiveScaffold stores in the Rails session.
Okay, no biggie... but apparently it doesn't delete them! If you
periodically check the session as with:

puts session.inspect

you'll see the same stuff Lance Ivy said would be in the session, but
I see many instances of it.

In other words, you start your app up, view a scaffold, the session
now contains the constraints, etc, for the scaffold... then you go
somewhere else in the application, come back and view the scaffold
again, now you have another copy of those session vars. Eventually the
session will build to its max (~40K) and you'll get either the "cookie
session storage exceeded" error or the more common 500 Internal Server
Error. This is at least what is happening to me, and I have a major
commercial application, and I need to assess this problem.

Is ActiveScaffold doing this to cache the results? e.g., make viewing
the scaffold go faster, given it has the same constraints?

Anyway to safely delete these session vars?

Nick Rogers

unread,
Dec 1, 2009, 2:38:31 PM12/1/09
to actives...@googlegroups.com
I had the same problem because my application has about 100 scaffolds in it that are rendered inline 2-5 at a time in different views. I solved this by purging the session of active_scaffold related keys via a before_filter every time I load a view that renders one or more active_scaffolds inline. i.e., you want to run the before_filter for each action of the view that renders the inline scaffold(s) and not for each action of the scaffold controller itself.

  # on each main view load, clean up our session store garbage caused by
  # active_scaffold scaffolds that are no longer being displayed, so that we
  # don't reach the cookie size limit when using the cookie session store
  before_filter :purge_as_session_variables, :only => FULL_PAGES

  # in order to purge the session variables used by active_scaffold, we must
  # first backup the non-as variables, then reset the session entirely, since
  # removing individual keys is not possible, then repopulate the session with
  # the non-as variables
  def purge_as_session_variables
    session_backup = Hash.new

    self.session.to_hash.each do |k, v|
      session_backup[k] = v unless k.to_s =~ /\Aas:/
    end
    
    # delete all keys - setting the as:* keys to nil is not good enough as we
    # can still exceed the cookie limit
    reset_session
    
    # recreate the original session minus as:* variables
    session_backup.each { |k,v| session[k] = v }
  end




--

You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" group.
To post to this group, send email to actives...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activescaffold?hl=en.



Ed W

unread,
Dec 2, 2009, 1:57:04 PM12/2/09
to actives...@googlegroups.com
Nick Rogers wrote:
> I had the same problem because my application has about 100 scaffolds
> in it that are rendered inline 2-5 at a time in different views. I
> solved this by purging the session of active_scaffold related keys via
> a before_filter every time I load a view that renders one or more
> active_scaffolds inline. i.e., you want to run the before_filter for
> each action of the view that renders the inline scaffold(s) and not
> for each action of the scaffold controller itself.
>

Hmm, I think your answer explains the problem... My first thought was
why you didn't do it in the after filter, then I realised why I was an
idiot and also why it's a non trivial problem

I guess you should submit some version of your before filter as a bug
fix. Note I'm not sure it make sense to erase all the session variables
at the start of the session (presumably before they can even be used?)?

Cheers

Ed W
Reply all
Reply to author
Forward
0 new messages