Rails core - Jan 2006 - How should we do away with the rubysess white page of death?

Jamis Buck and I had a few ideas tonight that would each take care of  
the CgiRequest bug where switching between Rails apps that have  
different classes (models) stored in the session causes the whole app  
to crash without a trace.  Of course, the problem is only present  
when using the FileStore to store session data, since if the sessions  
are being stored in the DB, there shouldn''t be any conflict between  
apps.

Option #1: Add a "tmp" folder to the Rails app directory structure  
and store session files in "#{RAILS_ROOT}/tmp".  If each app has its  
own tmp folder, we could instruct it do something like this inside of  
the Rails initializer:

	ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:tmpdir] =  
File.join(RAILS_ROOT, ''tmp'')

Option #2: Create some kind of UUID or unique ID per app, and store  
rubysess files in "/tmp/#{app_specific_id}/rubysess.*"  This would  
require modifying railties to create a UUID when the rails app is  
first generated.

Option #3 (?): Use the UUID in the rubysess filename, e.g. rubysess.# 
{app_specific_id}.#{random_number}.  I don''t know if this one is  
possible, since I don''t know of a way to change the name of the files  
that CGI::Session FileStore.


I''ve heard that some core members aren''t too excited about
adding a
tmp/ folder to RAILS_ROOT, and I can understand why; however, adding  
the tmp/ folder (option #1) may be the best solution for a number of  
reasons:

a) It guarantees that there will be no conflict between rails apps
b) Apps can benefit from the change immediately (no need to generate  
a UUID with railties)
c) We''ll finally have a place to put those pesky fastcgi socket files
d) Other plugins may benefit from a tmp/ folder, e.g. file_column?


Cast your ballots.


Duane Johnson
(canadaduane)
http://blog.inquirylabs.com/




_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 26, 2006, at 8:40 AM, Duane Johnson wrote:
> Jamis Buck and I had a few ideas tonight that would each take care  
> of the CgiRequest bug where switching between Rails apps that have  
> different classes (models) stored in the session causes the whole  
> app to crash without a trace.  Of course, the problem is only  
> present when using the FileStore to store session data, since if  
> the sessions are being stored in the DB, there shouldn''t be any  
> conflict between apps.
The rubysess. file prefix and cookie names are configurable so the  
app generator may:

   class ApplicationController < ActionController::Base
     session :prefix => ''<%= @app_name %>.'',
:session_key => ''<%=
@app_name %>''
   end

Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFD2P+WAQHALep9HFYRAqVSAJ928/lFoLHCe1SrnrR+nAd7RctMDwCfeV7D
yFy6xwYnXVegjuhe3T5GWqI=jaQX
-----END PGP SIGNATURE-----

On Jan 26, 2006, at 9:57 AM, Jeremy Kemper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jan 26, 2006, at 8:40 AM, Duane Johnson wrote:
>> Jamis Buck and I had a few ideas tonight that would each take care  
>> of the CgiRequest bug where switching between Rails apps that have  
>> different classes (models) stored in the session causes the whole  
>> app to crash without a trace.  Of course, the problem is only  
>> present when using the FileStore to store session data, since if  
>> the sessions are being stored in the DB, there shouldn''t be
any
>> conflict between apps.
>
> The rubysess. file prefix and cookie names are configurable so the  
> app generator may:
>
>   class ApplicationController < ActionController::Base
>     session :prefix => ''<%= @app_name %>.'',
:session_key => ''<%=
> @app_name %>''
>   end
>
True. However, if a controller does not extend ApplicationController  
(and it happens--Basecamp has one of these) then it doesn''t get that  
functionality. I think Duane''s suggestion of a tmp/ directory under  
RAILS_ROOT has some real merit. It does add one more directory to the  
app structure, but it gives us a good place to store those transient  
files (like sockets, and session files). It also gives us a way to  
prevent the white-screen-of-death without requiring existing apps to  
make any changes.

It could even be made such that the tmp/ directory is created on- 
demand, rather than auto-generated, which would reduce the perceived  
clutter when an app is first generated. (It would actually have to be  
created on-demand for existing apps to work with this solution.)

- Jamis

Hello,

On 26 jan 2006, at 17.40, Duane Johnson wrote:
> I''ve heard that some core members aren''t too excited
about adding a
> tmp/ folder to RAILS_ROOT, and I can understand why; however,  
> adding the tmp/ folder (option #1) may be the best solution for a  
> number of reasons:
>
> a) It guarantees that there will be no conflict between rails apps
> b) Apps can benefit from the change immediately (no need to  
> generate a UUID with railties)
> c) We''ll finally have a place to put those pesky fastcgi socket
files
> d) Other plugins may benefit from a tmp/ folder, e.g. file_column?
Rails'' default session storage is one of the biggest reason we at  
TextDrive have had to to start using an almost abnormal large /tmp  
partition (and upping the number of inodes it''ll hold as well), due  
to the sheer amount of rubysess files being generated.  We''ve even  
begun to recommend either moving the PStore tmpdir to RAILS_ROOT/tmp  
or switching to the ActiveRecordStore[1].

Granted, one could argue that that''s a "hit" one has to take
for
offering rails hosting, but the above is just the way it looks today,  
and it is causing the occasional hiccup when it fills up (which will  
happen, even when cleaning out (really) old session files) and other  
daemons can''t use /tmp.

And speaking as a developer, I wouldn''t mind having a rails specific  
tmp dir under RAILS_ROOT for the same reasons Duane states, if the  
intention is to keep the current default session storage...

Cheers,
JS

[1]: http://weblog.textdrive.com/article/196/on-rails-sessions


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

At a slight tangent, isolating application sessions won''t fully solve
this problem; you can change the name of a Model object and see this
''white screen of death'' within the same application. Something
needs
to be wrapped around the session loading to let Rails gracefully
handle loading a malignant session and at least give the user *some*
feedback (logs, 500 status, anything really).

That said, I think creating the RAILS_ROOT/tmp directory on-demand is
a good idea - as Jamis points out, there are already files (like
fastcgi sockets) which are floating around and need an appropriate
home - a tmp directory seems to make sense here. It wouldn''t be hard
to provide a rake task to clean it up/remove it either:

  desc ''Clear all sessions and temporary files for this
application''
  task :clear_tmp => :environment do
    # presuming RAILS_TMP is either defined by the user, or set by default:
    # RAILS_TMP = File.join(RAILS_ROOT, ''tmp'') unless
Object.const_defined?(:RAILS_TMP)
    FileUtils.rm_r(RAILS_TMP)
  end

  desc ''Clean application''
  task :clean => [:clear_logs, :clear_tmp]


... or whatever.

- James

On 1/26/06, Duane Johnson <duane.johnson@gmail.com>
wrote:
> Jamis Buck and I had a few ideas tonight that would each take care of the
> CgiRequest bug where switching between Rails apps that have different
> classes (models) stored in the session causes the whole app to crash
without
> a trace.  Of course, the problem is only present when using the FileStore
to
> store session data, since if the sessions are being stored in the DB, there
> shouldn''t be any conflict between apps.
>
> Option #1: Add a "tmp" folder to the Rails app directory
structure and store
> session files in "#{RAILS_ROOT}/tmp".  If each app has its own
tmp folder,
> we could instruct it do something like this inside of the Rails
initializer:
>
> ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:tmpdir]
> = File.join(RAILS_ROOT, ''tmp'')
>
> Option #2: Create some kind of UUID or unique ID per app, and store
rubysess
> files in "/tmp/#{app_specific_id}/rubysess.*"  This would
> require modifying railties to create a UUID when the rails app is first
> generated.
>
> Option #3 (?): Use the UUID in the rubysess filename, e.g.
> rubysess.#{app_specific_id}.#{random_number}.  I don''t know
> if this one is possible, since I don''t know of a way to change the
name of
> the files that CGI::Session FileStore.
>
>
> I''ve heard that some core members aren''t too excited
about adding a tmp/
> folder to RAILS_ROOT, and I can understand why; however, adding the tmp/
> folder (option #1) may be the best solution for a number of reasons:
>
> a) It guarantees that there will be no conflict between rails apps
> b) Apps can benefit from the change immediately (no need to generate a UUID
> with railties)
> c) We''ll finally have a place to put those pesky fastcgi socket
files
> d) Other plugins may benefit from a tmp/ folder, e.g. file_column?
>
>
> Cast your ballots.
>
>
> Duane Johnson
> (canadaduane)
> http://blog.inquirylabs.com/
>
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>
>

On Thu, 2006-01-26 at 17:55 +0000, James Adam wrote:
> That said, I think creating the RAILS_ROOT/tmp directory on-demand is
> a good idea - as Jamis points out, there are already files (like
> fastcgi sockets) which are floating around and need an appropriate
> home - a tmp directory seems to make sense here. It wouldn''t be
hard
> to provide a rake task to clean it up/remove it either:
> 
>   desc ''Clear all sessions and temporary files for this
application''
>   task :clear_tmp => :environment do
>     # presuming RAILS_TMP is either defined by the user, or set by default:
>     # RAILS_TMP = File.join(RAILS_ROOT, ''tmp'') unless
> Object.const_defined?(:RAILS_TMP)
>     FileUtils.rm_r(RAILS_TMP)
>   end
I''d like to add a ''me too'' to the list who would like
an on demand tmp
directory especially if it is implemented with a RAILS_TMP style
constant. This would make a very nice and easy way to tweak
configurations on a machine such that any consideration a site may need
for the tmp directory could be handled with little to no code changes.
-- 
Steven Critchfield <critch@basesys.com>

