-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel,
On 2/27/15 10:00 AM, Daniel Mikusa wrote: > On Fri, Feb 27, 2015 at 9:39 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Daniel, > > On 2/27/15 9:24 AM, Daniel Mikusa wrote: >>>> On Fri, Feb 27, 2015 at 8:35 AM, Alexander Diedler >>>> <adied...@tecracer.de> wrote: >>>> >>>>> Hello Daniel, That you for your reply. You mean, that >>>>> session persistance was enabled and a failover was >>>>> recordnized by the loadbalancer and the session was still >>>>> available on the remaining node? >>>>> >>>> >>>> No. I'm just talking about your configuration. You have two >>>> conflicting things configured. >>>> >>>> 1.) You have a session store created. This is going to store >>>> your sessions into the database. It's *not* clustering (at >>>> least by the definition Tomcat uses), but can be an effective >>>> way to share sessions across multiple Tomcat instances. >>>> >>>> 2.) You have a cluster defined. This is going to tell Tomcat >>>> to replicate session data directly between your Tomcat nodes. >>>> As you pointed out previously, this can be problematic on AWS >>>> where they don't support multicast. It's also conflicting >>>> with #1, which is what the error you reported is telling >>>> you. >>>> >>>> In short, remove the <Cluster/> tag, the error should go >>>> away. > > Are you sure that's best? > > >> My intent was just to answer the question that was asked. I was >> trying to stay out of this part of the discussion :) > > > If the goal is uninterrupted fail-over, then perhaps using the > BackupManager or DeltaManager with static membership is the better > strategy. > > >> +1 I generally prefer session replication and if static >> membership will work I'd agree that's the way to go. Sometimes >> that is tricky on AWS because the IP addresses can change, then >> your config needs updated and it can get messy. Once booted, the IP address won't change, but you are right: if you want to be "agile" on AWS (which is kind of the whole point), then you have to figure out how to play the IP address game. One option is using something like n2n to create a network space where multicast can work. It seems like a total pain in the neck to me, though. >> On the subject of what's better, when using a shared storage >> approach for sessions you'd probably want to go with Redis or >> Memcached and not a JDBC backed store. Performance should be >> much better. Although I've neither tried nor benchmarked either of these solutions, I suspect that you are correct in that some kind of key-value store is going to give higher performance than a relational database. Note that Memcached in particular is totally ephemeral (without some heroic measures) and so your session store can disappear on you if you aren't careful. If the OP wants the user's login to follow them, I think formal clustering is required, depending upon the authentication setup: without clustering, I think Tomcat will require a re-login on fail-over unless session replication has been enabled, because certain authentication information is tied to the session but not in session attributes (which are the only things stored in the database when using PersistentStore). Then again, I have zero experience with this and may be completely incorrect. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU8JEiAAoJEBzwKT+lPKRYjZYP/ieEXmqG4Kh3MAg+jo6aWzTV QmFG+iRFme7yV6EU/e7R57RgqqY9NW+RxMOyI9/kxIlQRleDTcMeSDWchymf/KoY ITdKN7+la/PqUzEvyrehqaO8L7RpNNaaUMnhxSNiVfgD2zlbPq/85XZzSUauUxlA 2aiT7dig1dIT6S729rsg2wNIzMSriVLhP1D2N3rwBvEVarccxehFVXDz//xYdtJU bWEZVUQLdu4J6Qzx9q8mQSyP3Gho3zi52qQ6YhLglMoIZEJU/v1ImGGpLYlmyr/C nOg3dKVc469q5xqRPEphwr9XGcM4fM3K6qelDz9L9e0OpbBb3rU5a92D0nAQM8xe Blr2JahaZdXJrsOvz8gqHzet0SUI4pEgANFhB+66Lw6dZejIHCK6eTdgpvgyBvIY Mz6zRID+5u6ftaZzhtPUDOzHj7kP5u8zdmrSITF/g9Ryqw4a2lem4DML01UQM++v LcdfTRujDlwBz9ktr7gVS6mpzMtwoLB0IhEY0D26sBXZIIQkWGr7dYFYJn6Zq79P /2yy7ZqIwDr0Onh97w0vVto1arr5ivBTMna9wbE565cq+minzIHPi6kTlNFMBH6S YPca8Wl2G/zm25OF8Y9m8LKDf65wKM6ZOjjCFGOiK2ywnFxj2OuCcuKdNcoe2h5F FRPI7jfq4mAAcWQRuyKD =ABjN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
