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
> On Oct 27, 2017, at 3:08 AM, Artur Siekielski wrote:
>
> I noticed that the DecoratedKey printed in the stack trace can be for a
> different table. The arguments are a token and a partition key and they can
> be the same for multiple tables. Is there a way to know for which table the
> Dig
> On Oct 27, 2017, at 2:23 AM, Gábor Auth wrote:
>
> Hi,
>
>> On Thu, Oct 26, 2017 at 11:10 PM Blake Eggleston
>> wrote:
>> Following a discussion on dev@, the materialized view feature is being
>> retroactively classified as experimental, and not recommended for new
>> production uses. Th
Seems like a question better suited for the Spark mailing list, or the DSE
support , not OSS Cassandra.
> On Oct 27, 2017, at 8:14 AM, Thakrar, Jayesh
> wrote:
>
> What you have is sequential and hence sequential processing.
> Also Spark/Scala are not parallel programming languages.
> But even
Dear community,
I am studying the behaviour of the Cassandra TimeWindowCompactionStragegy.
To do so I am watching some metrics. Two of these metrics are important:
Compaction.CompletedTasks, a gauge, and the TotalCompactionsCompleted, a
Meter.
According to the documentation (
http://cassandra.apa
What you have is sequential and hence sequential processing.
Also Spark/Scala are not parallel programming languages.
But even if they were, statements are executed sequentially unless you exploit
the parallel/concurrent execution features.
Anyway, see if this works:
val (RDD1, RDD2) = (JavaFunc
Bit more information. Using jmxterm and inspecting the state of a node when
it's "slow" playing hints, I can see the following from the node that has
hints to play:
$>get MaxHintsInProgress
#mbean = org.apache.cassandra.db:type=StorageProxy:
MaxHintsInProgress = 2048;
$>get HintsInProgress
#mbean
I noticed that the DecoratedKey printed in the stack trace can be for a
different table. The arguments are a token and a partition key and they
can be the same for multiple tables. Is there a way to know for which
table the DigestMismatchException happens?
Can the AsyncRepairRunner be triggere
Hi,
On Thu, Oct 26, 2017 at 11:10 PM Blake Eggleston
wrote:
> Following a discussion on dev@, the materialized view feature is being
> retroactively classified as experimental, and not recommended for new
> production uses. The next patch releases of 3.0, 3.11, and 4.0 will include
> CASSANDRA-1