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

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

Merged
merged 4 commits into from Mar 1, 2016
Merged

Conversation

matthewd
Copy link
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
Copy link
Member

😱💚

@rafaelfranca
Copy link
Member

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

@matthewd matthewd force-pushed the executor branch 11 times, most recently from 3eb9b6f to 5292095 Compare February 25, 2016 04:07
@matthewd matthewd force-pushed the executor branch 3 times, most recently from c5d3889 to 7a9c43d Compare February 27, 2016 11:15
@matthewd matthewd changed the title [WIP] Publish AS::Executor and AS::Reloader APIs Publish AS::Executor and AS::Reloader APIs Feb 27, 2016
<%- unless options[:skip_action_cable] -%>

# Action Cable requires that all classes are loaded in advance
Rails.application.eager_load!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this not needed anymore?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@kaspth
Copy link
Contributor

kaspth commented Feb 29, 2016

Love this ❤️

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 ActionDipatch.
matthewd added a commit that referenced this pull request Mar 1, 2016
Publish AS::Executor and AS::Reloader APIs
@matthewd matthewd merged commit 541e4ab into rails:master Mar 1, 2016
@jeremy
Copy link
Member

jeremy commented Mar 1, 2016

🤘

@mikhailov
Copy link
Contributor

👍 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 pushed a commit that referenced this pull request Mar 2, 2016
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.
@spastorino
Copy link
Contributor

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
Copy link
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
Copy link
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
Copy link

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 added a commit to willnet/rails that referenced this pull request May 1, 2016
…n guides [ci skip]

Guides should be updated because ActionDispatch::LoadInterlock was replaced with
ActionDispatch::Executor at rails#23807.
jeremy pushed a commit that referenced this pull request May 1, 2016
…n guides [ci skip]

Guides should be updated because ActionDispatch::LoadInterlock was replaced with
ActionDispatch::Executor at #23807.
@arthurnn
Copy link
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
Copy link

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.

@matthewd matthewd deleted the executor branch June 11, 2017 23:20
joecorcoran added a commit to travis-ci/travis-api that referenced this pull request Feb 20, 2018
joecorcoran added a commit to travis-ci/travis-api that referenced this pull request Feb 20, 2018
joecorcoran added a commit to travis-ci/travis-api that referenced this pull request Feb 21, 2018
joecorcoran added a commit to travis-ci/travis-api that referenced this pull request Feb 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet