Webpacker: Getting Errno::ETIMEDOUT

[mmaauu]

Hi! I've added the webpacker gem, after bundle install with the gem, I run rails s and I'm getting this error, I can't figure out what's going on.
Thanks!

Puma caught this error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. - user specified timeout (Errno::ETIMEDOUT) c:/RailsInstaller/Ruby2.3.0/lib/ruby/2.3.0/socket.rb:61:in `connect_internal' c:/RailsInstaller/Ruby2.3.0/lib/ruby/2.3.0/socket.rb:139:in `connect' c:/RailsInstaller/Ruby2.3.0/lib/ruby/2.3.0/socket.rb:636:in `block in tcp' c:/RailsInstaller/Ruby2.3.0/lib/ruby/2.3.0/socket.rb:231:in `each' c:/RailsInstaller/Ruby2.3.0/lib/ruby/2.3.0/socket.rb:231:in `foreach' c:/RailsInstaller/Ruby2.3.0/lib/ruby/2.3.0/socket.rb:626:in `tcp' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/webpacker-3.0.0/lib/webpacker/dev_server.rb:9:in `running?' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/webpacker-3.0.0/lib/webpacker/dev_server_proxy.rb:7:in `rewrite_response' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/rack-proxy-0.6.2/lib/rack/proxy.rb:57:in `call' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/railties-5.1.3/lib/rails/engine.rb:522:in `call' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/puma-3.10.0/lib/puma/configuration.rb:225:in `call' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/puma-3.10.0/lib/puma/server.rb:605:in `handle_request' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/puma-3.10.0/lib/puma/server.rb:437:in `process_client' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/puma-3.10.0/lib/puma/server.rb:301:in `block in run' c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/puma-3.10.0/lib/puma/thread_pool.rb:120:in `block in spawn_thread'

[gauravtiwari]

@mmaauu Are you using latest webpacker?

[gauravtiwari]

We just released 3.0.1, consider upgrading and see if it fixes the problem. You are not running webpack-dev-server though, right?

[mmaauu]

Thanks @gauravtiwari for your response, I've updated the gem ( $ bundle show webpacker
c:/RailsInstaller/Ruby2.3.0/lib/ruby/gems/2.3.0/gems/webpacker-3.0.1 ), but without luck, same error.

I'm just trying to install webpacker gem to start using it with react, I'm not using webpack-dev-server.

[gauravtiwari]

@mmaauu Thanks for confirming. Not sure why it's proxying to dev server then. Can you share your example on github please?

[javan]

Looks like we might need to rescue from Errno::ETIMEDOUT here too?
https://github.com/rails/webpacker/blob/fb8dd8c09ccc9d93ef3e084838e6e0f0683aaeb0/lib/webpacker/dev_server.rb#L8-L13

Side note: It's unfortunate if dev_server.running? is taking 1s just to determine that it's not running.

[mmaauu]

@javan I've made an example, same issue, please check this:
https://github.com/mmaauu/webpack-example

[swrobel]

Same issue here, had it on 3.0 and now 3.0.1 using default config. I was previously using a separate dev server process but was attempting to use the new 3.x functionality that doesn't require it. On the frontend, when I try to load http://localhost:3000/packs/application-02bd72f5b4651ad6eea4.js individually I get a 404 error

[gauravtiwari]

@mmaauu Just cloned your repo and everything seems to be running fine. @javan Yeah, make sense or we increase the timeout?

@swrobel Are you using windows? If you are not running dev server then the on-demand compiler should compile and rails server should serve assets for you. Just make sure your webpacker.yml has compile: true in development.

[swrobel]

I am on macOS and as I said I’m using the default config so yes it has compile true

[Bramjetten]

I'm experiencing the same thing on the High Sierra beta 9.

Adding rescue Errno::ETIMEDOUT to def running? partially fixes it. JavaScript is compiled, but requests take a long time (3-5 secs).

This takes about 2 seconds to raise an error on High Sierra when the webpack dev server is off:
$ curl localhost:3035

In the running? method the timeout is set to 1s, which means ruby raises Errno::ETIMEDOUT before ERR_CONNECTION_REFUSED is raised by macOS.

In my app I'm adding a monkey patch to have running? always return false so I can get back to work, but I'm curious to find out what causes this.

[swrobel]

Completely forgot that I'm on High Sierra beta as well.

[javan]

Does it work when bin/webpack-dev-server is running? Also curious if using a newer ruby version helps.

[Bramjetten]

If webpack-dev-server is running it's fast. Using ruby 2.4.1. Is there a different way to determine if the dev server is running besides waiting for the connection to timeout?

[javan]

Not sure, but that would be ideal. Could look into writing a tmp file when bin/webpack-dev-server starts/stops.

