After switching the alias to another fleet, the queue still places sessions on the old fleet

Hi there! Why, after changing the alias to another fleet, the queue still places sessions on the old fleets for several minutes?
We use the following scheme to update our game: create a new fleet, after it enters the ACTIVE state (and have free slots), switch the alias to it (the queue refers to this alias).
But new sessions continue to be placed to the old fleet for 4-6 minutes.

#Sessions on the old fleet after switch alias ref:
Game session: arn:aws:gamelift:us-east-1::gamesession/fleet-c2ff646d-3f0e-4633-8dd9-d8219f618dfc/086504a5-81af-468c-aa27-301ee833e69d

#New FleetID
fleet-25820f09-6388-4e3c-b344-713f1149a050

#Alias ID
alias-237fa3f9-667c-4917-b43d-f8a1daf2568a

How to fix this problem?

My assumption is that there will be small delay due to server side caches but it should be low seconds not minutes, so this seems unusual.

Are you creating game sessions directly, through a queue or through FlexMatch?

I’ve asked someone from the GamelIft service team to take a look.

@Pip, we are creating game sessions through FlexMatch.

Hi @Anry , I took a look at the alias switch timing. It looks like the alias change took some time for the switch to occur due to a few seconds of server side caching and the timing of session creations.

Looking at placement of game sessions, I see a session was placed on the old fleet about 15 seconds after the update. This session was activated soon after the update and didn’t receive the latest alias path due to our internal caching. The next session was created several minutes later and was placed on the new fleet.

Please let us know if this corresponds to what you experienced when the alias change occurred!

Hi @DanG, this is not exactly corresponds to our case, we saw several places of game sessions to the old fleet after the alias update for a few minutes. Can you provide more info about the ‘internal caching’? How long cache store path to a fleet? How to avoid cache problems?

@Anry - The team will need GameSessionIds that you think are being incorrectly placed to investigate further. We looked at all the game sessions placed around the time the fleet alias was updated and there was a long gap between calls to create new sessions.

Most back end servers will have some cache layers between themselves and their data store so they don’t have to keep looking up the same information. As Dan noted this is <=16 secs across all GameLift services for an alias id so everything sees the new fleet id.

I would be curious as to your use case of using Queues and AliasIds with FlexMatch. This is a fairly unusual pattern because queues already provide an indirect mechanism to fleets, and fleets can be hot swapped in the queue similar to alias ids.

Hi, here are game sessions with wrong alias ref.:

arn:aws:gamelift:eu-central-1::gamesession/fleet-cd5d9d7a-77ff-499b-8116-27fabd2aa499/b9663432-2e2d-4ebc-ba35-735db4b1eb30

arn:aws:gamelift:eu-central-1::gamesession/fleet-cd5d9d7a-77ff-499b-8116-27fabd2aa499/3d3e3cbc-e5c1-40f3-b7de-e2444f24b098

arn:aws:gamelift:us-east-1::gamesession/fleet-c2ff646d-3f0e-4633-8dd9-d8219f618dfc/84c79032-7943-4069-ba90-d06eba1a491c

arn:aws:gamelift:us-east-1::gamesession/fleet-c2ff646d-3f0e-4633-8dd9-d8219f618dfc/086504a5-81af-468c-aa27-301ee833e69d

This 2 fleets with the same build version (old game version).
We updated the aliases at different regions in parallel via aws cli.

We simply use AliasIDs in Queue and update alias only (only changing a FleetID on it). We don’t touch Queue on updates.