Skip to content

transient Async::Pool::Controller stays when the connection is closed #46

Closed
@PeterRunich

Description

@PeterRunich
#!/usr/bin/env -S falcon serve --bind http://localhost:7070 --count 1 -c
require 'async/websocket/adapters/rack'

run lambda { |env|
  Async::WebSocket::Adapters::Rack.open(env, protocols: ['ws']) do |connection|
    connection.send_close 4000
  end
}

I use this server for testing

require 'async'
require 'async/websocket'
require 'async/http'

Async do |task|
  begin
    endpoint = Async::HTTP::Endpoint.parse 'ws://localhost:7070/'
    connection = Async::WebSocket::Client.connect endpoint
    connection.read
  rescue
    connection.close
  end

  p task.print_hierarchy
end

After printing tasks hierarchy i got this

#<Async::Task:0x0000000000000280 connected to #<Addrinfo: [::1]:7070 TCP (localhost)> [fd=7] (running)>
→ /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:68:in `backtrace'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:68:in `backtrace'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/node.rb:268:in `print_backtrace'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/node.rb:261:in `block in print_hierarchy'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/node.rb:218:in `traverse_recurse'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/node.rb:214:in `traverse'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/node.rb:256:in `print_hierarchy'
  main.rb:71:in `block in <main>'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:107:in `block in run'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:248:in `block in schedule'
	#<Async::Task:0x0000000000000294 transient Async::Pool::Controller Gardener (running)>
	→ /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/scheduler.rb:79:in `transfer'
	  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/scheduler.rb:79:in `transfer'
	  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:45:in `yield'
	  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-pool-0.3.12/lib/async/pool/controller.rb:184:in `block in start_gardener'
	  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:107:in `block in run'
	  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.1/lib/async/task.rb:248:in `block in schedule'
#<Async::Children:0x2a8 size=1>

i expect that Async::Pool::Controller Gardener task was gone after connection.close, but it there

i do some fix and seems it works
#45

#<Async::Task:0x0000000000000a28 connected to #<Addrinfo: [::1]:7070 TCP (localhost)> [fd=7] (running)>
→ /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/task.rb:68:in `backtrace'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/task.rb:68:in `backtrace'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/node.rb:269:in `print_backtrace'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/node.rb:262:in `block in print_hierarchy'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/node.rb:219:in `traverse_recurse'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/node.rb:215:in `traverse'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/node.rb:257:in `print_hierarchy'
  main.rb:71:in `block in <main>'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/task.rb:107:in `block in run'
  /home/pepe/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/async-2.3.0/lib/async/task.rb:248:in `block in schedule'
#<Async::Children size=0>

Is the behavior in the original considered okay? If "yes", can you explain why?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions