-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Stop runtime script from emitting too many values #61938
Stop runtime script from emitting too many values #61938
Conversation
This prevent `keyword` valued runtime scripts from emitting too many values or values that take up too much space. Without this you can put allocate a ton of memory with the script by sticking it into a tight loop. Painless has some protections against this but: 1. I don't want to rely on them out of sheer paranoia 2. They don't really kick in when the script uses callbacks like we do anyway. Relates to elastic#59332
Pinging @elastic/es-search (:Search/Search) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the approach looks good to me, I guess the plan is to apply it to all types and share as much code as possible?
/** | ||
* The maximum number of values a script should be allowed to emit. | ||
*/ | ||
public static final int MAX_VALUES = 1000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems high
setDocument(docId); | ||
execute(); | ||
return results; | ||
} | ||
|
||
protected final void emitValue(String v) { | ||
if (results.size() >= MAX_VALUES) { | ||
throw new IllegalArgumentException("too many runtime values"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could the max values check be shared in the base class, and could we then unify the error message to something like "Runtime field [field] is emitting [1500] values while the maximum number of values allowed is [1000]"?
} | ||
chars += v.length(); | ||
if (chars >= MAX_CHARS) { | ||
throw new IllegalArgumentException("too many characters in runtime values [" + chars + "]"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Runtime field [field] is emitting [1500] characters while the maximum number of characters allowed is [1000]"?
Yes to all of those. I can try and pull it into the super class in this pr.
Do you have a preference for the max?
…On Fri, Sep 4, 2020, 05:32 Luca Cavanna ***@***.***> wrote:
***@***.**** commented on this pull request.
the approach looks good to me, I guess the plan is to apply it to all
types and share as much code as possible?
------------------------------
In
x-pack/plugin/runtime-fields/src/main/java/org/elasticsearch/xpack/runtimefields/AbstractScriptFieldScript.java
<#61938 (comment)>
:
> @@ -27,6 +27,11 @@
* ***@***.*** AggregationScript} but hopefully with less historical baggage.
*/
public abstract class AbstractScriptFieldScript {
+ /**
+ * The maximum number of values a script should be allowed to emit.
+ */
+ public static final int MAX_VALUES = 1000;
this seems high
------------------------------
In
x-pack/plugin/runtime-fields/src/main/java/org/elasticsearch/xpack/runtimefields/StringScriptFieldScript.java
<#61938 (comment)>
:
> setDocument(docId);
execute();
return results;
}
protected final void emitValue(String v) {
+ if (results.size() >= MAX_VALUES) {
+ throw new IllegalArgumentException("too many runtime values");
+ }
could the max values check be shared in the base class, and could we then
unify the error message to something like "Runtime field [field] is
emitting [1500] values while the maximum number of values allowed is
[1000]"?
------------------------------
In
x-pack/plugin/runtime-fields/src/main/java/org/elasticsearch/xpack/runtimefields/StringScriptFieldScript.java
<#61938 (comment)>
:
> setDocument(docId);
execute();
return results;
}
protected final void emitValue(String v) {
+ if (results.size() >= MAX_VALUES) {
+ throw new IllegalArgumentException("too many runtime values");
+ }
+ chars += v.length();
+ if (chars >= MAX_CHARS) {
+ throw new IllegalArgumentException("too many characters in runtime values [" + chars + "]");
Runtime field [field] is emitting [1500] characters while the maximum
number of characters allowed is [1000]"?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#61938 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABUXIUULXYGBMEZB2G3LFDSECX2PANCNFSM4QVD42FQ>
.
|
Does 100 sound reasonable for the max values? |
Sure!
…On Fri, Sep 4, 2020, 08:50 Luca Cavanna ***@***.***> wrote:
Does 100 sound reasonable for the max values?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#61938 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABUXIWJTUG2PWBPWWXD653SEDPCLANCNFSM4QVD42FQ>
.
|
@javanna this is ready for you again! |
...me-fields/src/main/java/org/elasticsearch/xpack/runtimefields/AbstractScriptFieldScript.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks @nik9000 !
Thanks @javanna ! |
This prevent `keyword` valued runtime scripts from emitting too many values or values that take up too much space. Without this you can put allocate a ton of memory with the script by sticking it into a tight loop. Painless has some protections against this but: 1. I don't want to rely on them out of sheer paranoia 2. They don't really kick in when the script uses callbacks like we do anyway. Relates to elastic#59332
This prevent `keyword` valued runtime scripts from emitting too many values or values that take up too much space. Without this you can put allocate a ton of memory with the script by sticking it into a tight loop. Painless has some protections against this but: 1. I don't want to rely on them out of sheer paranoia 2. They don't really kick in when the script uses callbacks like we do anyway. Relates to #59332
This prevent
keyword
valued runtime scripts from emitting too manyvalues or values that take up too much space. Without this you can put
allocate a ton of memory with the script by sticking it into a tight
loop. Painless has some protections against this but:
anyway.
Relates to #59332