Thanks for letting me know. I'll look into pyramid_redis_sessions.
-- Theron On Sun, Feb 16, 2014 at 12:06 PM, Mike Orr <[email protected]> wrote: > On Sat, Feb 15, 2014 at 11:34 AM, Theron Luhn <[email protected]> wrote: > > I'm using file-based Beaker sessions. If something happens to the > session > > file, (for example, if I delete the directory on my development > machine), I > > get a 500 error: > > > > > '[dir]/data/sessions/lock/e/e9/e953f617010ebeee3990cce9eb345c584e5fcb96.lock' > > I suspect the problem is missing parent directories rather than the > session files themselves. Beaker probably creates the parent > directories only on startup, and doesn't expect them to be deleted > while the application is running. I generally have to make the 'data' > directory myself or the application won't start. So the thing to do > would be to either have your failover routine (re)start the > application on the standby server, or modify the source to use > os.makedirs instead of os.mkdir. > > Beaker is not maintained anymore. The development version of Pyramid > is recommending pyramid_redis_sessions instead, which is the only > fully-maintained backend at this time. I was unhappy with this because > I was about to put an application into production that's using Beaker > file-based sessions (which I've never had problems with). But later we > decided we might use Redis on a wider scope, for caching and usage > statistics, so pyramid_redis_sessions would be a good way to start > gaining experience with it. I installed it last week, using a > self-compiled Redis, and it worked flawlessly. I'm going to put it in > production next week. I'm still using PostgreSQL as the primary > database. > > Longer-term, somebody needs to write a replacement for Beaker, or > 'pyramid_*' packages for the various backends. I've started looking > into it but I can't commit to it right now. The development version of > Pyramid has gotten more building blocks to write such backends with. > > We also need some HOWTOs on setting up non-backend sessions; e.g., > with regular database tables. I started trying that but got bogged > down in creating and managing the session ID, which Beaker does but > Pyramid doesn't support internally. I needed session IDs not only to > link the data to the user, but also to log with the request to count > the sessions per day, their length and entry/exit pages. It was enough > extra work that I went back to Beaker. > > The fundamental problem with Beaker is these lock files. It's using an > obsolete protocol borrowed from Perl::Mason that's more hassle than > it's worth. Beaker's successor, Dogpile, doesn't use this kind of lock > file. But Dogpile's author is not recommending it for sessions, which > I didn't expect. In any case, there's no Pyramid adapter yet for > Dogpile, that does the backend-neutral configuration like > pyramid_beaker does, so it's not an option without that. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "pylons-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/pylons-discuss/9zDnLK15Wks/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/groups/opt_out.
