Hello, Thanks for your ideas and best practises. This solution is for a bank and this peoples are very reserved about "hip technologies". The only goal ist o have High Availability, not load balancing. So we put the session information in a different Microsoft SQL 2008 database, that is independent from the application database.
Best regards Alexander -----Ursprüngliche Nachricht----- Von: Daniel Mikusa [mailto:dmik...@pivotal.io] Gesendet: Freitag, 27. Februar 2015 16:01 An: Tomcat Users List Betreff: Re: Persistance on Tomcat 8.0 and Cluster On Fri, Feb 27, 2015 at 9:39 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. 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. Dan > I guess the real question is for the OP: do you need clustering (i.e. > session replication between nodes) or is it okay if a user has to > login again and possibly re-start a workflow if they get failed-over > to another node? > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJU8IGMAAoJEBzwKT+lPKRY5SQQAIPfDPyKNssUyEOJw5ouA9Qw > 7chcfdhWVjiF83ecdXbZSxzS9hRi0l4pNdXVmU/LLQGNGfg+idtusrrG+fa4A4iE > xrs36Wt5DCN2+ejCFlWbrW1Ixk58DTLVdXMJ+F67QTIEp59MmKpGOdTXWlWKs8HI > Xgpq8hEJPMJbaUcEPu87iJbLviVoeWJD9i0TEeA/dcjdl0sR+WdH/VGBtS0TaAkX > ZMaR0Tkp/Fx4hLWUwe2s5QFrQ6n8Mpeggr76owXuSSD2+J0PYPkezs/ctvssn7OJ > YhHWPV5OQ52/YY3FFI5e8pEJZeX2D+FT+XS0CzI7EKsJ+UD9RgU/RVRv/iuKnLA9 > GImVr2aAAycCnqGZzDyOrMpO0MfHw9SqLttLdliX8HI383WODYNbrKoON6KaAQRK > MSwqbZ/YJcDczXVjzHxJZnggvhg2IYupQ89quSpf47kKL6bBw3607feiURegvSd5 > +xiONk3OifRDbcEv/Q3fGwU5rMYzPaf3f/6Jx0/j9jq/ijVKDUI0fvkqaZnCAev4 > o7p67AT6iyH31haRtLL72XFWm6/63hLXQ94qecOKyneAxu8/eWh+ajltAi28mMbk > GFI4iqQCcij9gjcGX++dDoNoe9qGsDj5ZIhVTWXC4hEnsZF64yQG+KHJ+Gss9JV7 > rbRTDWfS/YlVI/sBMiUz > =KZKi > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
