I think Timmy might be referring to the upcoming native CQL Java driver
that might be coming with 1.2 - It was mentioned here:
http://www.datastax.com/wp-content/uploads/2012/08/7_Datastax_Upcoming_Changes_in_Drivers.pdf
I would also be interested on testing that but I can't find it from
repositor
yes, https://issues.apache.org/jira/browse/CASSANDRA-1302
thanks
On Wed, Nov 14, 2012 at 2:04 AM, Tyler Hobbs wrote:
> As far as I know, the row cache has never been populated by
> get_range_slices(), only normal gets/multigets. The behavior is this way
> because get_range_slices() is almost e
Hello Aaron,
Thanks a lot for the reply.
Looks like the documentation is confusing. Here is the link I am referring
to: http://www.datastax.com/docs/1.1/operations/tuning#tuning-compaction
> It does not disable compaction.
As per the above url, " After running a major compaction, automatic min
I have RF = 3. Read/Write consistency has already been set as TWO.
It did seem that the data were not consistent yet.
(There are some CFs that I expected empty after the operations, but still
got some data, and the number of data were decreasing after retrying
to get all data
from that CF)
Sinc
What consistency level are you writing with? If you were writing with ANY,
try writing with a higher consistency level.
-Tupshin
On Nov 18, 2012 9:05 PM, "Chuan-Heng Hsiao"
wrote:
> Hi Aaron,
>
> Thank you very much for the replying.
>
> The 700 CFs were created in the beginning (before any inse
Hi Aaron,
Thank you very much for the replying.
The 700 CFs were created in the beginning (before any insertion.)
I did not do anything with commitlog_archiving.properties, so I guess
I was not using commit log archiving.
What I did was doing a lot of insertions (and some deletions)
using anoth
>
> If you are using the off heap cache the upper bound is memory. If you are
> using the on head it's the JVM heap.
But as I said earlier, I could not watch the usage of JVM heap while
reading saved caches
> time (UTC) 01 2 3 4 5 6
> 7 8 9 10 11 12 13
> Good value 88 44 26 35 26 86 187 251
> 455 389 473 367 453 373
> C* counter149 82 45
> As per datastax documentation, a manual compaction forces the admin to start
> compaction manually and disables the automated compaction (atleast for major
> compactions but not minor compactions )
It does not disable compaction.
it creates one big file, which will not be compacted until there
> 1. How much GCInspector warnings per hour are considered 'normal'?
None.
A couple during compaction or repair is not the end of the world. But if you
have enough to thinking about "per hour" it's too many.
> 2. What should be the next thing to check?
Try to determine if the GC activity correl
> . But what is the upper bound? And rules of thumb?
If you are using the off heap cache the upper bound is memory. If you are using
the on head it's the JVM heap.
Cheers
-
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 17/1
> I am wondering whether the huge commitlog size is the expected behavior or
> not?
Nope.
Did you notice the large log size during or after the inserts ?
If after did the size settle ?
Are you using commit log archiving ? (in commitlog_archiving.properties)
> and around 700 mini column family
If you are talking about the CQL-client that comes with Cassandra (cqlsh), it
is actually written in Python:
https://github.com/apache/cassandra/blob/trunk/bin/cqlsh
For information on datatypes (and conversion) take a look at the CQL definition:
http://www.datastax.com/docs/1.0/references/cql/i
Hi!
I posted this question on hector users list but no one answered, so I am
trying here as well.
I have production cluster running Cassandra 1.0.8 and a test cluster with
Cassandra 1.1.6.
In my Java app I do not user maven, but rather have my lib directory with
the jar files I use.
When I ran my
14 matches
Mail list logo
