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

Improved semantics for OutputDelegator #4391

Closed

Conversation

andrewvc
Copy link
Contributor

This commit greatly improves the semantics for the OutputDelegator. It
now:

  • Has an API for declaring if an output is threadsafe which lets us economize on the number of instances (we only need one shared across N threads)
  • By default sets the number of workers for an output to be == the
    number of pipeline workers (for non-threadsafe outputs)
  • Moves the worker_safe API (which declares whether the plugin supports > 1 workers) to the class, not instance level
  • Strongly enforces the worker safety API. Previously a warning would be logged but nothing else.
  • Should Provide better performance for threadsafe plugins. A plugin like the file output should only need a mutex around the file write and could be written to be threadsafe. This opens the door to multiple threads running, say, their codecs simultaneously.

This commit is built on top of some of the ideas in #4367

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
@suyograo
Copy link
Contributor

suyograo commented Jan 3, 2016

@andrewvc this can be for post 2.2, right?

@andrewvc
Copy link
Contributor Author

andrewvc commented Jan 4, 2016

Yes, it can be! I'd love to get this in for 2.3 however.

@ph
Copy link
Contributor

ph commented Jan 4, 2016

Reviewing today.

@suyograo suyograo added v2.3.0 and removed v2.2.0 labels Jan 4, 2016
@andrewvc
Copy link
Contributor Author

andrewvc commented Jan 4, 2016

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

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?

Copy link
Contributor Author

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

@ph
Copy link
Contributor

ph commented Jan 5, 2016

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 threadsafe_multi_receive and worker_multi_receive and the actual plugin. I think we could benefit by having them.

else
klass.new(*args)
end
end

def default_output_workers
@settings[:pipeline_workers] || @settings[:default_pipeline_workers]
end
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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!

@andrewvc andrewvc changed the title [WIP] Improved semantics for OutputDelegator Improved semantics for OutputDelegator Jan 5, 2016
@andrewvc andrewvc force-pushed the better-enforced-output-delegator branch from 6ee6427 to 3900785 Compare January 5, 2016 22:59
@andrewvc
Copy link
Contributor Author

andrewvc commented Jan 5, 2016

@ph I've removed the WIP designation and have added some real tests. How's it look now?

@suyograo would you be interested in being a second reviewer?

Backwards compatibility is now implemented for existing workers_not_supported uses.

This clears up a few bugs in the initial pass as well.
@andrewvc andrewvc force-pushed the better-enforced-output-delegator branch from 3900785 to 9ab024d Compare January 5, 2016 23:06
@suyograo
Copy link
Contributor

suyograo commented Jan 5, 2016

I volunteer @jsvd as the second reviewer. I don't understand the internals to this extent :)

@ph
Copy link
Contributor

ph commented Jan 6, 2016

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

Choose a reason for hiding this comment

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

Yay for backward compatibility

@ph
Copy link
Contributor

ph commented Jan 6, 2016

@andrewvc Much improvements! we are coming a long way! sir.

@ph
Copy link
Contributor

ph commented Jan 6, 2016

@andrewvc Looking good for me, I'll do a bit of manual testing tomorrow morning.

andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
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
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
…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
andrewvc added a commit that referenced this pull request Jan 7, 2016
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
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
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
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
@andrewvc andrewvc closed this in 57f8b65 Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
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
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
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
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
andrewvc added a commit that referenced this pull request Jan 7, 2016
@suyograo suyograo added v2.2.0 and removed v2.3.0 labels Jan 12, 2016
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

6 participants