I am collecting information to be sent to a print routine that
ultimately uses prawn to generate a PDF.
It writes an error to the logs…
Completed in 4304ms (View: 1, DB: 102) | 200 OK
[https://myserver/payables/print_the_checks]
/!\ FAILSAFE /!\ Wed Sep 30 18:41:52 -0700 2009
Status: 500 Internal Server Error
ActionController::Session::CookieStore::CookieOverflow
/usr/lib/ruby/gems/1.8/gems/actionpack-2.3.2/lib/action_controller/session/cookie_store.rb:102:in
`call’
though my session variables themselves are not very large, the ‘POST’ is
fairly large.
Do I need to discard some of the data that I’ve already accrued in
instance variables and re-acquire the data in my controller to shrink
the amount I ‘POST’ ? Would that help with the CookieOverflow ? Is it
possible to increase the size permitted ?
Craig
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Craig W. wrote:
Do I need to discard some of the data that I’ve already accrued in
instance variables and re-acquire the data in my controller to shrink
the amount I ‘POST’ ? Would that help with the CookieOverflow ? Is it
possible to increase the size permitted ?
Cookies have a maximum size of 4K. That’s how they were implemented and
it has nothing to do with Rails. I suspect some object might be getting
stored in your session. I would start by trying to track down exactly
what is getting stored in the session cookie. If you must store more
than 4K in your session then you’ll need to change from the default
session storage to one of the other options. But, you should first try
to figure out why your session is larger than 4K and see if you can work
around that.
A common problem is storing ActiveRecord objects in the session rather
than just storing the id and looking up the ActiveRecord object on each
request. Don’t worry Rails should cache the SQL so it shouldn’t be too
much of a performance hit.
On Thu, 2009-10-01 at 05:57 +0200, Robert W. wrote:
than 4K in your session then you’ll need to change from the default
session storage to one of the other options. But, you should first try
to figure out why your session is larger than 4K and see if you can work
around that.
A common problem is storing ActiveRecord objects in the session rather
than just storing the id and looking up the ActiveRecord object on each
request. Don’t worry Rails should cache the SQL so it shouldn’t be too
much of a performance hit.
when I put <%= session.inspect %> into the view I saw that the AR stuff
from the POST is indeed part of the session which was not clear to me
from everything I was reading in Rails documentation and from Google
searching.
So I went to using AR for the session store and now I am fine.
But since I am using a legacy db, I would prefer not having
schema_migrations and sessions tables as tables in these db’s but rather
in a separate db if such a thing is possible (which I think it is).
I have seen many various ideas about using ‘establish_connection’ but I
don’t see how you would use a separate database for ‘schema_migrations’
and ‘sessions’ tables since they don’t have a Model in my setup.
Has anyone done this? How do you accomplish it?
Craig
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.