-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Raquib,
On 1/28/14, 3:18 PM, Raquib Hasan wrote: > Do you mean, if just the sticky session is used, tomcat clustering > won't be needed? In some ways, yes, it is that simple. In other ways it is not. If you use sticky-sessions without clustering, all will well until a fail-over occurs. When a fail-over occurs, any users who were on the failed node will experience an interruption. If that's acceptable to you and your users, then there is no need (IMO) for clustering. If you cannot afford to have sessions fail during fail-over and users cannot be required to re-login, then you will have to implement clustering. I personally always try to construct my applications such that fail-over results in a resumable-situation: the user will have to re-login but otherwise the workflow is not interrupted. Thus I will probably never have to use clustering. - -chris > On Tue, Jan 28, 2014 at 12:37 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Raquib, > > On 1/28/14, 12:29 PM, Raquib Hasan wrote: >>>> I am not sure whether the sticky session is needed or not. >>>> The session replication also may not be needed. My >>>> requirement is very simple. > > If you don't need anything fancy, may I suggest that you start by > using sticky sessions and no session-replication? If you use > sessions, you'll need to use one of the two otherwise nothing will > work properly. > > Sticky-sessions are simple to configure and get you a lot of > mileage without much horsepower at all. > >>>> There are 2 back end servers. I want both gets same user >>>> communication at the same time, so that, if one server fails >>>> the other can continue. > > Assuming that you can suffer the loss of a single in-progress > request, you want to route the request to a /single/ back-end > server and not do something weird like broadcasting. If you use > sticky sessions, the same back-end server will get all of the > requests for a particular session. > > If that node fails, subsequent requests will be routed to the > other server. If you don't have session-replication enabled, the > user's session will be lost and they will have to re-login, > possibly re-starting any work in-progress. That's up to your > webapp's tolerance for fail-over to handle. > >>>> I though cluster is the solution. Does the session >>>> replication come with the clustering feature? > > Clustering ≈ session replication. Tomcat's clustering does not > provide anything other than session replication. > >>>> VIP means Virtual IP address given to client. Back-end >>>> servers can be communicated using the VIP no matter where the >>>> LB routes the requests to. > > I don't think that's necessary at all. LBs are designed to handle > sets of back-end servers and choose one of them based on a number > of criteria. You don't need to create a virtual IP that > wanders-around through your beck-end servers: the Big IP itself is > the IP address everyone will hit. > > -chris >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS6BYxAAoJEBzwKT+lPKRYkm0P/igmCiHXK2lGLMlTRT/Mp1rZ BwsH1Vzl1AR4y/twr5jnx4tLwtKjjoI/lkPwOfnWcm97POCpxCF2bOEk9pu/VLJw Px1Joyqh3LhadZkytB+u5PGWctCKuUHU48GXOUV+d0KH1N77McOyv4wGzJ8lKBDK oliQ1iGuLptL+jK3p2sjsD7s6xOKPDDG9+8mKVYb71TYuRPEdVbhvQU5DZdYhbXU RGJZVy+9XtD5WD3swNSWkbxpLs01FBmutrEQYq/zJzPjBS2Vyh1KHQgWU2ZR1BCY HZzCwt0zcx5bvM8bix6U7BqvJQ0gzMS513hS6eQ9fryuYFJQqxchYIj09+cXiEQ1 CPpb/4MT2vAIUM4uMD6/uoXi+QYemL1D4LZMXElAMObJoNob9sPKnSmicCGf2JJl t9z5mfW2JvOTib6KOM24/gnBhYbCDbBy7CeUq6G0dERdOYcledoYghlm7f6kht8n bOM3LHxat+yIEzpoyHozZb5sW9VDFCj1lSvf+6/YB12FRetunxRsRLpryVOxjLOY tpgbcbsv3/ma/PxZ2Vcx9FKnjsF7rstkOD5oQGEQg0O0YPnz+TfWVmh5f0ycmWbo +8+8aqZVsF+R12XE7Uv+FShzqZAEZrQIPO4DUvFTCSxjgh9/RpQ41InPmf+FlGen 9Z/0r0/TVoasIXSjfEu/ =oFmF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
