You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Raquib Hasan <ha...@gmail.com> on 2014/01/28 16:03:34 UTC
Clustering without Apache in the front
Hello,
I am creating a tomcat cluster following helps I found online. My question
is, do I have to use the Apache(mod_jk) for session replication? Is it
possible to use F5 load balancer directly bypassing the Apache? Primary
purpose of the cluster is fail over. Load balancing is not needed. I think
session replication is needed for a successful fail over. I am thinking
like, there would be a LB VIP that the client requests would be
communicating with. The sticky session would be enabled in the LB and there
is no need of apache web server in between. Is this the right way of
thinking?
I could not find the answer any where. Every example I found online starts
with an apache web server.
I appreciate your response.
Thank you.
RH
Re: Clustering without Apache in the front
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Jan 29, 2014 at 10:24 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> > Now, as Chris pointed out - it would be great to design your app
> > that it saves the intermediate work to a database or some secondary
> > store that can be retrieved upon login again. Think "shopping
> > cart", you are shopping around, the instance goes down, you need to
> > login again, and a nice application would persist shopping cart for
> > you, not so nice application would not, so when logged in again -
> > the shopping cart would be available or not :)
>
> Exactly. Our strategy - for those interested - is to include enough
> information in each request / form to allow users whose work is
> interrupted by a login to resume their workflow (in progress) after an
> interrupted session. This has the added benefit of allowing users to
> go get a cup of coffee, have their session expire, and pick-up where
> they left-off after a quick re-login.
+1 just experienced this in an (on-the-job) online training that I'm
completing.
I started an online training 'session' (in a single browser) hours ago,
started multitasking on-the-job, go back to the online training, and scroll
down (via wheel on my mouse) a little and read the page, multitask, come
back to online training, scroll down (via wheel on my mouse) more and do
some more reading, and later after more multitasking, the session was
closed (maybe via AJAX), and I have a 404 error in the browser.
So, i close the browser, click the URL to begin/resume the online training,
and the online training opens in the browser to the very exact position on
the page that I was last reading. Now, that is real nice!
I don't know what they are doing, but they may have some AJAX method on the
client that updates database on server, and database update includes what
part/position of the page I last read.
Re: Clustering without Apache in the front
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Neven,
On 1/28/14, 8:59 PM, Neven Cvetkovic wrote:
> Ultimately, session stickiness works great to handle load
> balancing (workload management), but it is not enough for session
> failover.
Correct: session stickiness just avoids the problem of session
fail-over. If you want "proper" session fail-over, you'll need
clustering (in some form... Tomcat's clustering isn't the only game in
town of course).
> In the unlikely event that the serving tomcat instance dies, the
> user will be sent over to the other tomcat instance (that doesn't
> know anything about you, i.e. doesn't have your session data), and
> will probably need to login again.
Correct.
> Now, as Chris pointed out - it would be great to design your app
> that it saves the intermediate work to a database or some secondary
> store that can be retrieved upon login again. Think "shopping
> cart", you are shopping around, the instance goes down, you need to
> login again, and a nice application would persist shopping cart for
> you, not so nice application would not, so when logged in again -
> the shopping cart would be available or not :)
Exactly. Our strategy - for those interested - is to include enough
information in each request / form to allow users whose work is
interrupted by a login to resume their workflow (in progress) after an
interrupted session. This has the added benefit of allowing users to
go get a cup of coffee, have their session expire, and pick-up where
they left-off after a quick re-login.
> Now, if your end users can live with that scenario - that's great -
> no need for session replication, clustering your instances,
> network chatter, etc... It definitely simplifies the configuration
> and setup.
If a re-login meant starting-over at a user's "home page" and having
to re-start various workflows, it would be much more important for
sessions not to fail, and clustering would be more attractive.
Clustering is (from my outside perspective) fraught with performance
and stability issues -- not because the code is bad, but because the
entire strategy is resource-consuming and fragile somewhat by design.
> However, if your end users (i.e. your Service-Level-Agreement /
> SLA) do require a proper session failover, you will need some sort
> of session replication to successfully implement that feature.
> That's not trivial and depends on the appserver (e.g. Tomcat,
> JBoss, WebSphere, Weblogic). Session replication is not part of the
> official JEE/Servlet spec, but most modern and serious appservers
> would provide some way of replicating sessions and clustering
> appserver instances.
On a side-note, one of the things I'm most-often asked is if a new
login from a "second" (or third, etc.) client can immediately-expire
any pre-existing sessions from the same user. This is a pain in the
neck that I haven't put much thought into, yet. With multiple back-end
servers, it basically means that you need to re-authenticate the
validity of a session with a central authority on every request. *sigh*
> Now, if you could make you application stateless - you could
> possibly turn off the sticky sessions. Makes things very easy to
> scale!
+1000
>
> :))
>
>> the only time I really need failover is when I 'might' want to
>> update the app's software. the app is quite stable now and not
>> many software changes right now, so again, there's not much of a
>> need for failover. :)
There's additional difficulty, here, especially if your application
changes radically: if you change the behavior of the web application
so much that two versions can't reasonably run next to each other
simultaneously, you'll require downtime.
We do this to ourselves at $work all the time by making structural
changes to our database that basically make it impossible to run
version X and X+1 simultaneously. The obvious approach is to much more
carefully make changes, spread the affects over more than a single
release, etc. but it turns out that 30 minutes of downtime once per
quarter for new releases just isn't that big of a deal for us, so we
don't bother to spend all those additional resources to make it happen.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS6R0kAAoJEBzwKT+lPKRYKmQP/RWhnKWRYV0gksTSDdzQyf9f
t80TJMTk1F5sHlDBKjAxaG9EIVf8loJ7LILaKcwm1jHLjfn2CrQJKr7h0wRwJPH1
NbFaRUv4Y5KGa63ZEQQtlYYRmZxVPfLL2V1jA/g0PgOHvTWV5xoUtARryqFSZcQG
+kqOLeujPcNDtepqFNNRB0JGx0H7fNwEW/sobrIbramRieo834BsOkF7qkpEmCG1
pl2cTbTtk8O9oxz9FXXYHf5x6luXx1j2GY9Htk/ZErKveUU24oYPi99zkSfb+EeM
b7ufb6N2EfLs88mTOgRtbH+9BYJUcJ5s9i28oeMQ7bhq3a1asJz6gWllwfJSXAvJ
d4qu8NUNRe4C/CQ7XQlUhxfGdeDZZkm4q3iLLQomFWD1NdrZMawbZyRw5+BMZhgQ
rD0mT6vPawNUbQM4RGF0vDVK11Yuztgd0RAO8g7GGVO63qrCM1/olSo5OZPO2fbm
GICNYL0SbU3jQ8C6rud26uB1NCMEjE4i4LP1nRJ3iOa50A0wJcQayPJ/vf4ie21z
9ywlV1Y4QkHqUT5gTN95XnKoecO4vKKHot/s8LTsClXgU1jygL0+EfvIqWnOIYoo
e6K3IRA878B7rSKtyV2c/3CJi50KRq1LvYcLsoMKzaMIeFSOZfpcYWzD45G9/Yyk
BqgeQJd/tV6VMyOErKlK
=JlWo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Clustering without Apache in the front
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Tue, Jan 28, 2014 at 8:59 PM, Neven Cvetkovic
<ne...@gmail.com>wrote:
> On Tue, Jan 28, 2014 at 3:54 PM, Howard W. Smith, Jr. <
> smithh032772@gmail.com> wrote:
>
> > > Thus I will probably never have to use clustering.
> >
> > Loving your responses on this topic, Chris. I do not want to hijack this
> > thread, but i find this topic interesting, and your responses make it
> more
> > interesting!
> >
> >
> +1. Great discussion, as always :)
>
>
> > Honestly, I don't need clustering (yet) in my app, but I feel as though
> > endusers of my app will be fine in a failover situation (as you described
> > in this thread). Endusers of my app have to login a lot since I set
> session
> > expired = 15 minutes. no complaints from the endusers, because they are
> in
> > and out of the app...all day, (almost) every day.
> >
>
> Ultimately, session stickiness works great to handle load balancing
> (workload management), but it is not enough for session failover. In the
> unlikely event that the serving tomcat instance dies, the user will be sent
> over to the other tomcat instance (that doesn't know anything about you,
> i.e. doesn't have your session data), and will probably need to login
> again. Now, as Chris pointed out - it would be great to design your app
> that it saves the intermediate work to a database or some secondary store
> that can be retrieved upon login again. Think "shopping cart", you are
> shopping around, the instance goes down, you need to login again, and a
> nice application would persist shopping cart for you, not so nice
> application would not, so when logged in again - the shopping cart would be
> available or not :)
>
+1 (000,000,000,...)
wow, thanks Neven. That was a great thought/analogy right there. As someone
that uses amazon.com quite often, I do like the shopping cart feature, even
though I have not recognized if my shopping cart was saved across
sessions... oh, but you just jogged my memory, and a product that I looked
at recently, amazon.com sent that product (and similar products) to my
email... so evidently, 'interests' are persisted per user/session.
'not so nice application would not'... wow, i definitely accept that as
constructive criticism. thanks.
> Now, if your end users can live with that scenario - that's great - no need
> for session replication, clustering your instances, network chatter, etc...
> It definitely simplifies the configuration and setup.
>
> However, if your end users (i.e. your Service-Level-Agreement / SLA) do
> require a proper session failover, you will need some sort of session
> replication to successfully implement that feature. That's not trivial and
> depends on the appserver (e.g. Tomcat, JBoss, WebSphere, Weblogic). Session
> replication is not part of the official JEE/Servlet spec, but most modern
> and serious appservers would provide some way of replicating sessions and
> clustering appserver instances.
>
+1 definitely here for tomcat (a serious appserver). :)
>
> Now, if you could make you application stateless - you could possibly turn
> off the sticky sessions. Makes things very easy to scale!
>
+1 thanks. even though my app is Java Server Faces app, I would say it is
quite stateless in nature/design, since users accomplish majority of their
daily tasks via one-page requests. of course,
1. one page is required to login
2. another/one page is required to search/filter/navigate-to target data
that already exists in the database
3. another/one page is required to add/update data, or to take some action
against that data (print data/form, email data/form to customer, etc...)
and this is normal user activity; some users let their session expire after
completing steps 1 and 2 above, or steps 1, 2, and 3 above.
In reference to the shopping cart suggestion, I would assume that you would
suggest that steps 2 and 3, above, are persisted, so users can resume
previous session.
> :))
>
> the only time I really need failover is when I 'might' want to update the
> > app's software. the app is quite stable now and not many software changes
> > right now, so again, there's not much of a need for failover. :)
> >
>
> Excellent! Keep it simple!
>
+1 thanks; that's my goal...keep it simple (for the endusers). :)
> Good luck!
> Neven
>
Re: Clustering without Apache in the front
Posted by Neven Cvetkovic <ne...@gmail.com>.
On Tue, Jan 28, 2014 at 3:54 PM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> > Thus I will probably never have to use clustering.
>
> Loving your responses on this topic, Chris. I do not want to hijack this
> thread, but i find this topic interesting, and your responses make it more
> interesting!
>
>
+1. Great discussion, as always :)
> Honestly, I don't need clustering (yet) in my app, but I feel as though
> endusers of my app will be fine in a failover situation (as you described
> in this thread). Endusers of my app have to login a lot since I set session
> expired = 15 minutes. no complaints from the endusers, because they are in
> and out of the app...all day, (almost) every day.
>
Ultimately, session stickiness works great to handle load balancing
(workload management), but it is not enough for session failover. In the
unlikely event that the serving tomcat instance dies, the user will be sent
over to the other tomcat instance (that doesn't know anything about you,
i.e. doesn't have your session data), and will probably need to login
again. Now, as Chris pointed out - it would be great to design your app
that it saves the intermediate work to a database or some secondary store
that can be retrieved upon login again. Think "shopping cart", you are
shopping around, the instance goes down, you need to login again, and a
nice application would persist shopping cart for you, not so nice
application would not, so when logged in again - the shopping cart would be
available or not :)
Now, if your end users can live with that scenario - that's great - no need
for session replication, clustering your instances, network chatter, etc...
It definitely simplifies the configuration and setup.
However, if your end users (i.e. your Service-Level-Agreement / SLA) do
require a proper session failover, you will need some sort of session
replication to successfully implement that feature. That's not trivial and
depends on the appserver (e.g. Tomcat, JBoss, WebSphere, Weblogic). Session
replication is not part of the official JEE/Servlet spec, but most modern
and serious appservers would provide some way of replicating sessions and
clustering appserver instances.
Now, if you could make you application stateless - you could possibly turn
off the sticky sessions. Makes things very easy to scale!
:))
the only time I really need failover is when I 'might' want to update the
> app's software. the app is quite stable now and not many software changes
> right now, so again, there's not much of a need for failover. :)
>
Excellent! Keep it simple!
Good luck!
Neven
Re: Clustering without Apache in the front
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Tue, Jan 28, 2014 at 3:42 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> Thus I will probably never have to use clustering.
Loving your responses on this topic, Chris. I do not want to hijack this
thread, but i find this topic interesting, and your responses make it more
interesting!
Honestly, I don't need clustering (yet) in my app, but I feel as though
endusers of my app will be fine in a failover situation (as you described
in this thread). Endusers of my app have to login a lot since I set session
expired = 15 minutes. no complaints from the endusers, because they are in
and out of the app...all day, (almost) every day.
the only time I really need failover is when I 'might' want to update the
app's software. the app is quite stable now and not many software changes
right now, so again, there's not much of a need for failover. :)
still listening in on this topic. :)
Re: Clustering without Apache in the front
Posted by Raquib Hasan <ha...@gmail.com>.
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 <
chris@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 <
> > chris@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Clustering without Apache in the front
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Clustering without Apache in the front
Posted by Raquib Hasan <ha...@gmail.com>.
Chris,
Do you mean, if just the sticky session is used, tomcat clustering won't be
needed?
Thanks,
Raquib Hasan
On Tue, Jan 28, 2014 at 12:37 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJS5+rxAAoJEBzwKT+lPKRYMqIP/3ekCp19upctE7XhZCu5/eca
> 5DZkTqzVtBoX2twnnRAwd9CN8X2aTAo26Lg9H+KtVeykGyKx4tseycWzq/4mR1Dq
> g4v8uw6SK/L7yReC84gUW55bvMxr93t4Zdy8dy6qp0L5yoEVlFEEbSaIcOyYHuIA
> NbFef4Cv5v8JjOOqNSRiwuweXs2IVRRzDee26YrB5ASwP1wPIG6emlCCdlMLqjvo
> eKmM1Gcm6AVoiJT+iG47Tms2MXrNhk58HD6xjh4+APdzs70/419UGVEj+YeKcMBv
> 0/vu27wnZd90AECKgSwv8f0aAgkX4pveEyBf1UvvoEywZ1nEj6LLv/+1xELX/1no
> pS0/cBGcDE8ujPUpa/SsLFyVkvJPcLYTdQ5V0yMUHb7qQysduYLF5mSI30OGs+aW
> DJm0bzLU6XZhVofmDBnG6vpYQKH3BxMjLlsUzQdM2W2EP/NwmNZuILfWJ6P/Wc3d
> r6Fck7GbAD5Ycn666FpclMIZC6H7GhlsRs9TGwRh0s3RBpQm9nLIIUiUDlRNJz3c
> hOMU6FRP1COx2dNjSPATtKnT2IPKofDpWSVTrlK9PrmFG7WztMboF0dfZZFamyZD
> wTzppXEXgW+scDYbnp+Nn7O55YReQfBW4Gk3qvWIgIEG6vs7wl8LRsr1a2FODCJb
> VmOeh6a6RNIemYG4nxCJ
> =X+/W
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Clustering without Apache in the front
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS5+rxAAoJEBzwKT+lPKRYMqIP/3ekCp19upctE7XhZCu5/eca
5DZkTqzVtBoX2twnnRAwd9CN8X2aTAo26Lg9H+KtVeykGyKx4tseycWzq/4mR1Dq
g4v8uw6SK/L7yReC84gUW55bvMxr93t4Zdy8dy6qp0L5yoEVlFEEbSaIcOyYHuIA
NbFef4Cv5v8JjOOqNSRiwuweXs2IVRRzDee26YrB5ASwP1wPIG6emlCCdlMLqjvo
eKmM1Gcm6AVoiJT+iG47Tms2MXrNhk58HD6xjh4+APdzs70/419UGVEj+YeKcMBv
0/vu27wnZd90AECKgSwv8f0aAgkX4pveEyBf1UvvoEywZ1nEj6LLv/+1xELX/1no
pS0/cBGcDE8ujPUpa/SsLFyVkvJPcLYTdQ5V0yMUHb7qQysduYLF5mSI30OGs+aW
DJm0bzLU6XZhVofmDBnG6vpYQKH3BxMjLlsUzQdM2W2EP/NwmNZuILfWJ6P/Wc3d
r6Fck7GbAD5Ycn666FpclMIZC6H7GhlsRs9TGwRh0s3RBpQm9nLIIUiUDlRNJz3c
hOMU6FRP1COx2dNjSPATtKnT2IPKofDpWSVTrlK9PrmFG7WztMboF0dfZZFamyZD
wTzppXEXgW+scDYbnp+Nn7O55YReQfBW4Gk3qvWIgIEG6vs7wl8LRsr1a2FODCJb
VmOeh6a6RNIemYG4nxCJ
=X+/W
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Clustering without Apache in the front
Posted by Raquib Hasan <ha...@gmail.com>.
Thanks Chris.
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. 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. I though
cluster is the solution. Does the session replication come with the
clustering feature?
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
RH
On Tue, Jan 28, 2014 at 10:24 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Raquib,
>
> On 1/28/14, 10:03 AM, Raquib Hasan wrote:
> > I am creating a tomcat cluster following helps I found online. My
> > question is, do I have to use the Apache(mod_jk) for session
> > replication?
>
> No.
>
> > Is it possible to use F5 load balancer directly bypassing the
> > Apache?
>
> Yes. (Note this is not "bypassing" Apache [httpd]... it's simply not
> using it at all. Use of httpd is common, but certainly not required by
> any stretch.
>
> The lb is not involved in session replication.
>
> If you want to use sticky sessions, you'll need to properly configure
> the lb to understand how to "stick" the sessions to a back-end server.
>
> > Primary purpose of the cluster is fail over. Load balancing is not
> > needed. I think session replication is needed for a successful fail
> > over.
>
> That depends upon the nature of your webapp. Note that
> session-replication is time-consuming and puts certain constraints on
> the objects you store in the session.
>
> > I am thinking like, there would be a LB VIP that the client
> > requests would be communicating with. The sticky session would be
> > enabled in the LB and there is no need of apache web server in
> > between. Is this the right way of thinking?
>
> What do you mean VIP?
>
> How many back-end servers were you considering using?
>
> > I could not find the answer any where. Every example I found online
> > starts with an apache web server.
>
> Using mod_jk (or mod_proxy_ajp) just makes everything easier given the
> configuration options, etc. All of the ASF documentation covers the
> use of httpd because it's freely-available and supported by the same
> organization. The ASF isn't going to maintain configuration
> instructions for a produce sold and supported by a commercial entity.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJS58uZAAoJEBzwKT+lPKRYOrMP/AxfjLwYrr5k3ishLEjDWwlw
> uvJnXLMS1uW06XVBRqkevwRerz+4uKF8GlFPsnAcZd3h3MfPd+nhvtrSo5gXCgk3
> aF+H+UNvq1axY7gAbI1syNCT3lUb1dQ4T+tbsuKILE4/LfE2+BqaIyEEUk3dpUq0
> hi9IdaPolZdtf1Zikt5stYljqrNwY16S2mGFliICrHcpKa8rPL6TaDxIgmmhm4XV
> zpziYZBCKaUqA2qadmFzUlRJSvZXmHqjmAXd6+dsMjzyIloeRntfBiktVbEh+EZg
> WlXvoIaU6m3AEpK9c+A0QeCi1i8J5uMvGFAHbBp7+9XttZZdAfKwEr4jGRSvfnk4
> nBaPFkEZZimmvh+i68bcysIPjVQVYzG2UHFsgTkie0SYhV1P8u6R7ugYGav9Uu2R
> WfMLJm9V+0r3mAgR/aD4B4VQ7JYEavQ4YAldBQeb2IRqygBB2DCTawyIiHm3RiJ5
> e7I0P2EXBjYhOZaQSQ0oWnLyF8JzGTIPy2B5b+qIHWYNBdV94/yvvBUp4iZhLEc7
> NYgfhBczcRBlsmhvqVUcRrnyHdmf/sfgaZsiEs6zuTVrbZUoPKxoJJ6BmkhcMRbh
> EgT2iMFL56IIRGKS2Is92vxoLV1Y/Kl5DYDceWw1qgveqZr2rPWfsNEP43RssM36
> pDdpqUCFLJ1PD24FHaL8
> =OKXz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Clustering without Apache in the front
Posted by Raquib Hasan <ha...@gmail.com>.
:)
On Tue, Jan 28, 2014 at 11:28 AM, André Warnier <aw...@ice-sa.com> wrote:
> Christopher Schultz wrote:
> ...
>
> I am thinking like, there would be a LB VIP that the client
>>> requests would be communicating with. The sticky session would be
>>> enabled in the LB and there is no need of apache web server in
>>> between. Is this the right way of thinking?
>>>
>>
>> What do you mean VIP?
>>
>>
> A very big, very expensive, gold-plated load balancer ?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Clustering without Apache in the front
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
...
>> I am thinking like, there would be a LB VIP that the client
>> requests would be communicating with. The sticky session would be
>> enabled in the LB and there is no need of apache web server in
>> between. Is this the right way of thinking?
>
> What do you mean VIP?
>
A very big, very expensive, gold-plated load balancer ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Clustering without Apache in the front
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Raquib,
On 1/28/14, 10:03 AM, Raquib Hasan wrote:
> I am creating a tomcat cluster following helps I found online. My
> question is, do I have to use the Apache(mod_jk) for session
> replication?
No.
> Is it possible to use F5 load balancer directly bypassing the
> Apache?
Yes. (Note this is not "bypassing" Apache [httpd]... it's simply not
using it at all. Use of httpd is common, but certainly not required by
any stretch.
The lb is not involved in session replication.
If you want to use sticky sessions, you'll need to properly configure
the lb to understand how to "stick" the sessions to a back-end server.
> Primary purpose of the cluster is fail over. Load balancing is not
> needed. I think session replication is needed for a successful fail
> over.
That depends upon the nature of your webapp. Note that
session-replication is time-consuming and puts certain constraints on
the objects you store in the session.
> I am thinking like, there would be a LB VIP that the client
> requests would be communicating with. The sticky session would be
> enabled in the LB and there is no need of apache web server in
> between. Is this the right way of thinking?
What do you mean VIP?
How many back-end servers were you considering using?
> I could not find the answer any where. Every example I found online
> starts with an apache web server.
Using mod_jk (or mod_proxy_ajp) just makes everything easier given the
configuration options, etc. All of the ASF documentation covers the
use of httpd because it's freely-available and supported by the same
organization. The ASF isn't going to maintain configuration
instructions for a produce sold and supported by a commercial entity.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS58uZAAoJEBzwKT+lPKRYOrMP/AxfjLwYrr5k3ishLEjDWwlw
uvJnXLMS1uW06XVBRqkevwRerz+4uKF8GlFPsnAcZd3h3MfPd+nhvtrSo5gXCgk3
aF+H+UNvq1axY7gAbI1syNCT3lUb1dQ4T+tbsuKILE4/LfE2+BqaIyEEUk3dpUq0
hi9IdaPolZdtf1Zikt5stYljqrNwY16S2mGFliICrHcpKa8rPL6TaDxIgmmhm4XV
zpziYZBCKaUqA2qadmFzUlRJSvZXmHqjmAXd6+dsMjzyIloeRntfBiktVbEh+EZg
WlXvoIaU6m3AEpK9c+A0QeCi1i8J5uMvGFAHbBp7+9XttZZdAfKwEr4jGRSvfnk4
nBaPFkEZZimmvh+i68bcysIPjVQVYzG2UHFsgTkie0SYhV1P8u6R7ugYGav9Uu2R
WfMLJm9V+0r3mAgR/aD4B4VQ7JYEavQ4YAldBQeb2IRqygBB2DCTawyIiHm3RiJ5
e7I0P2EXBjYhOZaQSQ0oWnLyF8JzGTIPy2B5b+qIHWYNBdV94/yvvBUp4iZhLEc7
NYgfhBczcRBlsmhvqVUcRrnyHdmf/sfgaZsiEs6zuTVrbZUoPKxoJJ6BmkhcMRbh
EgT2iMFL56IIRGKS2Is92vxoLV1Y/Kl5DYDceWw1qgveqZr2rPWfsNEP43RssM36
pDdpqUCFLJ1PD24FHaL8
=OKXz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org