A quick update on this issue. Today, when playing with UDA, I had also the exception:
java.security.AccessControlException: access denied ("java.io.FilePermission" "/xxxxx/logback.xml" "read")" What is definitely strange is that by re-executing again the query, same query, it works. I couldn't re-produce anymore the issue. I'm wondering if it only occurs when the UDA execution exceeds the warning timeout and is re-scheduled... On Tue, Dec 29, 2015 at 9:52 PM, Tyler Hobbs <ty...@datastax.com> wrote: > >> 1. Is it possible to "tune" the page size or is it hard-coded internally ? >> > > If a page size is set for the request at the driver level, that page size > will be used internally. Otherwise, it defaults to something reasonable > (probably ~5k rows). > > >> 2. Is read-repair performed on EACH page or is it done on the whole >> requested rows once they are fetched ? >> > > It's performed on each page as it's read. Do note that read repair > doesn't happen for multi-partition range reads, regardless of paging or > aggregation. > > >> >> Question 2. is relevant in some particular scenarios when the user is >> using CL QUORUM (or more) and some replicas are out-of-sync. Even in the >> case of aggregation over a single partition, if this partition is wide and >> spans many fetch pages, the time the coordinator performs all the >> read-repair and reconcile over QUORUM replicas, the query may timeout very >> quickly. >> > > Yes, that's possible. Timeouts for these queries should be adjusted > accordingly. It's worth noting that the read_request_timeout_in_ms setting > applies per-page, so coordinator-level timeouts shouldn't be severely > affected by this. > > -- > Tyler Hobbs > DataStax <http://datastax.com/> >