[ 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)