Home / server / Questions / 485425
Accepted
pinkeen
Asked: 2013-03-07 15:40:35 +0800 CST

Redmine (RoR rack app) on uWSGI forgets sessions when ran with more than one process

  • 772

When I log into redmine it forgets that I was logged after first click on any link or immediately after the login redirect. After I refresh the page a few times, I am still logged in in some of this refereshes.

NOTE: There is no login error. The _redmine_session cookie is present.

This reminded me of the situation where you have multiple nodes behind a load balancer and they don't share the same sessions storage so I decreased the number of uWSGI processes to 1 and voila - it works as expected.

It's strange because supposedly redmine stores its session in cookies now, so no shared storage is used at all.

I would like to have more processes for performance reasons. And I'm simply curious what's goin on. I'm new to deploying ruby apps (I don't do ruby at all so I don't know the whole ecosystem yet).

I'm using:

  • CentOS 6.3
  • redmine 2.2.3
  • ruby 1.8.7
  • uWSGI 1.4.8 with rack plugin linked in statically

My uWSGI .ini file for redmine: (note that the problem manifests itself only if processes > 1)

[uwsgi]
socket = 127.0.0.1:3032
master = true
processes = 1
post-buffering = 4096
env = RAILS_ENV=production
logto = /var/log/uwsgi/redmine.log
uid = dsh
gid = nginx
rack = /home/dsh/redmine/config.ru
centos

1 Answers

  1. Best Answer

    If you are using PostgreSQL, try setting

    • lazy = true in uWSGI configuration
    • and/or prepared_statements: false in database.yml.

    In my case, the query of the user table fails randomly with PG::Error: ERROR: prepared statement "a1" already exists, and falls back to the Anonymous user.

    It seemed to be avoided by prepared_statements: false.

    http://edgeguides.rubyonrails.org/configuring.html#configuring-a-database

    But still, I got message type 0x54 arrived from server while idle error sometimes, and the Redmine stopped responding. It is suspected that all workers share the same database connection.

    http://www.ruby-forum.com/topic/127814

    lazy = true solved this problem by loading the application in workers instead of the master. prepared_statements: false isn't necessary.

    uWSGI tries to (ab)use the Copy On Write semantics of the fork() call whenever possible. By default it will fork after having loaded your applications to share as much of their memory as possible. If this behavior is undesirable for some reason, use the lazy option. This will instruct uWSGI to load the applications after each worker’s fork(). Lazy mode changes the way graceful reloading works: instead of reloading the whole instance, each worker is reloaded in chain. If you want “lazy app loading”, but want to maintain the standard uWSGI reloading behaviour, starting from 1.3 you can use the lazy-apps option.

    (from "Things to know (best practices and “issues”)" of uWSGI documentation)

    Hope this helps.

    • 0