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 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.
