This might sounds too short for people in China, as in most cases it spends more than 30s. We should have a ENV to disable timeout.

@laosb The TIMEOUT_SCALE_FACTOR env variable exists already and you can set it to a higher multiplier.

Didn't realize it. Was that env used in other places?

Also, timeout is not to download a file, but more or less timeout between TCP packets. I do not think that you have 15 seconds between packets even in China. :-)

Ah, my mistake, sorry!

I hoped that my comment in the code is conveying this. :-( Should I improve it?

I thought it was fine – in general when talking about HTTP "timeout" this is what is implied – it's never the overall duration of the download, but instead the max time between blocks of data.

My only concern is if this is an appropriate use of timeoutScaleFactor – as that's only really used in selftest (usually in test.waitSecs) for increasing the delay when awaiting the next command to output to the log. I don't think it's currently purposed for networking stuff.

I also think all future ENV variables should be prefixed with METEOR_, but that's a separate issue and not something you've caused with this PR. :)

And we should have a cheatsheet for ENVs.

I do not know, I can remove it. I do not see really a reason for anyone to increase it to more than 15 seconds anyway.

We should not remove it, as nobody knows who will need it.

I think this timeout is important. I might actually make it 60 seconds just to cover the worst cases. A 15 second transmission timeout can absolutely happen – especially on a wifi or mobile network when switching modes – but is still recoverable in most all cases. After a minute, you're very likely down though. I guess 60 seconds of waiting might be obnoxious in some environments though – maybe 30 is an okay compromise though?

I'd probably wait to see about using timeoutScaleFactor based on what core says.

Based on the networking problems I've seen so far (including CDN problems, etc.) I think a procedure for HTTP request retry strategies is the next thing that might need some attention.

I think we should merge it with 15 seconds, and provide it with a release candidate. And then see what people give feedback on.

But yes, it could also be longer. I just do not want cases like now where it just hangs indefinitely.

Definitely don't want infinite hanging. My vote would be 60 – too short of a timeout and this could actually increase the number of package install problems by terminating them when they still might succeed if left to wait.

Shall we ask our friend Math.random?

> Math.round(Math.random() * 45 + 15)
35

In all seriousness, I'm subjectively comfortable with 30 seconds.

And should I just remove the scaling and make it 30s and this is it?

Yeah let's make it 30 seconds, and keep the scaling factor unless there's a good reason to remove it.

Others said that until now scaling factor is used only for testing.

Lgtm, thanks @mitar

I'm getting the following error when I try to deploy to Galaxy with 1.3.4

Error deploying application: Connection error (ETIMEDOUT)

Could this be related or is Galaxy simply having issues?

Edit: Setting TIMEOUT_SCALE_FACTOR to 10 fixed it (just picked a number), or Galaxy is back online again.

For who is reading the above comment; It has been comfirmed that this caused the deploy issue. A fix will be released soon. See this thread for details:

https://forums.meteor.com/t/1-3-4-breaks-galaxy-deployment-etimedout/25383/7

Can some explain how to change the TIMEOUT_SCALE_FACTOR. Is this a variable stored somewhere, can it be done from the terminal?

On Mac/Linux:

TIMEOUT_SCALE_FACTOR=10 meteor deploy ...

On Windows (PowerShell):

$env:TIMEOUT_SCALE_FACTOR = "10"
meteor deploy ...

Unfortunately, even 60s got an exceed in China. Changing TIMEOUT_SCALE_FACTOR...

For downloading or uploading?

I think the solution is to restart. Not to extend timeout. With such long delays between TCP packets, TCP connection might not recover anyway.

Downloading. Retried several times.

An auto-retry-and-resume strategy would make Meteor usable in China, I think.

Care of trying to add this feature to request library?

I seems to be getting a similar issue with Meteor 1.3.5.1 I have tried TIMEOUT_SCALE_FACTOR = "10" but I cannot consistently deploy to Galaxy

What is the TIMEOUT_SCALE_FACTOR range and what does each value mean?