The server is full, try again later (1017)

[kukurumei]

The stupid thing is, not only do they have inferior network engineers, they have inferior Sr. Network engineers.

The first thing to do in this situation is set up an emergency team, to patch the launcher on the client side to catch the overflow of the failing queue system.

It would take a team of programers a couple of hours to write a small sub program creates a 2nd queue "room" that reports to the SE HQ instead of datacenters. Which then SE can send delay routes based on server load.

Thus when you log in to "server1" it's actually going to [check server load script] instead of "server1"
When you do that you can completely lower the simultaneous connection speed via client interface "check server load every 3 minutes else, queue"

It's the equivalent of setting up a line on the street, when the lobby is filled up.

[sgosky]

The stupid thing is, not only do they have inferior network engineers, they have inferior Sr. Network engineers.

The first thing to do in this situation is set up an emergency team, to patch the launcher on the client side to catch the overflow of the failing queue system.

It would take a team of programers a couple of hours to write a small sub program creates a 2nd queue "room" that reports to the SE HQ instead of datacenters. Which then SE can send delay routes based on server load.

Thus when you log in to "server1" it's actually going to [check server load script] instead of "server1"
When you do that you can completely lower the simultaneous connection speed via client interface "check server load every 3 minutes else, queue"

It's the equivalent of setting up a line using on the street, when the lobby is filled up.

It's actually trickier to have two queues talk to each other than it is to simply have one queue. I'd argue for an uncapped queue, but I'm extremely certain they're extremely limited based on hardware; budget hardware. It's not the fault of the software engineers. They, unfortunately, aren't allowed to do anything if they don't have permission. That's how it works in the industry. You want to fix something but until the higher ups give the OK, you have to sit on your thumbs.

[kukurumei]

It's actually trickier to have two queues talk to each other than it is to simply have one queue. I'd argue for an uncapped queue, but I'm extremely certain they're extremely limited based on hardware; budget hardware. It's not the fault of the software engineers. They, unfortunately, aren't allowed to do anything if they don't have permission. That's how it works in the industry. You want to fix something but until the higher ups give the OK, you have to sit on your thumbs.

It's only tricker if you don't control the program. In this case SE has full control of their own source code. They can do anything to it. Including putting a timer on retries, or better, their own priority code client side(aka 2nd queue).

This shouldn't happen because they have in house programers/engineers. I can understand a normal company getting hit because they rely on a standard set of tools, but SE has full control of theirs.

[sgosky]

It's only tricker if you don't control the program. In this case SE has full control of their own source code. They can do anything to it. Including putting a timer on retries, or better, their own priority code client side(aka 2nd queue).

This shouldn't happen because they have in house programers/engineers. I can understand a normal company getting hit because they rely on a standard set of tools, but SE has full control of theirs.

Unfortunately, the programmers still have to wait for permission to make those kinds of changes. I've been there; I wanted to push a fix that I had already written and tested, but the word upstairs was "not yet," so I sat there, twiddling my thumbs, and browsing the forum, reading all of the angry comments.