使用会话RamSession背后nginx的CherryPy的错误(Error using sess

2019-10-17 06:32发布

我使用基于背后nginx的RamSession我自己的会话中运行一个应用程序的CherryPy。 问题是在每次请求的会话ID的变化。 我相信这个问题是每一个请求是由它去到不同的工人,因此会话保存的时间,但它不是由下一个可用的工人(有限的知识上是如何工作的不幸)的下一个请求认可。 当我设置的工人数量为1,然后按预期工作的一切。 我知道我大概可以使用FileSession或任何类型的基于DB会话处理程序,而只是想知道是否有一个解决方案。 谢谢

这里是我的新贵脚本:

description "uwsgi tiny instance"
start on runlevel [12345]
stop on runlevel [06]

exec /home/web/.virtualenvs/myenv/bin/uwsgi --uid web -H /home/web/.virtualenvs/myenv -w myapp.wsgi -p 1 -M -s 127.0.0.1:3031

这里是我的会议:

class MySession(sessions.RamSession):
    def clean_up(self):
        """Clean up expired sessions."""
        now = self.now()
        for id, (data, expiration_time) in copyitems(self.cache):
            if expiration_time <= now:
                try:
                    active = Mongo(ActiveSession).find_one('active', self.cache['active'])
                    Mongo(ActiveSession).remove(active)
                except:
                    print "Failed to remove active session object."
                try:
                    del self.cache[id]
                except KeyError:
                    pass
                try:
                    del self.locks[id]
                except KeyError:
                    pass
        # added to remove obsolete lock objects
        for id in list(self.locks):
            if id not in self.cache:
                self.locks.pop(id, None)

和我的配置:

config = {
    '/static': {
        'tools.staticdir.on': True,
        'tools.staticdir.dir': os.path.join(current_dir, 'media/public')
    },
    '/fotos': {
        'tools.staticdir.on': True,
        'tools.staticdir.dir': os.path.join(current_dir, 'media/fotos')
    },
    '/' : {
        'tools.sessions.on': True,
        'tools.sessions.name': 'myapp'
        'tools.sessions.storage_type': 'my',
        'engine.autoreload_on': False
    }
}

Answer 1:

你的直觉是正确的:在RamSession在时间被限制到1点的过程。 简单的解决办法是切换到FileSession(如果你的员工都可以访问相同的文件系统)或DB会话。 假设你的工人被严重分散,极有可能是后者。



文章来源: Error using session RamSession with cherrypy behind nginx