-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Addresses memory issues related to new multi-instance approach #1836
Conversation
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.
Makes sense! Minor comment on CHANGELOG, then merge.
Fxed |
Did you run the test in #1835? Want to post numbers? |
@@ -6,7 +6,7 @@ module Grape | |||
# should subclass this class in order to build an API. | |||
class API | |||
# Class methods that we want to call on the API rather than on the API object | |||
NON_OVERRIDABLE = Class.new.methods.freeze | |||
NON_OVERRIDABLE = Class.new.methods.freeze + %i[call call!] |
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.
I think that this should be (Class.new.methods + %i[call call!]).freeze
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.
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.
Nice!
As part of the new multi-instance approach, class calls to the API are being intercepted, and stored so that they can be call as part of the setup to all instances.
However, when you are running the API in Rack, the method
call
is not part of the configuration, but an action. We do NOT want to store every time the methodcall
was called for security and memory management issues:Addresses: #1835