Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <51119157.8050207@christopherschultz.net>
Date: Tue, 05 Feb 2013 18:10:15 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [Seriously OT] Help in diagnosing server unresponsiveness
References: <CD31675F.34C73%zoran@sparecreative.com>
 <BLU0-SMTP151B7CA8D4280D2DDB02953CF1C0@phx.gbl>
 <BLU0-SMTP2470B39640025B1F6F4C101CF1C0@phx.gbl>
 <CAGV1rD+_0v_Vq4VimAVmSCyg6nWjKH39aUfFVym3Cx==8jbOWg@mail.gmail.com>
 <510C157C.2000100@christopherschultz.net>
 <CAG6aRdWX9SDK71O4+7Wu4PTBO-ofFfPso-7uz3VbrD6H5UDyMQ@mail.gmail.com>
In-Reply-To: 
 <CAG6aRdWX9SDK71O4+7Wu4PTBO-ofFfPso-7uz3VbrD6H5UDyMQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chris,

On 2/2/13 11:47 AM, chris derham wrote:
>> In the Java world, most people would only call it a consider it
>> a "cluster" if the app servers actually know about each other --
>> for instance, if you are using session replication. IMO session 
>> replication is a dog, and there are better ways to achieve
>> similar goals that yield much higher performance.
> 
> I am curious to hear your thoughts - care to elaborate?

We've totally hijacked Zoran's thread. After this, let's move to a new
OT thread (or threads).

Tomcat's session replication basically blasts everything around to all
other Tomcat instances (or you can choose one and use BackupManager).
Every time you modify your session, you get a burst of traffic between
all your cluster members.

I dunno if Tomcat bothers updating the last-touched-time on the
session if that's the only thing that changed during the request, but
if so it means that there is a burst of replication traffic after
/every single request/.

Most web applications I've seen use HttpSession for a variety of
things, and not all of them need to be replicated. If you want to
hand-roll some wrapper objects to allow you to stash things into the
session that are not serializable (or shouldn't be serialized, like a
"transient" wrapper) you can avoid some of this stuff, but you really
shouldn't have to do this kind of thing.

Instead, rely on some other data-sharing mechanism such as a database,
memcached, etc. You can create a token that you pass to the client
just like a JSESSIONID cookie and if they fail-over to a different
node, you can still fetch your stuff when you need it.

The problem with using HttpSession + session replication is that lazy
programmers will stash just about anything into the session without
thinking about it, and it will get replicated all over the place. If
you use an external data storage mechanism, it's much more obvious
that something "special" is happening, and (hopefully) your devs will
take more care with dipping into that data store all the time.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlERkVcACgkQ9CaO5/Lv0PD0YACgg0mbr02sf0YHp1u+TeXT0oo/
eEsAoJyirF+Vz5YsGa3t7WbTXuq8uAuc
=c0H2
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org