Hello Randy,
It's normal that the memory in the heap is having this pattern. Java uses
memory available and when needed clean some memory for new needs, that's
the variation you see. In your case, it's not really regular but this can
depend on the workload as well.
I'm a C# .NET guy, so I have no
Hi,
Nice that you solved the issue. I had some thoughts while reading:
> My original thought was a new DC parallel to the current, and then
> decommission the other DC.
>
I also think this is the best way to go when possible. It can be reverted
any time in the process, respect distributions, yo
THIS! A well-reasoned and clear explanation of a very difficult topic. This is
the kind of gold that a user mailing list can provide. Thank you, Alain!
Sean Durity
From: Alain RODRIGUEZ
Sent: Tuesday, July 03, 2018 6:37 AM
To: user cassandra.apache.org
Subject: [EXTERNAL] Re: JVM Heap erratic
Hi all,
Please, can you give me a link to the source code behind the command
"nodetool status" ?
Thank you so much.
KInd regards.
There is more info and background context on CDC here:
https://issues.apache.org/jira/browse/CASSANDRA-8844
On Mon, Jul 2, 2018 at 9:26 PM, Justin Cameron
wrote:
> Sorry - you'd need a source connector, not the sink.
>
> On Tue, 3 Jul 2018 at 04:24 Justin Cameron wrote:
>
>> Yeah, if you're usi
https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/tools/nodetool/Status.java
On Tue, Jul 3, 2018 at 7:57 AM, Thouraya TH wrote:
> Hi all,
> Please, can you give me a link to the source code behind the command
> "nodetool status" ?
> Thank you so much.
> KInd r
There is a source connector from Landoop for Kafka Connect but it is based on
polling a “kcql” select statement. They claim to be working on a CDC source
connector for Kafka Connect but I couldn’t find anything.
Smart Cat Labs has a CDC trigger based Kafka producer but I don’t think it uses
Kaf
Some of my links related to Kafka and Cassandra
http://leaves.anant.us/#!/leaf/10767?tag=cassandra,kafka
Rahul
On Jul 3, 2018, 11:48 AM -0400, Joshua Galbraith
, wrote:
> There is more info and background context on CDC here:
> https://issues.apache.org/jira/browse/CASSANDRA-8844
>
> > On Mon,
Hi all,
We recently experienced an unexpected behavior with C* consistency.
For example, a table t consists of 4 columns - pk , a, b and c. We perform
Quorum write and then Quorum read (RF=3 / LCS compaction).
The consistency seems to break while repairing is running(repair -pr).
Say, a record
Shouldn't happen. Any chance you could trace the queries, or have you been
able to reproduce it? Also, what version of Cassandra?
On Wed., 4 Jul. 2018, 06:41 Visa, wrote:
> Hi all,
>
> We recently experienced an unexpected behavior with C* consistency.
>
> For example, a table t consists of 4 co
Thanks for replying!
The version is C* 3.11.1.
The quorum write and read are done in java code (spark streaming) and in async
mode within the same session. Could not reproduce it via cqlsh yet.
With the same session, execute the async write, and in the callback execute the
async read.
To be
11 matches
Mail list logo