Re: [web2py] Re: Sticky sessions in a distributed environment

2015-05-04 Thread Louis Amon
Update Heroku now provides an elegant solution to this issue : session affinity https://devcenter.heroku.com/articles/session-affinity Basically, it sets a special cookie that tends to distribute users towards the dyno t

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-12-04 Thread Louis Amon
> > I'm not too familiar with Heroku, but according to the little > documentation I have seen, the filesystem should persist until the dyno > restarts or is shut down. Does it really just reset randomly? > In theory you would be correct. The doc says that it resets on restarts or upon stopping

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-12-04 Thread Anthony
On Thursday, December 4, 2014 9:21:22 AM UTC-5, Louis Amon wrote: > > Note, aside from adding a few lines in the admin app to have its sessions >> stored in the db, another option might be to edit the handler file used to >> start web2py. In that file, you should be able to do something like this

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-12-04 Thread Louis Amon
> > Note, aside from adding a few lines in the admin app to have its sessions > stored in the db, another option might be to edit the handler file used to > start web2py. In that file, you should be able to do something like this: > > from gluon.settings import global_settings > global_settings.

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-28 Thread Anthony
Louis, I think you're getting a little pushback because you make a rather extreme criticism in the face of a fairly small issue that (a) you can easily work around right now and (b) would not be difficult to fix in the framework. Furthermore, the issue at hand affects features of web2py (i.e.,

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-28 Thread Niphlod
ticketing doesn't depend on admin, and you - again usually - don't want to see errors on the production server. Just copy errors over and see them on your development instance (or let the script tickets2email.py send the errors over to you). And...in a production server appadmin.py isn't needed

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-28 Thread Louis Amon
Right. Then why does the whole ticketting system depend on "admin" ? It is even said in the Deployment Recipe chapter of the doc : "You can later view the errors *using the admin app*, clicking on the "s

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-26 Thread Niphlod
I agree, but let us remind that the "admin" app is not meant to be deployed anywhere in production: its probably the reason why the "corner-case" surfaced now instead of some time ago. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-26 Thread Louis Amon
After a whole day of struggling I came to the conclusion that this is more of a design flaw than a bug : Appadmin is designed to check credentials with another application (admin). The default behaviour of the credential checking system does not allow any modification and has to be done with gl

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-26 Thread Anthony
On Wednesday, November 26, 2014 8:34:58 AM UTC-5, Louis Amon wrote: > > I can’t find any documentation about settings.cfg. > > How does it work ? Where is it loaded ? Is it application-specific ? > settings.cfg is in /web2py/applications/admin/ and is specific to the admin app. Currently it only

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-26 Thread Louis Amon
I can’t find any documentation about settings.cfg. How does it work ? Where is it loaded ? Is it application-specific ? I’m not sure setting a connection string in a file is the way to go with Heroku : you don’t really have those (they are dynamically generated). When you create a db in Heroku

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-26 Thread Louis Amon
Ok I think I found where the problem lies: In applications/admin/models/access.py we have this structure: if request.env.web2py_runtime_gae: session_db = DAL('gae') session.connect(request, response, db=session_db) hosts = (http_host, ) is_gae = True else: is_gae = False Wha

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-25 Thread Anthony
> > I checked into my browser's development tools to check cookies and found > that indeed, there are two cookies : session_id_APPNAME and > session_id_admin. These cookies and their values are persistent through > requests, even with multiple dynos. > > I now wonder about web2py's session ma

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-11-25 Thread Louis Amon
I've been in contact with Heroku's support regarding this issue, and here is what they told me : This doesn't appear to be a problem coming from our platform. Any request > coming into your app will have session cookies passed. > The way sessions stored on databases work is by setting a cookie w

Re: [web2py] Re: Sticky sessions in a distributed environment

2014-10-29 Thread Louis Amon
I tried to apply Derek’s advice by storing sessions in cookies, same problem : as long as my web app runs on 1 dyno everything works fine but if I scale it to 2 or more then sessions start to break. I also +1 on what Anthony said : wether it be stored in a database or in a cookie, a session sho