cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9954) Improve Java-UDF timeout detection
Date Thu, 10 Dec 2015 00:32:10 GMT


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?


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?


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:
>             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
> EDIT: These "is-amok-UDF" checks would also work for _UNFENCED_ Java-UDFs.

This message was sent by Atlassian JIRA

View raw message