from https://devcenter.heroku.com/articles/java-faq
<quote> The Heroku routing infrastructure does not support “sticky sessions”. Requests from clients will be distributed randomly to all dynos running your application. </quote> On Friday, 24 October 2014 04:41:06 UTC-5, Louis Amon wrote: > > I am trying to scale up my application deployed on Heroku by increasing > the number of dynos and am currently confronted with the issue of handling > sessions in a distributed environment. > > The regular solution (storing sessions in the database) does not seem to > work anymore when multiple dynos run concurrently : clients get asked for > login at every request. > I have no idea why this doesn't work since databases are supposed to be > shared between dynos on Heroku, but as far as I know there are 2 possible > ways to manage scalable sticky sessions: > > > 1. Memcache : couldn't use gluon/contrib to test this because the > MemcacheClient does not allow authentication in a connection string (i.e. > services like Memcached, MemCachier...) > 2. Redis : same issue --> Redis client does not seem to work well with > auth-based services that are available on Heroku (e.g. RedisCloud) > > > > Any idea why db-based sessions do not stick out of the box on Heroku, > and/or how to use a Cloud-based service to achieve session stickiness ? > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
