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

compile ScriptProcessor inline scripts when creating ingest pipelines #21858

Merged
merged 1 commit into from Dec 15, 2016

Conversation

talevy
Copy link
Contributor

@talevy talevy commented Nov 29, 2016

Inline scripts defined in Ingest Pipelines are not compiled at creation time and compile-time errors lazily occur upon initial execution of the pipeline.

WIP because it lacks tests.

Fixes #21842.

@talevy talevy added :Data Management/Ingest Node Execution or management of Ingest Pipelines including GeoIP >enhancement WIP v5.0.0 v6.0.0-alpha1 v5.2.0 and removed v5.0.0 labels Nov 29, 2016
return new ScriptProcessor(processorTag, script, scriptService);
CompiledScript compiledInlineScript = null;
if (script.getType() == ScriptType.INLINE) {
compiledInlineScript = scriptService.compile(script, ScriptContext.Standard.INGEST, script.getOptions());
Copy link
Member

Choose a reason for hiding this comment

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

I don't think the compile script should be stashed here. Instead, just check that the script can be resolved with the script service (don't just check inline; for example, it would then also ensure if they use a file script it exists).

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 is why I open WIP PRs! thanks – I'll check out what it means to resolve a script

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh, getting back to this now... by resolve, you mean just run through a compile, but don't actually store it. That sounds good to me too, guess I was cutting out the middle-man cacher.

I'll update to run compile on file and inline scripts

@talevy talevy force-pushed the compiledinline branch 3 times, most recently from 1213451 to 89c4252 Compare November 30, 2016 15:19
@talevy
Copy link
Contributor Author

talevy commented Nov 30, 2016

@rjernst updated, please let me know if this is what you meant. thanks!

@talevy talevy added review and removed WIP labels Nov 30, 2016
@@ -121,6 +131,15 @@ public ScriptProcessor create(Map<String, Processor.Factory> registry, String pr
throw newConfigurationException(TYPE, processorTag, null, "Could not initialize script");
}

// compile inline and file-backed scripts to ensure they are valid before constructing the processor.
if (script.getType() == ScriptType.INLINE || script.getType() == ScriptType.FILE) {
Copy link
Member

Choose a reason for hiding this comment

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

I don't see why we need to restrict types here. This should work fine for stored scripts as well, and they should be validated too.

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 guess my assumption was that stored scripts are compiled when being stored. is this not the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

but, yeah, I'm good with it. less branching

Copy link
Member

Choose a reason for hiding this comment

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

Yes they are, but you still want to ensure the script id exists?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes 😞. working on this in-between logstash builds is not helping my thought process. will update. thanks for review

@talevy
Copy link
Contributor Author

talevy commented Dec 1, 2016

retest this please

@talevy
Copy link
Contributor Author

talevy commented Dec 1, 2016

retest this please

1 similar comment
@talevy
Copy link
Contributor Author

talevy commented Dec 2, 2016

retest this please

@talevy
Copy link
Contributor Author

talevy commented Dec 13, 2016

@rjernst mind taking another gander when you find the time? thanks

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

Looks good.

import static org.elasticsearch.script.ScriptType.FILE;
import static org.elasticsearch.script.ScriptType.INLINE;
import static org.elasticsearch.script.ScriptType.STORED;

/**
Copy link
Member

Choose a reason for hiding this comment

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

Can you keep some basic docs here?

@Override
public void execute(IngestDocument document) {
ExecutableScript executableScript = scriptService.executable(script, ScriptContext.Standard.INGEST);
ExecutableScript executableScript;
executableScript = scriptService.executable(script, ScriptContext.Standard.INGEST);
Copy link
Member

Choose a reason for hiding this comment

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

revert splitting this over 2 lines?

@talevy talevy merged commit eaf82a6 into elastic:master Dec 15, 2016
@talevy talevy deleted the compiledinline branch December 15, 2016 01:26
talevy added a commit that referenced this pull request Dec 15, 2016
…#21858)

Inline scripts defined in Ingest Pipelines are now compiled at creation time to preemptively catch errors on initialization of the pipeline.

Fixes #21842.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/Ingest Node Execution or management of Ingest Pipelines including GeoIP >enhancement v5.2.0 v6.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants