Re: Cassandra 3.1 - Aggregation query failure

[DuyHai Doan <do...@gmail.com>]

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/>
>