To reproduce, run the following using Node.js:
let http = require("http");
http.createServer((_, response) => {
setTimeout(() => {
response.writeHead(200, { "Content-Type": "text/plain" });
response.end("Hello, cruel world!");
}, 10000);
}).listen(34733, "127.0.0.1");
Then, in a fresh baseplate, run this in Roblox Studio’s command bar:
local HttpService = game:GetService("HttpService")
HttpService.HttpEnabled = true
for i = 1, 4 do
task.spawn(function()
local response = HttpService:GetAsync("http://127.0.0.1:34733")
print(response .. " " .. i)
end)
end
This results in output something like this:
13:07:24.065 Hello, cruel world! 1 - Edit
13:07:24.066 Hello, cruel world! 2 - Edit
13:07:24.066 Hello, cruel world! 3 - Edit
13:07:34.081 Hello, cruel world! 4 - Edit
We can see that the first three requests are made in quick succession and get responses after ten seconds (as expected), while the fourth request seems to get queued behind the first three, and is only sent once there are fewer than 3 requests in-flight. I’ve verified that this is indeed the case by analyzing my loopback traffic - here’s the zipped pcap: only-3-requests.zip (1.4 KB).
This behavior occurs for further requests to any host, and the only way to clear this queue is to restart Roblox Studio. It seems related to this issue: HttpService extremely sluggish in studio.
This is specifically a problem for Rojo because it uses long polling, and it doesn’t have any logic implemented for cancelling open requests after a user disconnects. New users often rapidly disconnect from and reconnect to the Rojo server while trialing the software. Rojo only times out these long polls after a couple minutes, so after a user disconnects and reconnects 3 times, they have to wait a couple minutes before the Rojo plugin finally reconnects. When this happens, it seems to users that Rojo is very slow or “laggy” when the cause is really HttpService refusing to make more than 3 requests at a time.
Expected behavior
HttpService should be able to make more than 3 requests at a time. I’m not sure when this limit was added (I don’t recall it being a problem about a year ago), but I’d like it raised so it’s not so easy to trigger this queueing behavior. While Rojo could implement logic to close any open requests once a client disconnects, I still think a maximum of 3 requests is unreasonable, especially since this seems to be a global limit.
