Doesn't work well on a flaky connection #746
Comments
|
Somewhat similar to #627, in that we're not retrying in a case where we probably should. |
|
Interesting. I often work while traveling through areas with little or no coverage, and found using NPM almost impossible then. Yarn seemed very promising, and some quick tests showed it does behave just fine having most/all packages cached, but it does appear equally ineffective when starting from scratch indeed. It would be great if it was more proactive on flaky networks. Context:I currently work on a project with 803 packages in total. On a 1mbps, 0% packets drop rate, 5ms delay connection, the install times with cleaned caches are as follows:
On a 1mbps, 10% packets drop rate, 500ms delay connection, the rather unscientific results are as follows:
|
|
can confirm yarn will trip up on a slow/unstable connection with |
|
I'm facing the same as well. On windows with a tethered mobile connection (not very fast but npm works) |
|
Same in Archlinux with my 1mbp connection. |
|
This happens to me despite having a very stable connection |
|
Windows 10, 512kbps... I can't finish any install. Lots of (random) socket hang ups. NPM works properly most of the time Example: yarn add v0.15.1 |
|
i run into the same problem,in MacOS 10.11.5, node 5.3.0, npm 3.9.5: |
|
Having the same issues on Windows 8, yarn 0.15.1, third-world connectivity ( flaky networks). npm works fine |
|
Here exactly the same on Debian Jessie with mobile connection (EDGE about 12kbps). |
|
If I try yarn upgrade I get something like this: yarn upgrade v0.15.1
[1/4] Resolving packages...
error socket hang up
at TLSSocket.onHangUp (_tls_wrap.js:1097:19)
at TLSSocket.g (events.js:273:16)
at emitNone (events.js:85:20)
at TLSSocket.emit (events.js:179:7)
at endReadableNT (_stream_readable.js:913:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)
info Visit http://yarnpkg.com/en/docs/cli/upgrade for documentation about this command.No chance to get it working. npm works fine. |
|
yarn v0.16.0 however, npm works well. |
|
I don't have a flaky connection and I'm having issues as well. yarn v0.15.1 |
|
I have the same issue and just found out that Kaspersky Internet Security is blocking the connection from yarn. I don't have problems installing with npm. |
|
I ran into this issue the other day on VPN, and can reliably repro it until I remove the cache. Maybe it also has something to do with cache. |
|
I got the same issue as @mmartinez |
|
Just investigated this again and for me it's also Kaspersky (on OSX) causing the issue |
|
The same happens to me on 2 mbps line! Npm works fine... |
|
Just hit this but my connection is stable otherwise (I'm posting this without problems - yet consistent failures towards the registry). Also not a kaspersy or other antivirus/proxy user. |
|
@gaearon this is the issue I mentioned on twitter |
|
@Kitanga Thanks. I’m compiling a list in facebook/create-react-app#1189, let me know if you had any other issues. |
|
+1, I'm experiencing this as well when the packet drop os high. |
|
I fixed it with this local NPM registry DNS comment: npm/npm#6686 (comment) |
|
Same problem here using Debian Jessie....
|
|
happening on Heroku this am |
|
Having this problem also on Heroku right now. Deleting |
|
magically fixed itself - also had issues with a buildserver failing into install nodejs, glitch in a cdn somewhere? |
|
Using vanilla I encounter a semi-persistent "There appears to be trouble with your network connection" issue. The actual exception is ESOCKETTIMEDOUT, like this (I've put I haven't figured out why exactly those fail and why things work fine without Docker. The container has no resource limits (and there are no kernel issues reported) and the network connectivity from the container looked pretty healthy to my probing. For example the latency is low and there is no packet loss neither on small, nor large packets: What I've tried and what doesn't seem to help:
Still, "[2/4] Fetching packages..." step retries randomly. Sometimes it passes just fine, sometimes it retries once, sometimes it retries for very long. With (One of our team members got really unlucky yesterday, and |
|
I am keep getting this error. I have tried at my work, and home network, but no luck. Environment: Windows 7, yarn 0.27.5, node v7.7.2 Any solution to this problem? |
|
adding registry.npmjs.org to /etc/hosts file helped me in my case: |
|
very lucking,thank you @stephanMettler in my case: |
|
Is there anything you guys want Otherwise, I don't see anything actionable here since we cannot fix everyone's internet connection (not yet, anyways). |
|
OK I had the same issues when building create-react-app inside docker, never managed to install. Backed out one step to the vagrant box, running on VirtualBox, installed node yarn etc and then again ran create-react-app. Same issue but it did get further, downloaded more packages, than under docker. Changed the network settings on vagrant from NAT to Bridged: Old: New: You can switch back the configs once you have successfully done what you needed to. Ran create-react-app again and it looked like it it would complete, despite the odd "warning There appears to be trouble with your network connection. Retrying..." Nope failed on ESOCKETTIMEDOUT, but just about there! Ran it again, success! Back to docker version, long story short it eventually successfully built. Good job I'm doing intermediate builds... Networks can be flaky, some more than others. I would like to see the following be able to be set in config: download_max_retry - does what it says on the tin and defaults to 20 Hope this helps and thanks for the tools! |
|
Getting a similar situation today. I'm running a
Then got
These were caused by connection issues, but once they resolved themselves I found myself unable to run the command for a few minutes. Running the command from a new terminal window instantly worked. |
|
These all look like DNS issues. I do not know why yarn saturates the DNS resolving though. I'll try to investigate this. |
**Summary** Fixes #746. Unfortunately neither Node, nor many systems come with built-in DNS caching so the many parallel requests that Yarn makes sometimes overwhelm the DNS servers, and most of the time, for the very same domain(s). Even worse, we pay the DNS look up cost for each request, which is quite sad at best. This patch introduces the `dnscache` module which intercepts all DNS look ups and answers them from an in-memory cache when possible. This applies to the built-in `http` and `https` modules, used by `request`. **Test plan** Exiting tests should pass, and hopefully be faster. Total number of DNS look ups should decrease dramatically.
**Summary** Fixes #746. Unfortunately, neither Node, nor many systems come with built-in DNS caching so the many parallel requests that Yarn makes sometimes overwhelm the DNS servers, and most of the time, for the very same domain(s). Even worse, we pay the DNS look up cost for each request, which is quite sad at best. This patch introduces the `dnscache` module which intercepts all DNS look ups and answers them from an in-memory cache when possible. This applies to the built-in `http` and `https` modules, used by `request`. **Test plan** Existing tests should pass, and hopefully be faster. Total number of DNS look ups should decrease dramatically.
**Summary** Fixes yarnpkg#746. Unfortunately, neither Node, nor many systems come with built-in DNS caching so the many parallel requests that Yarn makes sometimes overwhelm the DNS servers, and most of the time, for the very same domain(s). Even worse, we pay the DNS look up cost for each request, which is quite sad at best. This patch introduces the `dnscache` module which intercepts all DNS look ups and answers them from an in-memory cache when possible. This applies to the built-in `http` and `https` modules, used by `request`. **Test plan** Existing tests should pass, and hopefully be faster. Total number of DNS look ups should decrease dramatically.
|
Does look like a DNS issue. I have this issue using Rancher (that has complicated workarounds with DNS). UPDATE: Solved putting the stacks to use network the "bridge" - For me it is a temporary solution, because my environment is for tests. Inside the app that is inside the the Rancher environment Inside the app that is inside the the Rancher environment Inside the app that is inside the the Rancher environment Outside of Rancher (in docker machine) |
100mbps down, 26mbps up current internet speed test. ping 7ms. doesn't seem like a network issue. but yet again, yarn install and yarn start fails with ETIMEDOUT and it has done it randomly for a past year. running npm install starts up the app in ~10 seconds. Guess it was my last time to use yarn. |
and others
Do you want to request a feature or report a bug?
Not sure.
What is the current behavior?
I'm at an airport today, so I've been tethering on my phone and using in-flight WiFi. Every time I try to run
yarn, I eventually get asocket hang uperror on an arbitrary package. Presumably, it doesn't handle mobile connectivity very well.npm installworks in these same scenarios.If the current behavior is a bug, please provide the steps to reproduce.
What is the expected behavior?
Please mention your node.js, yarn and operating system version.
yarn v0.15.1
node v6.2.1
macOS v10.11.6
The text was updated successfully, but these errors were encountered: