You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by lightbulb432 <ve...@hotmail.com> on 2007/08/24 22:51:05 UTC
[OT] Session replication vs stateless
Although the debate between session replication vs stateless can't be
definitively solved and depends on the application, I'd like to hear about
your experiences with both. How are you designing your current applications,
and what implications has the choice that you might not have expected -
would you do anything differently if you could?
I ask because I'm still unsure about whether to decrease memory usage by
increasing database usage (or bandwidth usage if sending state back to the
client) by going stateless at the application tier.
Stateless
Are there any people using stateless application tiers with transactions
that are inherently stateful, such as wizard-type screens or other business
processes or workflows? How'd that turn out?
Did you choose to move this state to the client (through cookies) or to the
database?
Session replication
For session replication in Tomcat 6, what's the ideal replication group size
in general? Would you ever want to set it to more than 2 instances? (Because
for any more, then you'd have a lot more overhead in transferring state back
and forth to even more other instances...)
With session replication between 2 machines, are you effectively reducing
the capacity of each server, at least in terms of memory, by 50%? Hopefully
I'm looking at it the wrong way, because it not, I'm not really liking the
session replication idea if I'm decreasing hardware usage by half.
Thanks.
--
View this message in context: http://www.nabble.com/-OT--Session-replication-vs-stateless-tf4325727.html#a12319704
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I'd go the opposite direction, I will do stateless before attempting any
kind of replication or distributed cache.
The scalability of a stateless application will outscale any replicated
app any day, since your fail over options are so much more simplified.
Filip
Dwayne wrote:
> Have you considered distributed caching for session replication? I avoid
> stateless like the plague.
>
> There are several tools out there for this, but my favorite (because they
> are open source) is Terracotta. It clusters the JVMs.
> Native clustering in Tomcat putters out, in my experience, after 3 nodes.
> With Terracotta, I dropped in the code and now am clustering 5 nodes and
> getting a lot higher TPS.
> I think it is worth the hour it took me to implement it and I didn't have to
> change my code at all, just write a short XML and drop some tags around what
> I wanted to distribute.
> Get it at terracotta.org. The support docs do not say they support Tomcat 6
> yet, but I have yet to hit any bugs (3 weeks in).
>
>
> On 8/24/07, lightbulb432 <ve...@hotmail.com> wrote:
>
>> Although the debate between session replication vs stateless can't be
>> definitively solved and depends on the application, I'd like to hear about
>> your experiences with both. How are you designing your current
>> applications,
>> and what implications has the choice that you might not have expected -
>> would you do anything differently if you could?
>>
>> I ask because I'm still unsure about whether to decrease memory usage by
>> increasing database usage (or bandwidth usage if sending state back to the
>> client) by going stateless at the application tier.
>>
>> Stateless
>>
>> Are there any people using stateless application tiers with transactions
>> that are inherently stateful, such as wizard-type screens or other
>> business
>> processes or workflows? How'd that turn out?
>>
>> Did you choose to move this state to the client (through cookies) or to
>> the
>> database?
>>
>> Session replication
>>
>> For session replication in Tomcat 6, what's the ideal replication group
>> size
>> in general? Would you ever want to set it to more than 2 instances?
>> (Because
>> for any more, then you'd have a lot more overhead in transferring state
>> back
>> and forth to even more other instances...)
>>
>> With session replication between 2 machines, are you effectively reducing
>> the capacity of each server, at least in terms of memory, by 50%?
>> Hopefully
>> I'm looking at it the wrong way, because it not, I'm not really liking the
>> session replication idea if I'm decreasing hardware usage by half.
>>
>> Thanks.
>> --
>> View this message in context:
>> http://www.nabble.com/-OT--Session-replication-vs-stateless-tf4325727.html#a12319704
>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.484 / Virus Database: 269.12.4/969 - Release Date: 8/23/2007 4:04 PM
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by Dwayne <dw...@gmail.com>.
Have you considered distributed caching for session replication? I avoid
stateless like the plague.
There are several tools out there for this, but my favorite (because they
are open source) is Terracotta. It clusters the JVMs.
Native clustering in Tomcat putters out, in my experience, after 3 nodes.
With Terracotta, I dropped in the code and now am clustering 5 nodes and
getting a lot higher TPS.
I think it is worth the hour it took me to implement it and I didn't have to
change my code at all, just write a short XML and drop some tags around what
I wanted to distribute.
Get it at terracotta.org. The support docs do not say they support Tomcat 6
yet, but I have yet to hit any bugs (3 weeks in).
On 8/24/07, lightbulb432 <ve...@hotmail.com> wrote:
>
>
> Although the debate between session replication vs stateless can't be
> definitively solved and depends on the application, I'd like to hear about
> your experiences with both. How are you designing your current
> applications,
> and what implications has the choice that you might not have expected -
> would you do anything differently if you could?
>
> I ask because I'm still unsure about whether to decrease memory usage by
> increasing database usage (or bandwidth usage if sending state back to the
> client) by going stateless at the application tier.
>
> Stateless
>
> Are there any people using stateless application tiers with transactions
> that are inherently stateful, such as wizard-type screens or other
> business
> processes or workflows? How'd that turn out?
>
> Did you choose to move this state to the client (through cookies) or to
> the
> database?
>
> Session replication
>
> For session replication in Tomcat 6, what's the ideal replication group
> size
> in general? Would you ever want to set it to more than 2 instances?
> (Because
> for any more, then you'd have a lot more overhead in transferring state
> back
> and forth to even more other instances...)
>
> With session replication between 2 machines, are you effectively reducing
> the capacity of each server, at least in terms of memory, by 50%?
> Hopefully
> I'm looking at it the wrong way, because it not, I'm not really liking the
> session replication idea if I'm decreasing hardware usage by half.
>
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/-OT--Session-replication-vs-stateless-tf4325727.html#a12319704
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Session replication vs stateless
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lb,
lightbulb432 wrote:
>
>> Don't forget that you can't be stateless if you
>> need logins of some type (unless you use BASIC auth, which looks ugly
>> from a user point of view).
>
> Why is this? Others who answered to this thread and discussions in general
> around web applications describe statelessness as an option for
> fully-functional webapps, which I imagine includes login functionality.
Well, Tomcat must keep authentication information somewhere in memory
after you login, even if it doesn't use a session to manage it (which
I'm sure it does, though I think the auth information is not stored /in/
the session, but rather associated with it in some other way).
If you aren't replicating sessions between Tomcat instances, you can't
switch instances without logging-in again.
>> I'm not convinced you can reasonably do authenticated transactions
>> (using Tomcat's auth) without stateful connections. You can hack around
>> with storing login cookies or doing your own auth management, but I like
>> the simplicity of using J2EE auth.
>
> Could you describe the limitations of statelessness as it relates to
> Tomcat's authorization?
See above.
> If you use your own custom login functionality then
> I see how there's no problem (just check the cookie or database for the
> current session ID for the right credentials, then allow access)
Actually, this might not be possible if you're trying to use session
information (without a few hacks). Since Tomcat will respond to an
invalid session id request by creating a new session (new id), switching
instances will result in the old session cookie being replaced by the
new one. You will end up constantly re-writing the session id in the
database you use to maintain login information.
> but is the
> same mechanism not possible or available when trying to use the Tomcat or
> standard Servlet authentication mechanism?
Unless you write your own Realm, I don't think this is possible.
> What's Tomcat's algorithm for load-balancing while taking into account
> session affinity?
I don't believe that Tomcat does any load balancing at all. Also, with
session affinity, there's no balancing going on once you are assigned to
a server (unless that one goes down).
For info on lb algorithms, you'd need to look at your load balancer. I
believe that mod_jk can be configured to use one of several types,
including an estimated "load" to try and route new visitors to the
more-idle members in the cluster.
> I remember in the response to another of my threads on this list people
> saying that it's generally outdated to use connectors and front Tomcat with
> Apache. I just want to confirm that it's the connector mechanism by which
> load balancing is possible with Tomcat, right?
Well, it's one way. You can certainly use a hardware load balancer, too,
which is probably better in the long run.
> On what machine is the connector software usually on?
It's always on the web server.
> If you have 5 machines
> with Tomcat on each, would you have the load balancer on one of those, on a
> dedicated machine, or would you have some other setup? What's generally done
> in production for high-availability sites?
It's really up to you and the requirements of your software. Some
applications can actually run within the DMZ and so it doesn't matter if
you run, say, Apache httpd on one of the app servers along with Tomcat.
Or, you could even run it on all of them.
Most often, you'll see that the web servers live in the DMZ and are
directly accessible from the Internet, while the application servers
live on a private subnet in the back, and can only be accessed from
within the DMZ or that private subnet.
The lbs can be anywhere, but generally sit way out at the front, and are
the only things accessible from the Internet.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1EL99CaO5/Lv0PARAj9lAKChBbFkMRLdSfO4x2xXFFFxY88t4QCgm7gc
cjQWB4jdTbFTdSvbDpaUy44=
=hlNZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by lightbulb432 <ve...@hotmail.com>.
That sounds about right. Don't forget that you can't be stateless if you
> need logins of some type (unless you use BASIC auth, which looks ugly
> from a user point of view).
Why is this? Others who answered to this thread and discussions in general
around web applications describe statelessness as an option for
fully-functional webapps, which I imagine includes login functionality.
I'm not convinced you can reasonably do authenticated transactions
> (using Tomcat's auth) without stateful connections. You can hack around
> with storing login cookies or doing your own auth management, but I like
> the simplicity of using J2EE auth.
Could you describe the limitations of statelessness as it relates to
Tomcat's authorization? If you use your own custom login functionality then
I see how there's no problem (just check the cookie or database for the
current session ID for the right credentials, then allow access), but is the
same mechanism not possible or available when trying to use the Tomcat or
standard Servlet authentication mechanism?
Pretty much nothing, unless you get lots of people who login and then
> walk away from their computers, and for some reason all of the
> walk-aways get assigned to one server, while all the other (active)
> users end up on another server. Then, you'd have one server with lots of
> load and one that's basically idle. This is unlikely, though.
What's Tomcat's algorithm for load-balancing while taking into account
session affinity?
I remember in the response to another of my threads on this list people
saying that it's generally outdated to use connectors and front Tomcat with
Apache. I just want to confirm that it's the connector mechanism by which
load balancing is possible with Tomcat, right?
On what machine is the connector software usually on? If you have 5 machines
with Tomcat on each, would you have the load balancer on one of those, on a
dedicated machine, or would you have some other setup? What's generally done
in production for high-availability sites?
--
View this message in context: http://www.nabble.com/-OT--Session-replication-vs-stateless-tf4325727.html#a12369222
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lb,
lightbulb432 wrote:
> Let me see if I have my options straight - stateless app tier and no session
> affinity, or stateful app tier (i.e. HttpSessions) with session affinity?
That sounds about right. Don't forget that you can't be stateless if you
need logins of some type (unless you use BASIC auth, which looks ugly
from a user point of view).
> The former allows you to forward the next request to any available web
> server because of no session affinity and to have failure without relogin,
> both of which seem like huge pluses. However, the downside is having to
> maintain that state elsewhere - either in the database (which as you pointed
> out is messy) or being sent back and forth to the client. Which of these
> options seems better at first glance to you?
I'm not convinced you can reasonably do authenticated transactions
(using Tomcat's auth) without stateful connections. You can hack around
with storing login cookies or doing your own auth management, but I like
the simplicity of using J2EE auth.
> If I were to go with a stateful app tier (i.e. HttpSession with session
> affinity but no session replication), what's the overhead of session
> affinity?
Pretty much nothing, unless you get lots of people who login and then
walk away from their computers, and for some reason all of the
walk-aways get assigned to one server, while all the other (active)
users end up on another server. Then, you'd have one server with lots of
load and one that's basically idle. This is unlikely, though.
> I realize that if there's no requirement for failure without
> relogin then this option could be better, but from a pure performance
> perspective, how big is the overhead caused by session affinity having to be
> resolved upon every request?
I would assert that it's immeasurably small. It takes more time to parse
the context name and do JkMount evaluation than it does to figure out
which server to choose from the cluster.
> Is there ever a benefit, from a Tomcat perspective or other, to having a
> stateless app tier but WITH session affinity, or would that be completely
> useless?
It sounds useless, but I'm sure there's a reason to do it. I guess you
could have an app that is strictly stateless, but can benefit from a
session nonetheless. For instance, let's say you have a search app. You
might want to cache the results of the search in the session for paging
purposes to improve performance. If you get bounced to another server,
you can always reconstruct the search from the information in the
request instead of using a cached copy, so it's strictly stateless, but
you also get a benefit from some kind of state.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG0z309CaO5/Lv0PARAieCAKCtEXwBpWTSCxMX5I9G1LoHUhJlWQCfdf1J
B3NgNH++vwleqVFfC0+R9/Q=
=MnEh
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by lightbulb432 <ve...@hotmail.com>.
Thanks for your response. So it sounds like session replication is out for
sure - you confirmed my initial feelings about it.
Let me see if I have my options straight - stateless app tier and no session
affinity, or stateful app tier (i.e. HttpSessions) with session affinity?
The former allows you to forward the next request to any available web
server because of no session affinity and to have failure without relogin,
both of which seem like huge pluses. However, the downside is having to
maintain that state elsewhere - either in the database (which as you pointed
out is messy) or being sent back and forth to the client. Which of these
options seems better at first glance to you?
If I were to go with a stateful app tier (i.e. HttpSession with session
affinity but no session replication), what's the overhead of session
affinity? I realize that if there's no requirement for failure without
relogin then this option could be better, but from a pure performance
perspective, how big is the overhead caused by session affinity having to be
resolved upon every request?
Is there ever a benefit, from a Tomcat perspective or other, to having a
stateless app tier but WITH session affinity, or would that be completely
useless?
Christopher Schultz-2 wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lightbulb,
>
> lightbulb432 wrote:
>> How are you designing your current applications, and what
>> implications has the choice that you might not have expected - would
>> you do anything differently if you could?
>
> (For the record, I am not using session replication.)
>
> It all comes down to what is most important for your application.
>
> If it is unacceptable to have users re-login if the server to which
> their session is tied (session affinity: no replication), then session
> replication is one of your only options.
>
> If it's okay to have users re-login when they switch servers due to
> failover, I'd highly recommend it since session replication is pretty
> heavy in terms of network use. Why waste all that time passing session
> information around?
>
>> I ask because I'm still unsure about whether to decrease memory usage
>> by increasing database usage (or bandwidth usage if sending state
>> back to the client) by going stateless at the application tier.
>
> You don't necessarily have to go stateless. Using a session is fins as
> long as it's okay for users to re-login when they switch servers.
>
>> Stateless
>>
>> Are there any people using stateless application tiers with
>> transactions that are inherently stateful, such as wizard-type
>> screens or other business processes or workflows? How'd that turn
>> out?
>
> I have some flows that are sort-of stateless (that is, I have lots of
> hidden <input> elements on those pages). I use those for when I want the
> wizard to be able to continue in the middle if the session times out
> when a user is halfway through the flow. Yes, the user has to login
> again, but they pick-up the flow where they left off.
>
>> Did you choose to move this state to the client (through cookies) or
>> to the database?
>
> I don't like using the database for scratch work. First of all, it ties
> up valuable database resources. Second, it pollutes your schema with
> what amounts to temporary data. Lastly, you have to clean up after that
> scratch data at some point so you don't fill up your database with
> useless junk. I think it's easier to simply allow aborted "transactions"
> (meaning multi-page flows) to die along with the session under which
> they were running.
>
>> With session replication between 2 machines, are you effectively
>> reducing the capacity of each server, at least in terms of memory, by
>> 50%?
>
> No. You're only reducing the amount of memory available "for sessions"
> by half. You can help yourself out a lot by using objects with transient
> fields so you don't transmit huge objects across the network and waste
> memory on a server that might not get used. Instead, use lazy
> instantiation to reconstitute those objects from the database (or
> wherever) when they are needed. Only replicate what is absolutely
> necessary to recover your state. (This only works well when you are also
> using session affinity).
>
>> Hopefully I'm looking at it the wrong way, because it not, I'm not
>> really liking the session replication idea if I'm decreasing hardware
>> usage by half.
>
> I'd have to say that I would rarely recommend session replication just
> because the memory, CPU, and network overhead doesn't outweigh the minor
> (and hopefully rare) inconvenience of having to re-login when you switch
> servers.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGz0z39CaO5/Lv0PARAr9OAKCiB/sk56z7e4kBkPoqHL7QI8wv+ACeO9AA
> rsWsRUE4t5JhIbB+dSyS9kg=
> =Wypn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/-OT--Session-replication-vs-stateless-tf4325727.html#a12356782
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lightbulb,
lightbulb432 wrote:
> How are you designing your current applications, and what
> implications has the choice that you might not have expected - would
> you do anything differently if you could?
(For the record, I am not using session replication.)
It all comes down to what is most important for your application.
If it is unacceptable to have users re-login if the server to which
their session is tied (session affinity: no replication), then session
replication is one of your only options.
If it's okay to have users re-login when they switch servers due to
failover, I'd highly recommend it since session replication is pretty
heavy in terms of network use. Why waste all that time passing session
information around?
> I ask because I'm still unsure about whether to decrease memory usage
> by increasing database usage (or bandwidth usage if sending state
> back to the client) by going stateless at the application tier.
You don't necessarily have to go stateless. Using a session is fins as
long as it's okay for users to re-login when they switch servers.
> Stateless
>
> Are there any people using stateless application tiers with
> transactions that are inherently stateful, such as wizard-type
> screens or other business processes or workflows? How'd that turn
> out?
I have some flows that are sort-of stateless (that is, I have lots of
hidden <input> elements on those pages). I use those for when I want the
wizard to be able to continue in the middle if the session times out
when a user is halfway through the flow. Yes, the user has to login
again, but they pick-up the flow where they left off.
> Did you choose to move this state to the client (through cookies) or
> to the database?
I don't like using the database for scratch work. First of all, it ties
up valuable database resources. Second, it pollutes your schema with
what amounts to temporary data. Lastly, you have to clean up after that
scratch data at some point so you don't fill up your database with
useless junk. I think it's easier to simply allow aborted "transactions"
(meaning multi-page flows) to die along with the session under which
they were running.
> With session replication between 2 machines, are you effectively
> reducing the capacity of each server, at least in terms of memory, by
> 50%?
No. You're only reducing the amount of memory available "for sessions"
by half. You can help yourself out a lot by using objects with transient
fields so you don't transmit huge objects across the network and waste
memory on a server that might not get used. Instead, use lazy
instantiation to reconstitute those objects from the database (or
wherever) when they are needed. Only replicate what is absolutely
necessary to recover your state. (This only works well when you are also
using session affinity).
> Hopefully I'm looking at it the wrong way, because it not, I'm not
> really liking the session replication idea if I'm decreasing hardware
> usage by half.
I'd have to say that I would rarely recommend session replication just
because the memory, CPU, and network overhead doesn't outweigh the minor
(and hopefully rare) inconvenience of having to re-login when you switch
servers.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGz0z39CaO5/Lv0PARAr9OAKCiB/sk56z7e4kBkPoqHL7QI8wv+ACeO9AA
rsWsRUE4t5JhIbB+dSyS9kg=
=Wypn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session replication vs stateless
Posted by Rémy Maucherat <re...@gmail.com>.
On 8/24/07, lightbulb432 <ve...@hotmail.com> wrote:
> Although the debate between session replication vs stateless can't be
> definitively solved and depends on the application, I'd like to hear about
> your experiences with both. How are you designing your current applications,
> and what implications has the choice that you might not have expected -
> would you do anything differently if you could?
I would go stateless if I can, or at least stateless enough so that it
does not require replication.
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org