Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Establishing websocket connection in Rails app using ActionCable causes error #106

Closed
deepj opened this issue Mar 13, 2020 · 12 comments
Closed

Comments

@deepj
Copy link
Contributor

deepj commented Mar 13, 2020

Started GET "/cable" for ::1 at 2020-03-13 10:03:58 +0100
Started GET "/cable/" [WebSocket] for ::1 at 2020-03-13 10:03:58 +0100
Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: keep-alive, Upgrade, HTTP_UPGRADE: websocket)
Finished "/cable/" [WebSocket] for ::1 at 2020-03-13 10:03:59 +0100
 9m12s    error: Async::Task [oid=0xd9a8] [pid=42462] [2020-03-13 10:03:59 +0100]
               |   Errno::EPIPE: Broken pipe
               |   → <internal:io> 121
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/generic.rb:216 in `async_send'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/generic.rb:62 in `block in wrap_blocking_method'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/generic.rb:156 in `write'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/stream.rb:258 in `block in drain_write_buffer'
               |     ~/.gem/ruby/2.7.0/gems/async-1.24.2/lib/async/semaphore.rb:80 in `acquire'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/stream.rb:247 in `drain_write_buffer'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/stream.rb:160 in `flush'
               |     ~/.gem/ruby/2.7.0/gems/protocol-http1-0.10.1/lib/protocol/http1/connection.rb:277 in `write_fixed_length_body'
               |     ~/.gem/ruby/2.7.0/gems/protocol-http1-0.10.1/lib/protocol/http1/connection.rb:332 in `write_body'
               |     ~/.gem/ruby/2.7.0/gems/async-http-0.50.2/lib/async/http/protocol/http1/server.rb:91 in `each'
               |     ~/.gem/ruby/2.7.0/gems/async-http-0.50.2/lib/async/http/server.rb:53 in `accept'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/server.rb:32 in `block in accept_each'
               |     ~/.gem/ruby/2.7.0/gems/async-io-1.27.3/lib/async/io/socket.rb:73 in `block in accept'
               |     ~/.gem/ruby/2.7.0/gems/async-1.24.2/lib/async/task.rb:258 in `block in make_fiber'
@ioquatix
Copy link
Member

Can you give me source code so I can repro?

@deepj
Copy link
Contributor Author

deepj commented Mar 25, 2020

Hm, I have troubles to reproduce it on a freshly generated Rails app. On the original app this is happening only more very random with the latest Falcon :(

@ioquatix
Copy link
Member

It looks like hijack is not working correctly

@ioquatix
Copy link
Member

Can you try the latest release.

@deepj
Copy link
Contributor Author

deepj commented Apr 10, 2020

@ioquatix tried, but no change :(

@deepj
Copy link
Contributor Author

deepj commented Apr 22, 2020

@ioquatix I've tried 0.36.3 for the last days and it seems the problem is gone. So I guess this can be closed

In fact, it's not true, it occurred again very randomly :(

@ioquatix
Copy link
Member

Do you have some time to peer on this?

@nare06
Copy link

nare06 commented May 27, 2020

Screen Shot 2020-05-27 at 10 02 43 PM

On falcon serve, I do find this issue. Not sure where the issue is.

Screen Shot 2020-05-27 at 10 03 03 PM

@ioquatix
Copy link
Member

Thanks for the report, I will investigate.

@ioquatix
Copy link
Member

I see the problem here: https://github.com/socketry/falcon/blame/45ca2be3cc8228e491b7b7298c228c2ba777ddc3/lib/falcon/adapters/rack.rb#L205

It's returning nil when there is a full hijack. At least, this seems somewhat wrong.

@ioquatix
Copy link
Member

The error message is somewhat misleading since it only kills the request task and not the underlying connection, which should be working correctly. In any case, I'll introduce a dedicated exception for this case.

@ioquatix
Copy link
Member

ioquatix commented Apr 23, 2021

This should be fixed (I tested it a bit), however full hijack will present an exception in the log since it terminates the normal request flow control using an exception and I don't want to handle this case explicitly in async-http as I actually want to minimise the blast radius of the full hijack feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants