Skip to content

dynamically get the plugin id instead of hardcoding it in the generated classes - #12038

Merged
elasticsearch-bot merged 1 commit into
elastic:masterfrom
colinsurprenant:dynamic_plugin_id
Jun 25, 2020
Merged

elasticsearch-bot merged 1 commit into
elastic:masterfrom
colinsurprenant:dynamic_plugin_id

Conversation

@colinsurprenant

@colinsurprenant colinsurprenant commented Jun 18, 2020 •

Copy link
Copy Markdown
Contributor

Fixes #12031

This PR fixes the regression introduced in 7.7.0 where the plugin id was set in the thread context by hard coding the unique plugin id in the generated class resulting in generating non cacheable classes that all contained a unique id.

The fix is to dynamically get the plugin id from the plugin instance field which result in non-unique generated code and thus allowing the reuse of equivalent generated classes.

  • Before this PR the generated filter and output classes would contain code similar to
org.apache.logging.log4j.ThreadContext.put("plugin.id", "ce80c1c692c7fd1664e67aa37b9b5ee8f6d7fa336b22bad5b14684ca44132adc");
  • This PR make that code be like:
org.apache.logging.log4j.ThreadContext.put("plugin.id", field1.getId().toString());

@andsel

andsel commented Jun 23, 2020

Copy link
Copy Markdown
Member

This LGTM. I've added a test to check if we experiment performance regressions future. /cc @jsvd

Comment thread logstash-core/src/test/java/org/logstash/config/ir/CompiledPipelineTest.java Outdated
@jsvd

jsvd commented Jun 23, 2020

Copy link
Copy Markdown
Member

Test has failed:

17:10:22 org.logstash.config.ir.CompiledPipelineTest > testCompilerCacheCompiledClasses FAILED
17:10:22     java.lang.AssertionError: expected:<1> but was:<0>
17:10:22         at org.junit.Assert.fail(Assert.java:88)
17:10:22         at org.junit.Assert.failNotEquals(Assert.java:834)
17:10:22         at org.junit.Assert.assertEquals(Assert.java:645)
17:10:22         at org.junit.Assert.assertEquals(Assert.java:631)
17:10:22         at org.logstash.config.ir.CompiledPipelineTest.testCompilerCacheCompiledClasses(CompiledPipelineTest.java:590)

@andsel

andsel commented Jun 23, 2020

Copy link
Copy Markdown
Member

@jsvd I think the cache is already warmed up by other tests

@jsvd

jsvd commented Jun 23, 2020

Copy link
Copy Markdown
Member

good catch, @andsel can you open an issue to discuss the implementation of the cache as a static? as it is it's difficult to configure/disable the cache in testing.
In the meantime we can simply evict the cache before tests in this class.

@andsel

andsel commented Jun 23, 2020

Copy link
Copy Markdown
Member

Added issue #12044 to improve the internal class cache

Comment on lines +55 to +58
static {
COMPILER.setDebuggingInformation(true, true, true);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't believe this was intended to stay?

Suggested change
static {
COMPILER.setDebuggingInformation(true, true, true);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I was thinking the same, but if the switch for Janino debug is on, probably having the right line reference on the generated sources could be helpful.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do you think could impact negatively the compilation part?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I haven't tested. can't this be enabled through JAVA_OPTS?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I found it, it's org.codehaus.janino.source_debugging.enable so removed the code fragment

Comment on lines +702 to +705
// for 7.6
// return new FilterDelegatorExt(
// RubyUtil.RUBY, RubyUtil.FILTER_DELEGATOR_CLASS)
// .initForTesting(this.filter.get());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

we won't be backporting this to 7.6

Suggested change
// for 7.6
// return new FilterDelegatorExt(
// RubyUtil.RUBY, RubyUtil.FILTER_DELEGATOR_CLASS)
// .initForTesting(this.filter.get());

@andsel andsel Jun 24, 2020 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

yes to remote, my bad

final CompiledPipeline compiledPipeline2 = new CompiledPipeline(pipeline2, pluginFactory);
compiledPipeline2.buildExecution();
final int cachedAfter = ComputeStepSyntaxElement.classCacheSize();
System.out.println("DNADBG>> cachedAfter: " + cachedAfter + ", cachedBefore: " + cachedBefore);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

what's DNADBG?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

ehm, comment to remove, my bad

@andsel
andsel force-pushed the dynamic_plugin_id branch from 6ff92cb to f7627fc Compare June 25, 2020 08:44

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

let's avoid these refactors, I think we benefit from having an explicit list, makes it easier to understand the dependencies. Intellij can be told to stop doing this.

Comment thread logstash-core/src/test/java/org/logstash/config/ir/CompiledPipelineTest.java Outdated
@andsel
andsel force-pushed the dynamic_plugin_id branch from 3de61df to 9ac8846 Compare June 25, 2020 12:22
…ead of hardcode

Changed ComputeStepSyntaxElement to generate Java code to retrieve the plugin's id by a method instead of hardcoding the value in the generated code.
This permit to share more compiled classes, that differs only by plugin.id and speed up the pipeline compilation.

The change has been secured by future regression with unit test that track pipeline compilations times.

Co-authored-by: Andrea Selva <andsel@users.noreply.github.com>
Co-authored-by: João Duarte <jsvd@users.noreply.github.com>

Fixes: elastic#12031
@andsel
andsel force-pushed the dynamic_plugin_id branch from 9ac8846 to 1a11abd Compare June 25, 2020 13:08
@elasticsearch-bot
elasticsearch-bot merged commit ffac2df into elastic:master Jun 25, 2020
@elasticsearch-bot

Copy link
Copy Markdown

Andrea Selva merged this to master!

Pull request was also backported into the following branches:

Branch Commits
7.x d767848
7.8 84f9154

andsel added a commit to andsel/logstash that referenced this pull request Jun 25, 2020
with PR elastic#11773 some configuration code part was moved from Ruby to Java, due to this move the CompiledPipelineTest.verifyRegex method
changed the type of thrown exception from stricter IncompleteSourceWithMetadataException to coarse parent InvalidIRException. With changes
in PR elastic#12038 some import cleanup was done and that removed the import of IncompleteSourceWithMetadataException and necessity of this fix.
elasticsearch-bot pushed a commit that referenced this pull request Jun 25, 2020
with PR #11773 some configuration code part was moved from Ruby to Java, due to this move the CompiledPipelineTest.verifyRegex method
changed the type of thrown exception from stricter IncompleteSourceWithMetadataException to coarse parent InvalidIRException. With changes
in PR #12038 some import cleanup was done and that removed the import of IncompleteSourceWithMetadataException and necessity of this fix.
@colinsurprenant

Copy link
Copy Markdown
Contributor Author

Thanks @jsvd for the review and @andsel for moving this to completion with the added tests. 🚀

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.

Pipeline compilation significantly increased in 7.7.0 in comparison to 7.6.2

5 participants