do not use cassandra for implementing queueing system with high
throughput. It does not scale because of tombstone management. Use
hornetQ, its amazingly fast broker but it has quite slow persistence if
you want to create queues significantly larger then your memory and use
selectors for
Dear:
It's OK, Welcome, let us start.
Thx
C U
==
www.infomesr.org
ad...@infomesr.org
- Message from is...@ishans.info -
Date: Sun, 6 Jan 2013 09:44:23 +0530
From: Ishan Thilina is...@ishans.info
Reply-To: user@cassandra.apache.org
Subject: Requesting for
I finally realized that Thrift API has changed from 1.1 to 1.2 and my code
and modified JDBC driver works well except I get an exception on the system
log when I close the connection. Looks like it is an old issue reappearing.
I have evaluated new Java driver, it is easier and more practical than
With regard to a large number of records in a batch mutation there are some
potential issues.
Each row becomes a task in the write thread pool on each replica. If a single
client sends 1,000 rows in a mutation it will take time for the (default) 32
threads in the write pool to work through
Another potential issue is when some failure happens to some of the mutations.
Is atomic batches in 1.2 designed to resolve this?
http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2
-Wei
- Original Message -
From: aaron morton aa...@thelastpickle.com
To:
