The following won't address any server performance issues, but will allow
your application to continue to run even if there are client or server
timeouts:
Your python code should wrap all Cassandra statement execution calls in
a try/except block to catch any errors and handle them appropriate
We are using 3.11.1 (which we recently upgraded from 3.11.0) and just
started experimenting with LeveledCompactionStrategy. After loading data
for 24 hours, we started getting the following error:
ERROR [CompactionExecutor:628] 2017-10-27 11:58:21,748
CassandraDaemon.java:228 - Exception in thread
use the behavior you're seeing.
>
>
>
> On Fri, Oct 13, 2017 at 4:24 PM, Bruce Tietjen <
> bruce.tiet...@imatsolutions.com> wrote:
>
>>
>> We are new to Cassandra and have built a test cluster and loaded some
>> data into the cluster.
>>
>> We
:
> What's the compaction strategy are you using? level compaction or size
> tiered compaction?
>
> On Fri, Oct 13, 2017 at 4:31 PM, Bruce Tietjen <
> bruce.tiet...@imatsolutions.com> wrote:
>
>> I hadn't noticed that is is now attempting
uld not happen. There’s a check that drops
> sstables out of a compaction task if there isn’t enough available disk
> space, see https://issues.apache.org/jira/browse/CASSANDRA-12979 for some
> details.
>
>
> On Oct 13, 2017, at 4:24 PM, Bruce Tietjen com> wrote:
>
>
> W
We are new to Cassandra and have built a test cluster and loaded some data
into the cluster.
We are seeing compaction behavior that seems to violate what we read about
it's behavior.
Our cluster is configured with JBOD with 3 3.6T disks. Those disks
currently respectively have the following used/
