-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Improved semantics for OutputDelegator #4391
Improved semantics for OutputDelegator #4391
Conversation
This commit greatly improves the semantics for the OutputDelegator. It now: * Has an API for declaring if an output is threadsafe to avoid instance creation * By default sets the number of workers for an output to be == the number of pipeline workers * Moves the worker safe API to the class, not instance level * Strongly enforces the worker safety API * Should provide better performance for threadsafe plugins
@andrewvc this can be for post 2.2, right? |
Yes, it can be! I'd love to get this in for 2.3 however. |
Reviewing today. |
Thanks @ph! |
# The user has configured extra workers, but this plugin doesn't support it :( | ||
if @config["workers"] && @config["workers"] > 1 && @klass.workers_not_supported? | ||
message = @workers_not_supported_message | ||
if message |
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.
Do we really need to create a new variable message
here we could use @workers_not_supported_message
directly?
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.
This line is actually erroneous, it should be pulled from @klass
. Will be updated in my next push
Added minors comments, I haven't tested with actual plugins yet. But before we run real world config, can we add a few tests to showcase what happen with the different workers settings and the different options set from the plugin? I am looking at the interaction between |
else | ||
klass.new(*args) | ||
end | ||
end | ||
|
||
def default_output_workers | ||
@settings[:pipeline_workers] || @settings[:default_pipeline_workers] | ||
end |
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.
Do we really need to have a check for this? The DEFAULT_SETTINGS
already have a default settings configured?
I think the fallback to defaults should be done in one place https://github.com/elastic/logstash/pull/4391/files#diff-bc1e9ea81caa54ea0d56abf4415fdf00R34 ? WDYT?
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.
This I think is separate, because default_output_workers
is semantically different from default_pipeline_workers
, yet it must move in lock-step with the default value of the pipeline workers. Are you sure you aren't confusing the two? IMHO this is the correct place for this.
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 you are right, I was effectively confusing the two, move along!
6ee6427
to
3900785
Compare
Backwards compatibility is now implemented for existing workers_not_supported uses. This clears up a few bugs in the initial pass as well.
3900785
to
9ab024d
Compare
I volunteer @jsvd as the second reviewer. I don't understand the internals to this extent :) |
reviewing :) |
# | ||
# Older plugins invoke the instance method Outputs::Base#workers_not_supported | ||
# To detect these we need an instance to be created first :() | ||
# TODO: In the next major version after 2.x remove support for this |
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.
Yay for backward compatibility
@andrewvc Much improvements! we are coming a long way! sir. |
@andrewvc Looking good for me, I'll do a bit of manual testing tomorrow morning. |
…LS > 2.2 API changes Fixes #4391
We were getting some bizzare errors (#4391 (comment)) on the file output with the new OutputDelegator changes. By switching away from method(:mymethod) to blocks with define_singleton_method they went away. This bug is only present with Jruby 1.7.x (tested with 1.7.22 and 1.7.23). Jruby 9.x is fine. Fixes #4391
…he semantics for the OutputDelegator. It now: * Has an API for declaring if an output is threadsafe to avoid instance creation * By default sets the number of workers for an output to be == the number of pipeline workers * Moves the worker safe API to the class, not instance level * Strongly enforces the worker safety API * Should provide better performance for threadsafe plugins Fixes #4391
Backwards compatibility is now implemented for existing workers_not_supported uses. This clears up a few bugs in the initial pass as well. Fixes #4391
…LS > 2.2 API changes Fixes #4391
We were getting some bizzare errors (#4391 (comment)) on the file output with the new OutputDelegator changes. By switching away from method(:mymethod) to blocks with define_singleton_method they went away. This bug is only present with Jruby 1.7.x (tested with 1.7.22 and 1.7.23). Jruby 9.x is fine. Fixes #4391
Backwards compatibility is now implemented for existing workers_not_supported uses. This clears up a few bugs in the initial pass as well. Fixes #4391
…LS > 2.2 API changes Fixes #4391
We were getting some bizzare errors (#4391 (comment)) on the file output with the new OutputDelegator changes. By switching away from method(:mymethod) to blocks with define_singleton_method they went away. This bug is only present with Jruby 1.7.x (tested with 1.7.22 and 1.7.23). Jruby 9.x is fine. Fixes #4391
This commit greatly improves the semantics for the OutputDelegator. It
now:
number of pipeline workers (for non-threadsafe outputs)
This commit is built on top of some of the ideas in #4367