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

Replace def #{type}_func with define_singleton_method #4298

Closed
wants to merge 1 commit into from

Conversation

ph
Copy link
Contributor

@ph ph commented Dec 2, 2015

When you run multiples pipeline and the config code get evaluated, on
every evaluation the class cached is clear, everytime you were calling a
func method you had the latest evaluated code. The filter_func and
the output_func need to be unique for every instance of the pipeline,
this PR replace the def with a define_single_method call ensuring
the uniqueness of the code on every instance.

This PR is based on #4254

@ph ph added the v2.2.0 label Dec 2, 2015
@ph ph changed the title Fix/allow multiples pipeline config Replace def #{type}_func with define_singleton_method Dec 2, 2015
@ph ph force-pushed the fix/allow-multiples-pipeline-config branch 2 times, most recently from 693f709 to 6cf2950 Compare December 2, 2015 21:55
@andrewvc
Copy link
Contributor

andrewvc commented Dec 2, 2015

LGTM, just waiting for #4254 to merge in

@purbon
Copy link
Contributor

purbon commented Dec 3, 2015

@andrewvc @ph I think this change is not just for your #4254, right? I can also go to master now, right? If not, can we point this PR to your PR and merge it there? or also point it to the feature branch? then we don't have to wait.

what do you say?

@purbon
Copy link
Contributor

purbon commented Dec 3, 2015

@ph having @andrewvc commits in this PR it does really make the review more complicated. hard to spot where are your changes for example. I would recommend to simplify the dependency as I shared in my previous comment.

@@ -15,6 +15,21 @@ def close
end
end

class DummyInputGenerator < LogStash::Inputs::Base
Copy link
Contributor

Choose a reason for hiding this comment

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

we install the generator plugin as part of the core plugins need for test, https://github.com/elastic/logstash/blob/master/rakelib/default_plugins.rb#L113-L121 any reason not to redefined here? you know I would like our make our test plugin free, only use mocks/stubs/dummy (pick your name), but if we require it for now I think it would be better to stick to one usage. what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking to use the generator but I have checked the logstash-core gemspec and it doesn't include the generator plugin and the only test in logstash-core that require the generator is the pipeline_reporter_spec.

Its not obvious that the generator is available in the context of theses specs 😞

Copy link
Contributor

Choose a reason for hiding this comment

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

I know is not obvious, is in the file I shared, 👍 I understand. I think we should have only 1 way if possible, right? what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, lets keep the DummyGenerator, since we don't need a dependency for that and you were proposing to move away. This also in line with the actual dummy plugin in the current pipeline_spec

Copy link
Contributor

Choose a reason for hiding this comment

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

are we already ok on going away from plugins to be used in specs? I don't think we agreed, even if I love the idea. not sure what to think.

@ph
Copy link
Contributor Author

ph commented Dec 3, 2015

@purbon Concerning this PR against master vs the branch, let me check If I can do it agains't master.

@ph
Copy link
Contributor Author

ph commented Dec 3, 2015

I will remake this PR against master

@ph
Copy link
Contributor Author

ph commented Dec 3, 2015

@purbon It can be done, but the test would change, so lets keep it for #4254

@purbon
Copy link
Contributor

purbon commented Dec 3, 2015

@ph then I would recommend to point to @andrewvc branch/PR/whatever. It makes no sense we wait to incorporate this if is good enoughts. makes sense? @andrewvc what do you think?

@ph ph force-pushed the fix/allow-multiples-pipeline-config branch 2 times, most recently from 9dd0d6f to d4bea94 Compare December 3, 2015 15:24
@ph
Copy link
Contributor Author

ph commented Dec 3, 2015

updated with the review, @andrewvc do you want to cherry-pick this or I can create the PR against a feature branch?

@ph ph mentioned this pull request Dec 3, 2015
@andrewvc
Copy link
Contributor

andrewvc commented Dec 3, 2015

@ph well, I don't want to reopen the pr for #4254 so maybe we can wait till that gets in master? I think I can address all of the open concerns today.

PRs against PRs are hard :(

@ph
Copy link
Contributor Author

ph commented Dec 3, 2015

@andrewvc np I will rebase, when @purbon gives his lgtm.

@purbon
Copy link
Contributor

purbon commented Dec 3, 2015

LGTM

@andrewvc
Copy link
Contributor

Hey @ph are you planning on rebasing this?

@ph ph force-pushed the fix/allow-multiples-pipeline-config branch 2 times, most recently from 43b012a to b259cdd Compare January 5, 2016 14:29
@ph
Copy link
Contributor Author

ph commented Jan 5, 2016

rebased with master @andrewvc !

@@ -47,6 +47,10 @@ def initialize(params={})

def register
end

def threadsafe?
false
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this currently exists as an API. In https://github.com/elastic/logstash/pull/4391/files#diff-3d93d6656c81049b6de7a09dbe141a46R30 I added a new method Outputs/Base.declare_threadsafe! that would declare this at the class level.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

let me check that, if its needed, I think I had an error without it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You were right, I think at the time I have created the pr it was required.

@ph ph force-pushed the fix/allow-multiples-pipeline-config branch from b259cdd to 4d83693 Compare January 5, 2016 16:27
@ph
Copy link
Contributor Author

ph commented Jan 5, 2016

updated with your comment @andrewvc

let(:pipeline2) { LogStash::Pipeline.new("input { generator {} } filter { dummyfilter {} } output { dummyoutput {}}") }

it "should handle evaluating different config" do
expect(pipeline1.output_func(LogStash::Event.new)).not_to include(nil)
Copy link
Contributor

Choose a reason for hiding this comment

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

This could use a comment explaining why we're checking for it not to be nil.

@andrewvc
Copy link
Contributor

andrewvc commented Jan 5, 2016

Could use an explanatory comment, but after that LGTM!

When you run multiples pipeline and the config code get evaluated, on
every evaluation the class cached is clear, everytime you were calling a
`func` method you had the latest evaluated code. The `filter_func` and
the `output_func` need to be unique for every instance of the pipeline,
this PR replace the `def` with a `define_single_method` call ensuring
the uniqueness of the code on every instance.

This PR is based on #4254
@ph ph force-pushed the fix/allow-multiples-pipeline-config branch from 4d83693 to c032468 Compare January 5, 2016 17:01
@ph
Copy link
Contributor Author

ph commented Jan 5, 2016

Added a comment!

@elasticsearch-bot
Copy link

Pier-Hugues Pellerin merged this into the following branches!

Branch Commits
master 9d876fa
2.x da26b88
2.2 27e675c

ph added a commit that referenced this pull request Jan 6, 2016
When you run multiples pipeline and the config code get evaluated, on
every evaluation the class cached is clear, everytime you were calling a
`func` method you had the latest evaluated code. The `filter_func` and
the `output_func` need to be unique for every instance of the pipeline,
this PR replace the `def` with a `define_single_method` call ensuring
the uniqueness of the code on every instance.

This PR is based on #4254

Fixes #4298
@ph ph closed this in 9d876fa Jan 6, 2016
ph added a commit that referenced this pull request Jan 6, 2016
When you run multiples pipeline and the config code get evaluated, on
every evaluation the class cached is clear, everytime you were calling a
`func` method you had the latest evaluated code. The `filter_func` and
the `output_func` need to be unique for every instance of the pipeline,
this PR replace the `def` with a `define_single_method` call ensuring
the uniqueness of the code on every instance.

This PR is based on #4254

Fixes #4298
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants