Thanks Chris .. now I got a clear picture. First off I will try without cluster. If that does not work, I will go for clustering.
Regards. On Tue, Jan 28, 2014 at 3:42 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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 > >
