[
https://issues.apache.org/jira/browse/CASSANDRA-9954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-9954:
------------------------------------
Status: Patch Available (was: Open)
Rebased the patch and triggered CI:
||trunk|[branch|https://github.com/apache/cassandra/compare/trunk...snazy:9954-amok-udf-trunk]|[testall|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-9954-amok-udf-trunk-testall/lastSuccessfulBuild/]|[dtest|http://cassci.datastax.com/view/Dev/view/snazy/job/snazy-9954-amok-udf-trunk-dtest/lastSuccessfulBuild/]
> 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)
