I'm using

sessionCluster=true

on a production app that has three Lucee instances all running 5.3.10.120. Very rarely, but seemingly in the same situations, a session variable only persists on the instance it was set on, meaning the session data is inconsistent across instances. The situation(s) in question I believe all involve a redirect (using ColdBox's

relocate()

) after setting the session variable. Is this is a known issue? Is there some sort of session flush I need to execute before the relocation?

Are you using sticky sessions? That's best practice these days, for performance reasons lucee only writes sessions to the central cache after a certain time

Heck no. How is sticky session best practice in containerized environments? When containers can come and go at random?

Yeah I'm not 100% sure of the deets but for performance I think every request doesn't read n write a session

Honestly. I thought the whole point of

sessionCluster=true

was to tell Lucee to aggressively write to session cache. i.e., you can use a distributed cache with

sessionCluster=false

and it would write to memory until the end of the request. But with

sessionCluster=true

it writes with every session scope change. I know it does this because I can see many writes to my session cache per request.

I'm on my phone so I can't check the code

Right on, appreciate the help 👍🏻

OK, good info in that thread even though I'm not really worried about locking (this definitely isn't a race condition situation). But the fact that @bdw429s couldn't figure out the rhyme or reason of this makes me think I'm better off using

false

and re-enabling sticky sessions. I guess if a server drops / comes online at that point all the users "stuck" to the dropped server would move to a new one and their session would be read from the cache first since it's not in memory?