[
https://issues.apache.org/jira/browse/CASSANDRA-10395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034779#comment-15034779
]
Ariel Weisberg commented on CASSANDRA-10395:
--------------------------------------------
The current approach is to put every UDF call into a concurrent queue. We
implemented the "optimal" approach to monitoring timeouts as part of
CASSANDRA-7392. The key difference is you don't have to hit a global concurrent
linked queue for every single UDF call. You can register the threads once on
creation and they can publish timeout information to be checked by the timeout
thread to the same object repeatedly.
[This {{ConcurrentLinkedQueue}} ends up being used as a
set.|https://github.com/apache/cassandra/compare/trunk...snazy:10395-udf-monitor-3.0?expand=1#diff-074b58383a8982056f42ad1887c3a9e3R172].
If you need a set it would better to use it rather than having to always walk
the queue to add/remove stuff.
[{{CopyOnWriteMap}} from Apache mina is an odd choice. Maybe use
{{org.cliffc.high_scale_lib.NonBlockingHashMap}}?|https://github.com/apache/cassandra/compare/trunk...snazy:10395-udf-monitor-3.0?expand=1#diff-30a3dbf7d783cf329b5fb28a8b14332eR140]
The whole business in general with the thread local. Is that because the list
of allowable packages changes depending on whether the thread is currently in
the UDF or not? Does this allow access to leak if the thread accesses a
forbidden class/package while not inside a UDF? Once it's loaded it will stay
loaded right?
It seems like the logging of UDF warnings should be rate limited with a counter
of how many things were not logged. It's one of the things we agonized about
how to do well in CASSANDRA-7392.
For the timeout it checks thread cpu time, but it doesn't also check wall clock
time. The two aren't quite interchangeable if someone figures out a way to
block the UDF thread such as with the use of concurrent data structures or
locking.
> Monitor UDFs using a single thread
> ----------------------------------
>
> Key: CASSANDRA-10395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10395
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Priority: Minor
> Fix For: 3.0.x
>
>
> Actually each UDF execution is handed over to a separate thread pool to be
> able to detect UDF timeouts. We could actually leave UDF execution in the
> "original" thread but have another thread/scheduled job regularly looking for
> UDF timeouts, which would save some time executing the UDF.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
