> What do you mean by logged out
>  If it's one from Redisson, then you should look at their code and not
Tomcat's code.

So you have two tomcat nodes: A & B, clustered in any fashion (forget I
mentioned redisson) of your choosing; let's say they're clustered using the
built in tcp point-to-point replication. Have 5 people logged into an
application on the first server using standard JavaEE APIs
(HttpServletrequest.login) Now turn off server A. Your load balancer starts
sending traffic to server B. Their sessions will be there, BUT they will be
logged out; one has to call HttpServletRequest.login() again. Upon login,
Tomcat destroys the previous session (as it should), nullifying any benefit
for clustering the application in the first place.

In the two links I provided, the StandardSession object goes to great
length to ensure that the security principal is not serialized into the
session, and therefore replicated in the cluster. Why is that? Why not
serialize the security credential so the user can bounce between servers?

On Tue, Feb 11, 2020 at 4:27 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Hash: SHA256
> Jon,
> On 2/11/20 2:35 PM, exabrial wrote:
> > https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-duri
> ng-session-failover-event-and-restarts
> <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-during-session-failover-event-and-restarts>
> >
> >
> >
> >
> We've implemented session replication using Redisson, but we noticed
> > that if we intentionally fail a node, the user's sessions do get
> > replicated, but they're logged out when they're restored on the new
> >  server.
> What exactly do you mean when you say "logged-out"?
> > Is there a way to make this work properly so the user doesn't get
> > logged out during a failover event?
> >
> > Most /More importantly, is there a technical or security reason for
> >  this?
> FYI the servlet specification does not guarantee that <distributable>
> web applications also transfer authentication information.
> > If you look at the Tomcat code, they actively try and avoid
> > serialization the Security Principal:
> >
> > https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/
> session/StandardSession.java#L1559
> <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L1559>
> >
> >
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/se
> ssion/StandardSession.java#L234
> <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L234>
> That code is for serializing the whole session, not transmitting
> session information between cluster nodes. You need to read the code
> for the various ClusterManagers and (more importantly), the
> DeltaSession class.
> Which SessionManager are you using? If it's one from Redisson, then
> you should look at their code and not Tomcat's code.
> - -chris
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> pFj5fA/+MtxPWjtoiRCcfPJSvjdZjjZA1PbiTPSxXqtizg17071kQJVXy3GONP6O
> AONwDkm/+2yNo6RJvRH2WW5qLZgX9FvNekUVkDeM+MvNOwszqAx/doXgCwO1ljy3
> Dv1uOgWCGE2ktAig3Cul9BICGmq6hhcfI9yT0oicrrxKI9njpVKhhJijLvJEZNFp
> GeSwU2QMRR25asinBvCJ2L6wMFM5ppXjpwoWVvI1G+UlFYEUOZAAlNAsq/Dblmuo
> 45GrNQdw2LyKfjt/lLaQrjEOx3KoHtfIKBOxSBgwJFykx/w3RmoEXONrwj6tuTyG
> HVSvLITH0rky301YvXPqrEAseW0816grwbCkP1HrmDfbpVCQ/1QUb+ceKEHzLuOr
> 8XPha3M0xDhFF9daEqJcYurcIC6NCMy0UuvaSfvh3ICy/RFL2K4Sql9SRGnj4eLV
> 8QJTMHgKDD3Gie2wHr9gYDwj7gtkjHGJrMyCNOh1bTNSQKkabFlsUL1uiEOJ0QgR
> EkLketZAhWNGMiaS4X41jtqQymL5zJI7P7KqGy0LmuZErZt6qot/5If0osgnl1V+
> wjP6YjBU2i9YajNJB57JFtx3AkCRXUXZm4vAQnG8v//ECsWOrggdlQvF+W5r2mXr
> 50z5n2LUbUrKTX9N3ailoNczmZ/MyEhUhyTT7xmqSjLXtlFPO7g=
> =UkyD

Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
Engineers, of course, understand the glass is twice as big as it needs to

Reply via email to