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

fix for accessors lut invalidation #5132

Merged
merged 1 commit into from
Apr 25, 2016

Conversation

colinsurprenant
Copy link
Contributor

@colinsurprenant colinsurprenant commented Apr 18, 2016

This is a fix for the Accessors fieldref cache invalidation in the Ruby Event only. Before considering merging this we should assess the performance impact and see if using a hierarchical cache would provide better performance. Depending on the direction we choose for the fix, the same idea will have to be applied to the Java Event.

A stale cache spec has been added.

Fixes #5127

[edit 04/20]
Per comments below, we agreed that this fix is acceptable performance-wise and the same fix has been applied to the Java Event. Doing so uncovered another bug that resulted in a expecting List or Map ClassCastException, also fixed and related test added.

@colinsurprenant
Copy link
Contributor Author

colinsurprenant commented Apr 18, 2016

Ah yes, obviously, you have to make sure logstash-core-event is selected in the Gemfile and logstash-core.gemspec to test with the Ruby Event.

@colinsurprenant colinsurprenant changed the title fix for accessors lut invalidation [WIP] fix for accessors lut invalidation Apr 18, 2016
@jsvd jsvd self-assigned this Apr 19, 2016
@jsvd
Copy link
Member

jsvd commented Apr 19, 2016

From my benchmarks of operations on LogStash::Event, the performance change with this patch is as follows:

  • in a set-heavy benchmark, this patch is ~7% faster than the current implementation
  • in a read-heavy benchmark, this patch is ~4.8% slower than current implementation
  • in a mixed benchmark, this patch is ~4.5% faster than the current implementation

All these are measured with an uncertainty around +/- 4%

So IMO, since this actually fixes a bug, I think the PR is on the right track 👍

[edit] see more about the results in https://gist.github.com/jsvd/172c98c3d6bc6cc08aca6501d60cc7a9

@colinsurprenant
Copy link
Contributor Author

@jsvd thanks for measuring this!

@colinsurprenant colinsurprenant changed the title [WIP] fix for accessors lut invalidation fix for accessors lut invalidation Apr 20, 2016
@colinsurprenant
Copy link
Contributor Author

colinsurprenant commented Apr 20, 2016

  • We agreed that this fix is acceptable performance-wise and the same fix has been applied to the Java Event.
  • Doing so uncovered another bug that resulted in a expecting List or Map ClassCastException, also fixed and related test added.

Note that rake test:core reports the error under both Event implementations if/when removing the fix. The Java implementation also includes specific Java unit tests.

@jsvd @guyboertje @talevy please review?

@colinsurprenant
Copy link
Contributor Author

The build failure is not related to this PR

Failures:

  1) LogStash::Agent metrics after config reloading resets the metric collector
     Failure/Error: expect(snapshot.metric_store.get_with_path("/stats/events")[:stats][:events][:in].value).to eq(new_config_generator_counter)
     NoMethodError:
       undefined method `value' for nil:NilClass
     # ./logstash-core/spec/logstash/agent_spec.rb:374:in `(root)'
     # ./vendor/bundle/jruby/1.9/gems/rspec-wait-0.0.8/lib/rspec/wait.rb:46:in `(root)'
     # ./rakelib/test.rake:42:in `(root)'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/task.rb:248:in `execute'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/task.rb:243:in `execute'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/task.rb:187:in `invoke_with_call_chain'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/task.rb:180:in `invoke_with_call_chain'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/task.rb:173:in `invoke'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:150:in `invoke_task'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:106:in `top_level'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:106:in `top_level'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:115:in `run_with_threads'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:100:in `top_level'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:78:in `run'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:176:in `standard_exception_handling'
     # ./vendor/bundle/jruby/1.9/gems/rake-11.1.2/lib/rake/application.rb:75:in `run'

Finished in 38.1 seconds (files took 2.1 seconds to load)
1179 examples, 1 failure

Failed examples:

rspec ./logstash-core/spec/logstash/agent_spec.rb:359 # LogStash::Agent metrics after config reloading resets the metric collector

Randomized with seed 54320

@ph @purbon ?

@ph
Copy link
Contributor

ph commented Apr 21, 2016

@colinsurprenant I will look into this failling test. first time I see it.

describe "Accessors invalidation" do
let(:event) { LogStash::Event.new({ "message" => "foo" }) }

it "should perperly invalidate accessors" do
Copy link
Contributor

Choose a reason for hiding this comment

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

properly

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

@guyboertje
Copy link
Contributor

LGTM

@@ -67,7 +67,7 @@ private Object findTarget(FieldReference field) {
target = this.data;
for (String key : field.getPath()) {
target = fetch(target, key);
if (target == null) {
if (! targetIsCollection(target)) {
Copy link
Member

Choose a reason for hiding this comment

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

this method only checks that the argument is a collection, I suggest renaming it as isCollection

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 totally expecting this comment :D

@jsvd
Copy link
Member

jsvd commented Apr 21, 2016

2 minor comments, otherwise tests went well, LGTM

@@ -134,7 +138,7 @@ private Object fetch(Object target, String key) {
} else if (target == null) {
return null;
} {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

woa, this is a weird syntax quirk

Copy link
Contributor

Choose a reason for hiding this comment

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

missing else

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup... weird omission, it was still "correct" but ... anyhow. fixing :D

@colinsurprenant
Copy link
Contributor Author

ok, pushed changes. any final review @jsvd @talevy ?

@jsvd
Copy link
Member

jsvd commented Apr 22, 2016

LGTM

lut invalidation spec

fix lut invalidation

extra comment

fix lut invalidation, invalid target path, with tests

post review fixes
@colinsurprenant
Copy link
Contributor Author

merged in master, 5.0, 2.x. will wait after 2.3.2 release (today) to merge fix in 2.3, we prefer to get a bit more mileage with this fix before it makes it into a release.

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.

Accessors path invalidation problem
6 participants