On Tue, Feb 5, 2013 at 6:10 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----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/. >
Interesting! > 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. interesting... i was reading about a memcached (open source) project that works really well with tomcat, and i was going to ask about it on this list. I liked the blog that I saw about this, because 'honestly' it seemed easier to read and easier to implement than reading tomcat's 'cluster/session-replication documentation page'. :( an example or blog is always a great read. :) > > 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. Ouch, that hurt again! I think I did a lot of this when I first began Java EE development, but have learned that it is not necessary any longer, and honestly, I may still be guilty of stashing stuff into the session. > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
