Chris, On 1/13/15, 11:06 AM, "Christopher Schultz" <ch...@christopherschultz.net> wrote:
>-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Peter, > >On 1/13/15 1:10 PM, Peter Rifel wrote: >> On 1/13/15, 6:32 AM, "Christopher Schultz" >> <ch...@christopherschultz.net> wrote: >> >> I was wondering, because there is an unfortunately situation with >> session stickiness and long-lived clients where fail-over can cause >> a large number of clients to switch to a particular server and >> /stay there/ even if they have to re-login (when you'd likely >> prefer that they get re-balanced to another node if they have to >> re-login). >> >> If you had a temporary failure of one node, perhaps the clients >> were re-assigned to another node and they "stayed there" when the >> failing node became available again. Those clients would stay there >> until either their newly-assigned node failed, or they closed their >> browser (assuming they are using cookies that live for the life of >> the client, like JSESSIONIDs typically do). >> >> After the weekend in your scenario, perhaps all your users >> restarted their browsers (or computers) and thus were re-balanced. >> >>> But shouldn't all sessions be replicated regardless of how >>> stickiness is (or isn't) setup? > >Yes, they should. I was just considering a possible failure scenario. >With completely distributable sessions and the DeltaManager, the whole >cluster should stay in sync. > >>> I assume that the DeltaManager only replicates changes to the >>> state of all sessions since its last replication. Maybe if there >>> was a hiccup in replication by one tomcat instance, the sessions >>> that it created or extended would not have gotten replicated and >>> then never made their way to the other instances until they >>> expire on their own. > >If this happened, you should be able to see some indication in the log >files. > >>> If this is the case, I may try and come up with a better method >>> for monitoring the clustering state, unless anyone has any >>> suggestions on how to fix this supposed hiccup. > >It seems reasonable to expect that the session count would be >consistent across the cluster, at least over time (obviously, it could >take a few seconds for the cluster to become consistent if you are >watching very carefully). > >The logs contain no clues? Both log4j and CATALINA_OUT on every instance make no reference to any session related issues at the time that this started. > >How many nodes are in the cluster? 5? I know that DeltaManager's >performance degrades as the number of nodes increases, but I think >it's a linear performance drop, as opposed to anything polynomial. I'm >not sure if 5 nodes ends up being the breaking point, especially given >your load profile (which you didn't specify). Yes, we have 5 nodes. I may consider a different Manager if this becomes more of an issue. > >When you get nodes out of sync, can you probe them to find out if >those "extra" sessions might be expired, but not yet cleaned-up? Yes I will try and dump the session id list the next time this happens and do some debugging. Hopefully its not during a weekend... Thanks again for your help! I'll be back here again if I have any new info. Peter > >- -chris >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1 >Comment: GPGTools - http://gpgtools.org > >iQIcBAEBCAAGBQJUtWy+AAoJEBzwKT+lPKRYg9kQAL04b/noYkqhhGJ+dznl5njP >nXX0VSCoCEF0+tEIGMvwS2k3MWJdxIlqPvpLnj2efompRmICB7cvVAjYF99xX6g9 >7SqV3TQ9eSNC3FzTPZomUolbSph7XS1eus3BEauRJ90H2ZaokeczSPDRPK/Gzsoq >5+A9B22AcAspQOckZ+FaG5Qw/nwNeH+woksnPP2gCsgD85Rgs2PSlxJ+C8bF2VZ7 >PbXnDCBTh2dSPnFWb/E3tHVMb9lICz6/T/oVswnGJNuxwHfoceuWxnzlDisTU4jj >LCNqg65gCOcscqLooS/L2t4znWlsnKAVsCmxOLYutOlZgLtnMhVXPqi7u1sRbZV6 >SL+3HSOoT6hpI2/w80RVxdPtVosLx0NpYPEq0Kp/Bv/4iXdwGyxtqJ6biTppyCe6 >US6Se7QyOt4lZOG0Bgp6nwx657sgAZUTBqN2JNFmVizx89Lh2A7r6fN6FoPnMxWH >6ab4qTjPGi8C0TsndY4ei7IDyEF14/JhNgJcpstt37KTJkhuECHZng0vaP7mt0rG >f27w2fR2UQtRMkAE3ydKgGUSrOTybai6Y6Z4R4pOoKQl3lilwAMX/PjPODAWkc6T >RC9upIneDXdWB2eZzSfIr9v06JV/GT5fHjIn0eV1CtFs+95zYg4Jtn9+obTte08y >WnYTGW5w9PC69+csaVcz >=pPm4 >-----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
