4 of 4 people found this helpful
Tableau Server sessions are tracked using a cookie stored on the end-user client. So for instance, if User A has a session in Chrome, then opens IE and logs in to Tableau Server, a new session will be created. This is because Chrome and IE do not share cookies.
In another scenario, if you have a Tableau Server session open with Chrome, and open an 'Incognito Mode' window in Chrome, logging in to Tableau Server in this new window will give you a new session.
The same goes for using your tablet/cell phone.
The presence or absence of an external load balancer does not effect this behavior in any way. In fact, a Tableau Server cluster has a built-in load balancer, so a request sent to one node can be handled by processes on any of the nodes. Unless you are configuring a High Availability Tableau Server cluster, an external load balancer is typically not needed.
EDIT: One other situation where an external load balancer would be useful - two Tableau Server deployments, one Production and the other Disaster Recovery. An external load balancer can be used to seamlessly fail-over to the Disaster Recovery deployment, in the event that Production goes down. Although in this situation, it is functioning less as a load balancer, and more as a very smart reverse proxy.
I do have further queries. Requesting you to please have a look
I understood from your response that the session management is at client side.
Let's say i login to Tableau Server in a tab in chrome browser. I am redirected to worker node 1 and the session information is stored in the client side browser (chrome). Now, i open second tab in the same browser - chrome - with same URL (Tableau server) as the first tab. In this second tab, will my request with all the client side stored information go to worker node 2 or request will keep going to node 1(since node 1 was used in first tab request)?
I understand that both of the tabs use same session.
Let's say i login to Tableau Server in a tab in chrome browser. I open a dashboard and change some filters in it. I open second tab with same url as the first tab in chrome browser. I notice that in second tab, the state (changed filters) of dashboard that was on tab 1 is maintained. How does this state management happens?
4 of 4 people found this helpful
Ok, so here is where things get confusing.
There are multiple different "sessions" when talking about Tableau Server. One session is the user's authentication with Tableau Server, which I will refer to as "User Session". Another session is the user's interaction with a VizQLServer process (the process that does the actual rendering of the workbook), which I will refer to as "VizQL Session".
The User Session follows the user around as they interact with Tableau Server, and stays the same until they log out (or timeout). The VizQL Session is specific to a workbook/dashboard that the user has open, and is only used to refer to that interaction.
The User Session is stored in a cookie on the client machine. The VizQL Session is stored on Tableau Server itself, and is only visible to end-users if an error happens. (It will be a 32 digit hexadecimal number, followed by 2 integers. It looks like this -> F86F7525B268426E92018FB02A9DF4D6-1:0)
I can have 1 User Session but many VizQL Sessions - for instance, if I have logged in to Tableau Server with only one device+browser combo, but have multiple dashboards open. Each dashboard has its own VizQL Session, because they are each being rendered independently, but all fall under the same User Session.
So, on to your first question. If you open a second tab, it will most likely be handled by the same VizQLServer process on the same node. There are exceptions to this, but VizQL Sessions are fairly 'sticky'. Tableau Server does this to try to leverage the in-process cache that each VizQLServer process maintains. But if you check the URL when you open a new tab, Tableau Server will iterate the "iid" number, because it recognizes this as a new browser tab. When this new "iid" is issued, a new VizQL Session will be created, so that the two different browser tabs can now be manipulated independently. It is at this point that we might get sent to a different VizQLServer process, possibly on a different node.
This leads nicely in to question 2. If you open a new tab and copy/paste the dashboard URL, you will see the same state as the first tab because you have specified the same "iid" number.
Try this out. Open a dashboard, make some changes to the filters, and then copy/paste the URL but leave off everything after the "?". (For instance, my dashboard is at "http://my.tableau.server/#/views/TestDashboard/Sheet1?:iid=5&render=true". I would copy only the "http://my.tableau.server/#/views/TestDashboard/Sheet1", and leave off the "?:iid=5&render=true"). When you do this, a fresh version of the dashboard will be opened (without the changes you just made), and a new "iid" will be issued (new VizQL Session).
Which highlights the purpose of the "iid". The "iid" is there to allow users to have multiple copies of the same dashboard open. It is the method that Tableau Server uses to differentiate two different VizQL Sessions, owned by one User Session, when both VizQL Sessions are loading the same dashboard. Leaving off the "iid" tells Tableau Server that you want to start fresh. Specifying the same "iid" tells Tableau Server that you want to use the same dashboard state. But even when you specify the same "iid", Tableau Server can still tell it's a new browser window, so it needs to create a new VizQL Session (hence, it gives you a new "iid").
I hope this helps clear things up. Sorry if this is confusing, but session management in Tableau Server can be a complicated topic.
Hi Brandyn Moody,
Your response is excellent. I have been able to sort out most of things. I will take some time to do some tests and get back to you with my detailed test results.
And..Do you write any blogs on Tableau/ Visualizations? Are you on LinkedIn? I would love to keep reading Tableau related material that you publish anywhere (Tableau Community / LinkedIn/ Blog/ website).
And, as of now, i do have couple of more followup confirmation on user sessions.
Based on your response, sessions are managed at client side. When i login and run a Tableau dashboard, i see that a sessionId (i assume it is user sessionID) gets created in work group DB (this DB is in repository) in sessions table and the session information is stored in client side browser. How does this user session information gets propagated from the node containing repository to other nodes in the cluster? Given - We know that repository can not be replicated on all nodes. We also know from your response when user opens another tab in same browser, user can be redirected to other nodes in cluster.
Second, i know that the processes in different nodes in a cluster can talk to each other. I am not sure how and through what mechanism. Can you please elaborate on that aspect? Which are the processes that can talk through the cluster and for what purpose?
1 of 1 people found this helpful
I do have a LinkedIn, it should be pretty easy to find because my name is fairly unique.
I do not write any blogs, although that is a good idea, I may start doing so in the future. If I do, I'll drop a link for you here.
About user session info propagation. There can be a backup Repository, and that is regularly synchronized with the primary Repository, but the primary Repository is the "single version of the truth". So any process that needs to deal with user sessions will query the active Repository before dealing with a user, to fetch the user session information. User session information is queried on-demand, so it does not need to be pro-actively propagated to all nodes.
This is why the node hosting the Repository must have very fast hard drive access. The Repository needs to be able to respond quickly to a lot of small, fast queries. In addition to user session information, many other Tableau Server actions are handled in this manner. Workbook information is held in the Repository, and VizQLServer will query the Repository before rendering a workbook. The same is true for Data Sources connection information, user permissions, usage statistics (although for this one, a process will post to the Repository, not query it), etc.
About processes talking to each other. All Tableau Server processes, with very few exceptions, will communicate with each other across TCP or UDP ports. Even on a single-node server, processes use network ports to communicate with each other. This is done so that the difference between single-node and cluster Tableau Server deployments is minimized, and makes scaling out much simpler. For a list of ports and protocols that each process uses, check out the document linked below.
Tableau Server Ports:
Keep in mind that the document above lists the ports for the newest version of Tableau Server, if you need port information for an older version of Tableau Server, replace the "current" in the link above with a specific version. For instance, the ports for a 9.2.x Tableau Server can be found at https://onlinehelp.tableau.com/v9.2/server/en-us/ports.htm .
Hope this info helps.