Thanks Richard. We're probably going to go for "session affinity" as our load-balancer is set up for that. The problem is that it won't work with the forum module will it? Not quite sure how to manage comments unless we route those specific url's through a specified public instance. I guess that is when clustering would need to be used isn't it?
>>> On 11/09/12 at 14:59, "Unger, Richard" <[email protected]> wrote: Hi Jon, Yes, I concur with Will*s answer. The moment your webapps use the session (for example, because they require login to a protected area) you need to take this into account in your system architecture. Each user request has to be associated with that user*s session on the server-side. There are 3 basic techniques for this, and as always, it*s a trade-off: 1) Use so-called *session affinity* in your load-balancer configuration. Basically, this makes sure that each user, after the initial request, always gets to speak to the same application-server, for all future requests. This ensures that the user can always be reconnected to his session, since he always talks to the same tomcat. There are different techniques for achieving this depending on the load-balancer you are using. Some solutions use cookies, some use features of the request like client-IP, and some maintain internal tables to manage the associations. The ability to handle requests with *session affinity* should be a feature of any load-balancer solution, it*s a very common need. Advantages of this solution include that it is simple to set up, does not require any modification of either app-servers or the application, and generally does not impact performance. Disadvantages include the fact that if an app-server dies or is taken down for maintainance, all active sessions of that app-server are lost, and users who were connected to that app-server have to log in again, and restart whatever they were doing in a new session on the other app-server. Also, having session affinity can *skew* your load-balancing, since the balancer is not entirely free to distribute requests as it wants. 2) Your second option is to use clustering to share the session between your application-servers. In this case, you configure the app-servers to operate together *as a cluster*. The app-servers will manage distribution of the user sessions between participating cluster nodes. In this setup it does not matter which server gets to process an incoming request * all servers have access to all the sessions. Principal advantage of this solution is true failover * you can take down an app-server, and users will simply continue working on the other cluster nodes, without missing a beat. Principal disadvantage of this solution is that it requires consideration at the app-design level * since the sessions are being exchanged (over the network) between the app-servers, any information stored in the session has to be serializable. This means you have to pay careful attention to what objects get put in the user session by your application. Also, if the sessions are large, performance will suffer since the cluster will have to do a lot of work to serialize and deserialize the sessions. 3) A third option, less commonly used in Java AFAIK, is to use shared persistent storage for the sessions. Typically a database is used to store the user sessions, and each session is loaded at the beginning of a request, and then persisted back the the DB at the end of a request. This setup has the advantage of having sessions available on each server, without having to configure clustering, which can be complicated. Principal disadvantages are probably performance, and of course in this solution sessions also need to be completely serializable as well. Personally, I*d go for #1 or #2, not #3* Regards from Vienna, Richard Von: [email protected] [mailto:[email protected]] Im Auftrag von Jon RINGWOOD PSE 55500 Gesendet: Dienstag, 11. Se ptember 2012 11:11 An: Magnolia User-List Betreff: Re: [magnolia-user] Public instances Hey Will, I meant content that users had to login to view like the members only area of the demo-project. I assume that can't be managed by clustered storage as it would be session based wouldn't it? Load balanced public instances wouldn't work in that respect surely? Jon >>> On 11/09/12 at 08:47, Will Scheidegger <[email protected]> wrote: Hi Jon I don't really know what you mean by "protected content". Isn't both the extranet and intranet "protected content" by definition? All user generated content (i.e. comments, shopping carts and so on) however must be stored in a clustered repository in order for it to work with multiple nodes. Best regards, -will On 11.09.2012, at 09:39, Jon RINGWOOD PSE 55500 wrote: I'm after a little advice, we have a standard server configuration with a single author publishing to two public instances. These public instances host our extranet and intranet and are load balanced with both subscribing to the same author content. This works well but we are starting to plan for protected content and commenting and are not sure how this would work with load-balanced public instances. I assume that it wouldn't! Does anyone use protected content and commenting on their site? If so, do you load-balance or just use a single public instance? Any advice would be most appreciated. Thanks Jon ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- This email and any other accompanying document (s) contain information from Kent Police, which is confidential or privileged. The information is intended to be for the exclusive use of the individual(s) or bodies to whom it is addressed. The content including any subsequent replies could be disclosable if relating to a criminal investigation or civil proceedings. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this email in error, please notify us immediately by contacting the sender or telephoning 01622 690690. ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
