Publish AS::Executor and AS::Reloader APIs #23807

Merged
merged 4 commits into from Mar 1, 2016

Projects

None yet
@matthewd
Member

These should allow external code to run blocks of user code to do "work", at a similar unit size to a web request, without needing to get intimate with ActionDispatch.

The theory is that interested callers (Sidekiq, ActionCable) can just do:

Rails.application.reloader.wrap do
  # run some user code
end

.. and we'll take care of the interlock, code reloading, returning AR connections to the pool, and anything else that might be relevant.

@matthewd matthewd self-assigned this Feb 22, 2016
@matthewd matthewd added this to the 5.0.0 milestone Feb 22, 2016
@vipulnsward
Member

😱💚

@rafaelfranca
Member

This is really promising. I like the API and the implementation is simple. 👍

@matthewd matthewd changed the title from [WIP] Publish AS::Executor and AS::Reloader APIs to Publish AS::Executor and AS::Reloader APIs Feb 27, 2016
@rafaelfranca rafaelfranca commented on the diff Feb 29, 2016
...es/lib/rails/generators/rails/app/templates/config.ru
@@ -1,10 +1,4 @@
# This file is used by Rack-based servers to start the application.
require ::File.expand_path('../config/environment', __FILE__)
-<%- unless options[:skip_action_cable] -%>
-
-# Action Cable requires that all classes are loaded in advance
-Rails.application.eager_load!
@rafaelfranca
rafaelfranca Feb 29, 2016 Member

Is this not needed anymore?

@rafaelfranca
rafaelfranca Feb 29, 2016 Member

Ah. it was because Action Cable, yeah, it is not needed.

@kaspth
Member
kaspth commented Feb 29, 2016

Love this ❤️

@matthewd matthewd merged commit 541e4ab into rails:master Mar 1, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jeremy
Member
jeremy commented Mar 1, 2016

🤘

@mikhailov

👍 Since we have an option to reload user code what you think to enhance the functionality to avoid unnecessary reload for static assets (idea came from #23518)

@spastorino spastorino pushed a commit that referenced this pull request Mar 2, 2016
Jorge Bejar and Santiago Pastorino Do not run app.executor callbacks in integration tests
This reverts changes made to integration tests in PR #23807.
The issue happens when using capybara with a driver that needs to start a
server in a separate thread like (poltergeist, selenium, etc).
Both threads the capybara server one and the test thread end running
syncronize over the interlock.
cf075d9
@spastorino
Member

The integration.rb part of the changes introduces an issue when using capybara with a driver that needs to start a server in a separate thread like poltergeist, selenium, etc.

Both threads, the test thread and the capybara server one run synchronize over the interlock so the server can't execute when receives the request because it's locked.

I don't know what was the intention of the changes in integration.rb were but doesn't seem to have sense, given that all it adds is this lock and QueryCache which doesn't make much sense per integration test as it's working with this changes.

Fixed here cf075d9

@mperham
Contributor
mperham commented Mar 5, 2016

Would there be any benefit to using call instead of wrap as the method name? More idiomatic or reusable?

@arthurnn
Member

This changed the QueryCache to be an executor instead of a middleware.
Before, to disable QueryCache in a rails app, I could just remove the middleware. (config.middleware.delete "ActiveRecord::QueryCache"). How can I disable it now? should we add some way to?

@mrrusof
mrrusof commented Apr 20, 2016

I see you touched ActiveRecord::ConnectionAdapters::ConnectionManagement. I'm in the process of figuring out how to reconcile Sinatra+Thin+ActiveRecord. The problem is that ConnectionManagement in ActiveRecord 4.2.6 does not return connections to the pool when used by Thin 1.6.4. ConnectionManagement returns to the pool those connections that are active and belong to the current thread. For each request, Thin connects to the database in a thread and applies ConnectionManagement in another.

Does this pull request resolve the problem? If not, what is "the right way" to approach the problem?

Related questions in stackoverflow:

@willnet willnet added a commit to willnet/rails that referenced this pull request May 1, 2016
@willnet willnet Replace ActionDispatch::LoadInterlock with ActionDispatch::Executor i…
…n guides [ci skip]

Guides should be updated because ActionDispatch::LoadInterlock was replaced with
ActionDispatch::Executor at #23807.
d6205e0
@jeremy jeremy added a commit that referenced this pull request May 1, 2016
@willnet @jeremy willnet + jeremy Replace ActionDispatch::LoadInterlock with ActionDispatch::Executor i…
…n guides [ci skip]

Guides should be updated because ActionDispatch::LoadInterlock was replaced with
ActionDispatch::Executor at #23807.
0725f28
@Neodelf Neodelf added a commit to Neodelf/rails that referenced this pull request May 5, 2016
@willnet @Neodelf willnet + Neodelf Replace ActionDispatch::LoadInterlock with ActionDispatch::Executor i…
…n guides [ci skip]

Guides should be updated because ActionDispatch::LoadInterlock was replaced with
ActionDispatch::Executor at #23807.
b397e1d
@arthurnn
Member

Does this pull request resolve the problem? If not, what is "the right way" to approach the problem?

@mrrusof I dont think it does. There is #24608 for instance to deal with connection pool, etc. if thats what you are asking.

@mrrusof
mrrusof commented May 30, 2016

@arthurnn Well, I created an issue in Thin and the author resolved the problem by finishing requests in the same thread that starts them.

@flyfy1

Why the prepare method is to run after the :run, but not before?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment