Thrill-Data only runs 5 minute checks and they had been relying on DISers for more precise details.
I hadn’t kept checking this morning to see when backups stopped.
@ironband74 , when the red Join BG button is tapped, does that ‘hold’ a specific BG until all the checks are run and the Profiles are placed into that BG?
Or, does placement in an open BG only occur after the Profile checks are run?
Have been discussing this with some TPAS Mods and we can’t determine when the exact placement occurs. With so many ‘playing at home,’ could that cause ‘in park guests’ to be blocked from regular BGs?
While I have only conjecture and "how I would build it" thoughts, I believe that the message doesn't get sent to the server until you pass the point where the tickets are selected and the second "Join boarding group" button is pressed. I think the communication goes like this:
Client loads page. Checks with server to see if the server can receive messages. If it can, it activates the button (Note that if page is cached, the check may not happen. This is why you don't want to click in to the Find out more page until after park open).
Client taps Join Boarding Group button from either the Find out More page or the Status Page.
Client selects tickets from the tickets scanned into the app.
Client taps "Join Boarding Group" at the bottom of the page.
Client sends message to server which includes all selected ticket numbers/pass numbers.
Server receives message and spools it.
Gate 1 checks the message to see if all ticket numbers in the message have been scanned into the park. If not all tickets are scanned in, it returns a message to the client indicating that all tickets are not scanned in and moves the client to a screen to deselect tickets. If they are all scanned in, it passes to Gate 2.
Gate 2 checks the message to see if any ticket numbers in the message have already been assigned a boarding group. If they have, it returns a message to the client to show the "You are already in a boarding group error. If none of the tickets in the message are assigned a boarding group, it passes the message to the Scheduler.
Note that Gates 1 and 2 can be multithreaded since they do not assign anything and just pass back a message to direct client behavior.
The Scheduler I believe is single threaded, but may be multithreaded and depend on the low probability of messages from the same group being in the same batch. The scheduler knows that the message has passed gates 1 and 2, and so now assigns boarding groups in succession while keeping tickets in the same message assigned to a single group. Once a group has been assigned, the Scheduler returns a message indicating which boarding group the tickets have been assigned and the client displays the success screen.
So I don't think that folks playing along at home tax anything, except the ping to the server to see if it is ready to accept messages or not.
