[
https://issues.apache.org/jira/browse/CASSANDRA-9954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049728#comment-15049728
]
Robert Stupp commented on CASSANDRA-9954:
-----------------------------------------
bq. Are we going to do this after CASSANDRA-10395?
Yes, that would be the order. But I’d like to prepare both together since 10395
removes “client timeout warning” functionality that this ticket can bring back.
In other words: make 10395 RTC and base this on 10395. WDYT?
bq. Do we allow UDFs in writes?
Yes.
bq. can mark the UDFs as deterministic/non-deterministic
No - that’s been removed after that blog post. We might need to bring that back
with functional indexes (CASSANDRA-7458) as non-deterministic functions would
be bad for that.
You’re probably right
bq. reads do UDFs only run at the coordinator?
Yes.
bq. Checking metrics every 16 times is a little bit too often for most loop
iterations. Maybe make that a property?
Good point. Added {{cassandra.java_udf_check_interval}} for that - now defaults
to 1000 instead of 16.
Renamed {{JavaUDFByteCodeVerifier.verify}} to {{verifyAndInstrument}}.
Labels are inserted nearly everywhere and are required for loops, conditional
branches and all that stuff.
You’re right - we should measure the performance impact at least in a micro
benchmark. I think all we need to know is the performance impact for the UDF
itself as that’s basically just added. WDYT?
Rebased the branch and pushed it.
> Improve Java-UDF timeout detection
> ----------------------------------
>
> Key: CASSANDRA-9954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9954
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.x
>
>
> CASSANDRA-9402 introduced a sandbox using a thread-pool to enforce security
> constraints and to detect "amok UDFs" - i.e. UDFs that essentially never
> return (e.g. {{while (true)}}.
> Currently the safest way to react on such an "amok UDF" is to _fail-fast_ -
> to stop the C* daemon since stopping a thread (in Java) is just no solution.
> CASSANDRA-9890 introduced further protection by inspecting the byte-code. The
> same mechanism can also be used to manipulate the Java-UDF byte-code.
> By manipulating the byte-code I mean to add regular "is-amok-UDF" checks in
> the compiled code.
> EDIT: These "is-amok-UDF" checks would also work for _UNFENCED_ Java-UDFs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
