-
Suggestion
-
Resolution: Unresolved
-
None
-
14
-
1
-
When a user session is moved from one server to another, all session information is lost, including login credentials. When this happens, the user is forced to re-login in JIRA in order to create a new session.
Please implement user session replication between the nodes in order to avoid that.
- is duplicated by
-
- Closed
- is related to
-
- Gathering Interest
[JRASERVER-67647] Ability to have user session replication between the nodes in Jira Data Center (DC)
I have no experience with writing or configuring tomcat apps, so customizing how tomcat deploys Jira is outside of my skillset – if that's something that would work I'd be happy to try it, but I'd need some help figuring out how to set it up using the Atlassian Jira data center docker containers (on kubernetes). if it's that easy perhaps Atlassian could do a quick write-up of how to set it up? that would (IMO at least) satisfy the requirements for this ticket.
a18e59a95e41 did you try to investigate of Tomcat Cluster Redis session manager?
https://github.com/ran-jit/tomcat-cluster-redis-session-manager/wiki
Just curious is that possible to manage it?
I suppose Richard, you never used Enterprise HA Atlassian software?
I'm sorry, it only get's worse. Welcome to Atlassian landscape.
But hey, we have cakes here!
Wow.. just wow. a data center product designed for high availability that doesn't even support an optional form of shared sessions across servers? I mean, it's not even a hard thing to do... use memcache, redis, store them in postgresql, .... lots and lots of options and lots of open source implementations for each.
Yes, sticky connections technically work, but that means any time a node goes down anyone using it has to re-authenticate. I've literally never even seen a project before that was designed for high availability that didn't deal with that before literally anything else.
I'm literally baffled how this even has to be a suggestion, I had just assumed it would already be working as it is in every other piece of commercial software I've ever used. I'm not trying to be offensive, but something like this missing really does not inspire a lot of confidence in Jira Data Center as a product, and given how nice the software is otherwise I'm just ... sorry, my mind is blown.
I could see this as a good use case for Redis.
It is in-memory key-value storage system that supports replication ie: HA of the data.
As for how to un-complicate installation instructions with Redis added to the mix...
- assuming Jira DC is installed as HA, with 2x LB(active + standby), and 2x DB(active and replica)
- installing Redis on the DB nodes in reverse order will utilize mostly idle replica server, as well as provide redundancy(obviously depending on memory requirements for having say 60k sessions in memory it could be also located on the LB's in similar fashion)
Why? Because Jira itself have requirement of too much memory as is with all the plugins and complexity of DC data sizes... And bigger heap doesn't always mean better, not to mention it is CPU intensive solution.
Oh and yes, this is annoying for users, please add it! ie +1
//Tomas
+ 1 Would definitely be a very useful feature for bug fixing, rebooting and re-indexing Jira.
Adding my +1. We sometimes need to restart one of the nodes, and having all our users lose their state is very frustrating, especially if they were in the middle of updating a ticket.
Can we just turn on REDIS tomcat session replication?
+1 This has been really annoying when the sticky sessions don't work.
+1 Will simplify daily operation a lot - patching, restarts (for whatever reason), etc.
from 8.13 it's starting to sync saml sessions, which great step for us.
Unfortunately, it will be good to have that feature fully implemented.
Yeah, that's really needful, at least we have SAML/SSO, if one of node is goes down, we are getting too many requests to external provider of authentication via SAML.
4555db5a5f8f I tried to use the Redis session manager for Tomcat you suggested. At first it looked as if it worked - the details about the logged-in user were available to both cluster nodes from the shared session store. However, further tests showed that some plugins we use also store objects in the session and some of them do not implement Serializable, which leads to exceptions being thrown.