Sticky sessions?

This post from a few years ago mentioned that stick sessions were on the roadmap:

I can’t find anything about that in the docs but maybe I’m missing it. Has that been implemented?

I think this might be what you’re after:

This should be helpfull as well:

1 Like

Hmm, if I’m reading that right that causes a request to be replayed against another VM which isn’t quite what I’m looking for. I want to arrange things so if a browser gets routed to a given VM on request one subsequent requests go to the same VM. (This is because the app I’m using involves uploading some data to the server and then making a request that processes the data. The data doesn’t have to stick around forever but if the second request goes to a different VM the uploaded data won’t be there.)

I guess I could use replay to replicate the data to all my VMs somehow but that seems a bit excessive.

I’ll start by saying that I agree that ideally this should be handled by the platform, and perhaps some day it will be. Meanwhile…

Consider a deployment with two VMs: VM1 and VM2.

A POST request comes in with some data. It gets routed to VM1. That VM writes the data to the filesystem. Before responding it gets FLY_MACHINE_ID from the ENV and adds it as a cookie.

Subsequently a GET request comes in requiring that same data. Unfortunately it gets routed to VM2. VM2 compares the cookie against FLY_MACHINE_ID and sees that it is different. So instead of proceeding, it responds with a Fly-Replay header specifying the desired machine. replays the same get request, but this time on VM1, which successfully processes the request.

Ah, I see. So that requires changing the server running on the fly machine to take part in this protocol.

One question though: when VM2 responds with the Fly-Replay header does that cause fly to replay to a new machine and then send the response from the replay back to the original client?

Correct. I should have spelled this out more completely.

The fly proxy that receives the response from VM2 will replay the original request (not the response it just received) to VM1. VM1 will compare the cookie to the FLY_MACHINE_ID, and seeing a match will proceed to read the file (which is only available on this machine), produce a response, and that response will go back to the original client without involvement by VM2.

This isn’t something that I merely think should work, nor is it something that I merely heard others say they use; I this is one of a number of techniques I use actively myself to solve a similar problem:

Showcase architecture - Multiple regions

Cool, thanks. Somehow I had missed that the response to the client came from the replayed request rather than the original request. In retrospect that makes sense but the docs could possibly be more clear about that.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.