On Jan 26, 2006, at 10:55 AM, James Adam wrote:
> At a slight tangent, isolating application sessions won''t fully
solve
> this problem; you can change the name of a Model object and see this
> ''white screen of death'' within the same application.
Something needs
> to be wrapped around the session loading to let Rails gracefully
> handle loading a malignant session and at least give the user *some*
> feedback (logs, 500 status, anything really).
>
The root of the issue here is that CGI::Session doesn''t raise an  
exception when this sort of behavior occurs.  It''s awful, I know, but  
it''s the sad truth: there''s no way to know in advance if

	request  = ActionController::CgiRequest.new(cgi, session_options)

will totally fail or not, and there''s no exception raised. 
It''s even
in the docs that "things will break nastily" [1] in just this sort of
situation.  If I am wrong here (and I''d love to be) then please let  
me know.
> That said, I think creating the RAILS_ROOT/tmp directory on-demand is
> a good idea - as Jamis points out, there are already files (like
> fastcgi sockets) which are floating around and need an appropriate
> home - a tmp directory seems to make sense here. It wouldn''t be
hard
> to provide a rake task to clean it up/remove it either:
The only question that remains for the on-demand issue is what to do  
about lighttpd''s sockets--as far as I know, the folder that the  
sockets go in has to exist before lighttpd will even try to  
communicate with fcgi.  I could be wrong here, too.  Perhaps we can  
create tmp/ when "ruby script/server" is invoked?  In any case, I  
think the railties default behavior should be to generate an empty  
tmp/ folder for completeness.
>   desc ''Clear all sessions and temporary files for this
application''
>   task :clear_tmp => :environment do
>     # presuming RAILS_TMP is either defined by the user, or set by  
> default:
>     # RAILS_TMP = File.join(RAILS_ROOT, ''tmp'') unless
> Object.const_defined?(:RAILS_TMP)
>     FileUtils.rm_r(RAILS_TMP)
>   end
>
>   desc ''Clean application''
>   task :clean => [:clear_logs, :clear_tmp]
>
Nice :)


Duane Johnson
(canadaduane)
http://blog.inquirylabs.com/




_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

> > At a slight tangent, isolating application sessions won''t
fully solve
> > this problem; you can change the name of a Model object and see this
> > ''white screen of death'' within the same application.
Something needs
> > to be wrapped around the session loading to let Rails gracefully
> > handle loading a malignant session and at least give the user *some*
> > feedback (logs, 500 status, anything really).
> >
> 
> The root of the issue here is that CGI::Session doesn''t raise an  
> exception when this sort of behavior occurs.  It''s awful, I know,
but
> it''s the sad truth: there''s no way to know in advance if
> 
> 	request  = ActionController::CgiRequest.new(cgi, session_options)
> 
> will totally fail or not, and there''s no exception raised. 
It''s even
> in the docs that "things will break nastily" [1] in just this
sort of
> situation.  If I am wrong here (and I''d love to be) then please
let
> me know.
Actually, it does raise an exception (at least in the case where it
can''t
open the session file due to permissions issues). But the error handling path
assumes the presense of a working session object so the exception never gets
logged.  I filed that bug here: http://dev.rubyonrails.org/ticket/3474.

> Option #1: Add a "tmp" folder to the Rails app directory
structure and store
> session files in "#{RAILS_ROOT}/tmp".  If each app has its own
tmp folder,
> we could instruct it do something like this inside of the Rails
initializer:
I''m cool with this now as well. Especially since this will mean that
its easier to have two instances of the same application running on
the same machine. Something app-name based options won''t help with.

Also, please someone do investigate #3474. I''d really like to declare
a death to white screens in 1.1.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

On Jan 26, 2006, at 2:42 PM, David Heinemeier Hansson wrote:
>> Option #1: Add a "tmp" folder to the Rails app directory
structure
>> and store
>> session files in "#{RAILS_ROOT}/tmp".  If each app has its
own tmp
>> folder,
>> we could instruct it do something like this inside of the Rails  
>> initializer:
>
> I''m cool with this now as well. Especially since this will mean
that
> its easier to have two instances of the same application running on
> the same machine. Something app-name based options won''t help
with.
>
Alright, thanks for everyone''s thoughts on this one.  I''ll go
ahead
an write something up to fix this once and for all.
> Also, please someone do investigate #3474. I''d really like to
declare
> a death to white screens in 1.1.
Does anyone feel qualified to look at this?  I can take a look, and  
see what I can do.  Any help would be appreciated.

Duane

I''ll take a stab at it this weekend.

On 1/27/06, Duane Johnson <duane.johnson@gmail.com>
wrote:
> > Also, please someone do investigate #3474. I''d really like to
declare
> > a death to white screens in 1.1.
>
> Does anyone feel qualified to look at this?  I can take a look, and
> see what I can do.  Any help would be appreciated.