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

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

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

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

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

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

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

[web2py] Re: Sticky sessions in a distributed environment

Any project will eventually outgrow any framework it uses, when that happens you can either contribute to the framework if it makes sense or just do it yourself for that application. The advantage is that with web2py you can use the included tools while you don't reach that moment while with a

[web2py] Re: Sticky sessions in a distributed environment

I don't think commenting about my age is any more mature than what you claim I would be... Anyway, contributing is amongst my current preoccupations - as I mentionned in another post. The thing is : my disappointment here lies in the architecture, not the features. There is little contribut

[web2py] Re: Sticky sessions in a distributed environment

> I now get why many blogs and forums discussing "web2py vs other framework" always end up mentionning that developping on web2py starts as a very thrilling experience but often leaves a bitter taste. You could have suggested that we make admin more production ready than it already is, maybe ev

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

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

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

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

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

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

[web2py] Re: Sticky sessions in a distributed environment

How will you get your db configuration in admin? I don't think it should have all these ifs and elifs specially for heroku when this isn't heroku specific, this is about how you can configure the admin to store cookies in the DB. Maybe just add an option in settings.cfg to configure the admin's

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

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

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

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

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

[web2py] Re: Sticky sessions in a distributed environment

Store your sessions in cookies? To *store sessions in cookies* instead you can do: session.connect(request,response,cookie_key='yoursecret',compression_level=None) Here cookie_key is a symmetric encryption key. compression_level is an optional zlib encryption level. While sessions in cookie ar

[web2py] Re: Sticky sessions in a distributed environment

+1 on anthony. Dynos are meant to scale as "serving frontends". The data(base) that a dyno1 sees NEEDS to be the same data(base) dyno2 sees, or the whole concept of consistency is not assured (and there's little point of being "distributed" when the only consistency is assured by having a repli

[web2py] Re: Sticky sessions in a distributed environment

With sessions in a shared database, you shouldn't need sticky sessions, as the sessions are accessed in one central location. Not sure why it's not working in this case, but it bears further investigation. Anthony On Friday, October 24, 2014 5:41:06 AM UTC-4, Louis Amon wrote: > > I am trying t

[web2py] Re: Sticky sessions in a distributed environment

from https://devcenter.heroku.com/articles/java-faq The Heroku routing infrastructure does not support “sticky sessions”. Requests from clients will be distributed randomly to all dynos running your application. On Friday, 24 October 2014 04:41:06 UTC-5, Louis Amon wrote: > > I am trying to