What if we follow an approach of persisting the session to a datastore, like we've done in the petstore sample, that way you don't need to worry about affinity or the node having the session failing. In memory session replication is costly & leads to a whole lot of other issues, like the ones we've seen with replicated caches, so it best to avoid it.
On Wed, Mar 9, 2016 at 6:32 PM, Sanjiva Weerawarana <[email protected]> wrote: > Manu's question is in the context of the reusable UI framework stuff we're > working on. > > Fundamentally, is it necessary to have sessions to write a UI? Can we use > HATEOS for some stuff, browser local storage for some stuff etc. and not > have sessions at all?? > > I feel we need sessions as a lot of simple things become hard without them. > > Then comes the question of how do we do sessions and whether we do some > kind of replication or rely on affinity based routing. > > On Wed, Mar 9, 2016 at 5:23 PM, Afkham Azeez <[email protected]> wrote: > >> With such a model, you don't have to worry about things like session >> replication in order to achieve HA. >> >> On Wed, Mar 9, 2016 at 3:32 PM, Manuranga Perera <[email protected]> wrote: >> >>> Should we aim to do the same in the UIs we ship, such as products ES? >>> There will be some extra effort. >>> >>> On Wed, Mar 9, 2016 at 2:12 PM, Afkham Azeez <[email protected]> wrote: >>> >>>> In the petstore sample, the sessions of the frontend apps are stored in >>>> Redis. >>>> >>>> On Wed, Mar 9, 2016 at 1:57 PM, Imesh Gunaratne <[email protected]> wrote: >>>> >>>>> Hi Manuranga, >>>>> >>>>> Yes, what you are saying it true! We should only use session aware >>>>> load balancing for existing applications which has session management >>>>> features built into them. >>>>> >>>>> Ideally when implementing new applications those should be designed in >>>>> a way to store their sessions outside the application (irrespective of >>>>> they >>>>> run on containers or not). This can be done with either using a database >>>>> or >>>>> a service (ex: Redis). In that way we can scale the application and >>>>> session >>>>> management service separately and also route request without handling >>>>> sessions at the load balancer level. >>>>> >>>>> Thanks >>>>> >>>>> On Wed, Mar 9, 2016 at 1:12 PM, Manuranga Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> We are currently using sessions and session affinity in our apps. But >>>>>> going forward, especially in Micro Services/Docker model does it make >>>>>> scene? >>>>>> >>>>>> Eg: If we bring up a new container due to high load, requests will >>>>>> still route to old continents due to the session. If we kill a container >>>>>> that is associated with some session where should the request go? >>>>>> >>>>>> We have written (I think) a session aware router for Docker. It's ok >>>>>> for external apps, but I think it defeats the purpose of >>>>>> containerization, >>>>>> due to about reasons. >>>>>> >>>>>> I think the correct way to do this in our apps is to, have >>>>>> authentication as a service. A micro service will translate the >>>>>> session-id >>>>>> to a token. App depends fully on the token. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> -- >>>>>> With regards, >>>>>> *Manu*ranga Perera. >>>>>> >>>>>> phone : 071 7 70 20 50 >>>>>> mail : [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Imesh Gunaratne* >>>>> Senior Technical Lead >>>>> WSO2 Inc: http://wso2.com >>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>> W: http://imesh.io >>>>> Lean . Enterprise . Middleware >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **[email protected]* <[email protected]> >>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: **http://twitter.com/afkham_azeez* >>>> <http://twitter.com/afkham_azeez> >>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : [email protected] >>> >> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ > email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) > x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 > blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **[email protected]* <[email protected]> * cell: +94 77 3320919blog: **http://blog.afkham.org* <http://blog.afkham.org> *twitter: **http://twitter.com/afkham_azeez* <http://twitter.com/afkham_azeez> *linked-in: **http://lk.linkedin.com/in/afkhamazeez <http://lk.linkedin.com/in/afkhamazeez>* *Lean . Enterprise . Middleware*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
