<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[FusionAuth in a cluster and separate user sessions for each node]]></title><description><![CDATA[<p dir="auto">Hello</p>
<p dir="auto">My setup consists of 3 virtual machines running database, FusionAuth &amp; elasticsearch in a clusters plus a load balancer:</p>
<ul>
<li>vm1: PostgreSQL DB (shared)</li>
<li>vm2: FusionAuth node1 + Elasticsearch node 1</li>
<li>vm3: FusionAuth node2 + Elasticsearch node 2</li>
<li>LoadBalancer</li>
</ul>
<p dir="auto">The problem is that every few requests I'm logged out of the FA management panel. It seems to happen when the load balancer directs the request to the FusionAuth node different than the one used for the previous requests. I can see that JSESSIONID cookie gets changed when I'm logged out. Turns out FusionAuth instances are not sharing the user session, is this correct?</p>
<p dir="auto">The quick fix is to make the load balancer use "sticky sessions" but I wonder if this is the correct way to resolve this. Maybe I have something wrong with the FA configuration?</p>
]]></description><link>https://fusionauth.io/community/forum/topic/209/fusionauth-in-a-cluster-and-separate-user-sessions-for-each-node</link><generator>RSS for Node</generator><lastBuildDate>Wed, 11 Mar 2026 04:07:22 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/topic/209.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 07 Jul 2020 11:31:14 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to FusionAuth in a cluster and separate user sessions for each node on Wed, 30 Dec 2020 20:00:30 GMT]]></title><description><![CDATA[<p dir="auto">Note that as of 1.19.0, session pinning/sticky sessions are no longer required. <a href="https://fusionauth.io/docs/v1/tech/release-notes/#version-1-19-0" rel="nofollow ugc">More details here</a>.</p>
]]></description><link>https://fusionauth.io/community/forum/post/2082</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/2082</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Wed, 30 Dec 2020 20:00:30 GMT</pubDate></item><item><title><![CDATA[Reply to FusionAuth in a cluster and separate user sessions for each node on Tue, 07 Jul 2020 14:38:05 GMT]]></title><description><![CDATA[<p dir="auto">Yup, sticky sessions is the answer! Glad you were able to sort this out.</p>
]]></description><link>https://fusionauth.io/community/forum/post/528</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/528</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Tue, 07 Jul 2020 14:38:05 GMT</pubDate></item><item><title><![CDATA[Reply to FusionAuth in a cluster and separate user sessions for each node on Tue, 07 Jul 2020 12:09:20 GMT]]></title><description><![CDATA[<p dir="auto">Answering to myself, as I've found the information regarding this issue in the docs. Seems "sticky sessions" is the way to go.</p>
<p dir="auto"><a href="https://fusionauth.io/docs/v1/tech/installation-guide/server-layout" rel="nofollow ugc">https://fusionauth.io/docs/v1/tech/installation-guide/server-layout</a></p>
<p dir="auto">"In this scenario FusionAuth should be placed behind a load balancer to utilize both services equally. Session pinning should be utilized to support stateful sessions to FusionAuth"</p>
]]></description><link>https://fusionauth.io/community/forum/post/526</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/526</guid><dc:creator><![CDATA[maciej.wisniowski]]></dc:creator><pubDate>Tue, 07 Jul 2020 12:09:20 GMT</pubDate></item></channel></rss>