-
Notifications
You must be signed in to change notification settings - Fork 21.7k
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
Conversation
😱💚 |
This is really promising. I like the API and the implementation is simple. 👍 |
3eb9b6f
to
5292095
Compare
c5d3889
to
7a9c43d
Compare
<%- unless options[:skip_action_cable] -%> | ||
|
||
# Action Cable requires that all classes are loaded in advance | ||
Rails.application.eager_load! |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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.
Publish AS::Executor and AS::Reloader APIs
🤘 |
👍 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) |
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.
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 |
Would there be any benefit to using |
This changed the QueryCache to be an executor instead of a middleware. |
I see you touched Does this pull request resolve the problem? If not, what is "the right way" to approach the problem? Related questions in stackoverflow: |
…n guides [ci skip] Guides should be updated because ActionDispatch::LoadInterlock was replaced with ActionDispatch::Executor at rails#23807.
…n guides [ci skip] Guides should be updated because ActionDispatch::LoadInterlock was replaced with ActionDispatch::Executor at #23807.
@arthurnn Well, I created an issue in Thin and the author resolved the problem by finishing requests in the same thread that starts them. |
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:
.. and we'll take care of the interlock, code reloading, returning AR connections to the pool, and anything else that might be relevant.