Когда я вхожу в Redmine, он забывает, что я вошел в систему после первого щелчка по любой ссылке или сразу после перенаправления входа. После того, как я обновил страницу несколько раз, я все еще вхожу в систему в некоторых из этих ссылок.
ПРИМЕЧАНИЕ. Ошибка входа в систему отсутствует. Присутствует файл cookie _redmine_session.
Это напомнило мне о ситуации, когда у вас есть несколько узлов за балансировщиком нагрузки, и они не используют одно и то же хранилище сеансов, поэтому я уменьшил количество процессов uWSGI до 1 и вуаля - он работает, как ожидалось.
Это странно, потому что якобы redmine теперь хранит свою сессию в файлах cookie, поэтому общее хранилище не используется вообще.
Я хотел бы иметь больше процессов по соображениям производительности. И мне просто любопытно, что происходит. Я новичок в развертывании приложений Ruby (я вообще не использую Ruby, поэтому я еще не знаю всю экосистему).
Я использую:
Мой файл uWSGI .ini для redmine: (обратите внимание, что проблема проявляется, только если процессов> 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
Если вы используете PostgreSQL, попробуйте установить
lazy = true в конфигурации uWSGIprepared_statements: false в database.yml.В моем случае запрос таблицы пользователей случайно не выполняется с PG::Error: ERROR: prepared statement "a1" already exists, и возвращается к анонимному пользователю.
Казалось, что этого удалось избежать prepared_statements: false.
http://edgeguides.rubyonrails.org/configuring.html#configuring-a-database
Но все же я получил message type 0x54 arrived from server while idle иногда возникает ошибка, и Redmine перестает отвечать. Предполагается, что все рабочие используют одно и то же соединение с базой данных.
http://www.ruby-forum.com/topic/127814
lazy = true решил эту проблему, загрузив приложение в воркеры вместо мастера. prepared_statements: false не нужно.
uWSGI пытается (ab) использовать семантику копирования при записи вызова fork (), когда это возможно. По умолчанию он будет разветвляться после загрузки ваших приложений, чтобы разделить как можно больше их памяти. Если такое поведение по какой-то причине нежелательно, используйте ленивый вариант. Это укажет uWSGI загружать приложения после каждого worker fork (). Ленивый режим меняет способ работы изящной перезагрузки: вместо перезагрузки всего экземпляра каждый воркер перезагружается по цепочке. Если вы хотите «ленивую загрузку приложения», но хотите сохранить стандартное поведение перезагрузки uWSGI, начиная с версии 1.3, вы можете использовать опцию lazy-apps.
(из «Что нужно знать (лучшие практики и« проблемы »)» документации uWSGI)
Надеюсь это поможет.