[gauravtiwari]

I guess we just need to catch Errno::ETIMEDOUT and that should fix the timeout problem👍

JavaScript is compiled, but requests take a long time (3-5 secs).

@Bramjetten What's the size of your app?

[gauravtiwari]

JavaScript is compiled, but requests take a long time (3-5 secs).

This could also be related to:

This takes about 2 seconds to raise an error on High Sierra when the webpack dev server is off:
$ curl localhost:3035

i.e. running? is adding 2-3s overhead on each request hence taking long time.

[javan]

In addition to rescuing Errno::ETIMEDOUT, it looks like we can specify a lower connect_timeout option. Here's an example (with the dev server running):

>> Socket.tcp('localhost', 3035, connect_timeout: 1).close
=> nil

>> Socket.tcp('localhost', 3035, connect_timeout: 0.1).close
=> nil

>> Socket.tcp('localhost', 3035, connect_timeout: 0.0001).close
=> nil

>> Socket.tcp('localhost', 3035, connect_timeout: 0.000001).close
Errno::ETIMEDOUT: Operation timed out - user specified timeout

I suggest changing it from 1 to 0.1 to start.

[Bramjetten]

That looks like the way to go. In my tests I saw that running? was called 3 times for a single request, that's why it took 3 extra seconds for each request. Changing it to 0.1 would mean an extra 300ms for each request which is a great improvement already. Ideally we'd call running? fewer times.

[mmaauu]

Hi @gauravtiwari! I can't find the issue to make it work, I'm running on windows 7, do you have any idea? Thanks!!

[javan]

Curious why High Sierra hits a timeout (Errno::ETIMEDOUT) vs. connection refused (Errno::ECONNREFUSED) on Sierra. Can you try higher port numbers (4XXX, 5XXX, etc) and see if that changes anything? Did you install Ruby after upgrading your OS or did it carry over from Sierra?

[Bramjetten]

Same for other port numbers. Same for everything I give curl actually. Ruby was carried over.

Op 4 sep. 2017 om 18:43 heeft Javan Makhmali [e-mail] het volgende geschreven:

Curious why High Sierra hits a timeout (Errno::ETIMEDOUT) vs. connection refused (Errno::ECONNREFUSED) on Sierra. Can you try higher port numbers (4XXX, 5XXX, etc) and see if that changes anything? Did you install Ruby after upgrading your OS or did it carry over from Sierra?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[javan]

Any change if you reinstall curl and/or Ruby? Wonder if it needs to be recompiled against updated system libs. Just shooting in the dark here. :)

[swrobel]

Tested the same code on another Mac running Sierra (10.12.6) and it's working just fine so this definitely seems to be a High Sierra issue.

[BrianTatum]

@mmaauu Did you ever find a solution to this for Windows? I have the same problem on Windows 10.

[mmaauu]

@BrianTatum, I've changed this into the webpacker/lib/webpacker/dev_server.rb, I added this line, hope this helps.

def running?
    Socket.tcp(host, port, connect_timeout: 1).close
    true
   rescue Errno::ETIMEDOUT  # ADDED
    true
  rescue Errno::ECONNREFUSED, NoMethodError
    false   
end

[javan]

This was fixed in https://github.com/rails/webpacker/pull/753, but hasn't been released yet. You can use it now by pointing your Gemfile to github: 'rails/webpacker'.

[BrianTatum]

@javan Looks like that did fix it in it Windows 10. Thanks!! What is your schedule for releasing versions?

[davidteren]

Had the same issue on High Sierra and pointing my Gemfile to github: 'rails/webpacker' fixes it.

[fgermanojr]

I just upgraded to high sierra on mac. Stuff was running before. Now get the above mentioned error.
What does "pointing my Gemfile to github: 'rails/webpacker'" exactly mean. Do I put this in some form on the gem 'webpacker' line.

---

My Environment is a bit of a cludge. Currently running rails 5.1.3. react_on_rails 9 or 10, and ruby 2.4.2. I need to do a clean reconstruction to be sure of what I have. I worry about interaction between react_on_rails gem and the changing way rails is doing this. Aside from this problem version skew issues may remain. We need some clean set up docs for react_on_rails 9 vs 10.
In time I hope to help with this.

[gauravtiwari]

bundle update webpacker should fix it, since this got out in last release 3.0.2

[fgermanojr]

Thanks. I made a few changes in versions (react_on_rails to 9, ruby to 2.3.4) and it comes up.
gem list is showing webpacker 3.0.1 and 3.0.1. I will follow your suggesting and be sure to have webpacker at 3.0.2.

[gauravtiwari]

👍

[navjeetc]

I had the same issue in Windows (WSL-Ubuntu 16.04) and running bundle update webpacker fixed the issue