Hi all,
We've open sourced Polidoro. It's a Cassandra client in Scala on top of
Astyanax and in the style of Cascal.
Find it at https://github.com/SpotRight/Polidoro
-Lanny Ripple
SpotRight, Inc - http://spotright.com
...@eyeviewdigital.com wrote:
All you need to do is to decrease the replication factor of DC1 to 0, and
then decommission the nodes one by one,
I've tried this before and it worked with no issues.
Thanks,
On Tue, Jul 23, 2013 at 10:32 PM, Lanny Ripple la...@spotright.comwrote:
Hi,
We have
Hi,
We have a multi-dc setup using DC1:2, DC2:2. We want to get rid of DC1.
We're in the position where we don't need to save any of the data on DC1.
We know we'll lose a (tiny. already checked) bit of data but our
processing is such that we'll recover over time.
How do we drop DC1 and just
)
at
org.apache.cassandra.thrift.Cassandra$Client.get_paged_slice(Cassandra.java:753)
at
org.apache.cassandra.hadoop.ColumnFamilyRecordReader$WideRowIterator.maybeInit(ColumnFamilyRecordReader.java:438)
On Thu, Apr 18, 2013 at 12:34 AM, Lanny Ripple la...@spotright.com wrote:
It's slow going finding
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 16/04/2013, at 10:17 AM, Lanny Ripple la...@spotright.com wrote:
A bump to say I found this
http://stackoverflow.com/questions/15487540/pig-cassandra-message-length-exceeded
so others
http://www.thelastpickle.com
On 18/04/2013, at 5:50 AM, Lanny Ripple la...@spotright.com wrote:
That was our first thought. Using maven's dependency tree info we verified
that we're using the expected (cass 1.2.3) jars
$ mvn dependency:tree | grep thrift
[INFO
Saw this in earlier versions. Our workaround was disable; drain; snap;
shutdown; delete; link from snap; restart;
-ljr
On Apr 11, 2013, at 9:45, moshe.kr...@barclays.com wrote:
I have formulated the following theory regarding C* 1.2.2 which may be
relevant: Whenever there is a disk error
was too long.
The mystery to me: Why no complaints in previous versions? Were some checks
added in Thrift or Hector?
-Original Message-
From: Lanny Ripple [mailto:la...@spotright.com]
Sent: Tuesday, April 09, 2013 6:17 PM
To: user@cassandra.apache.org
Subject: Thrift message length
Hello,
We have recently upgraded to Cass 1.2.3 from Cass 1.1.5. We ran
sstableupgrades and got the ring on its feet and we are now seeing a new issue.
When we run MapReduce jobs against practically any table we find the following
errors:
2013-04-09 09:58:47,746 INFO
We occasionally (twice now on a 40 node cluster over the last 6-8 months) see
this. My best guess is that Cassandra can fail to mark an SSTable for cleanup
somehow. Forced GC's or reboots don't clear them out. We disable thrift and
gossip; drain; snapshot; shutdown; clear
A type 4 UUID can be created from two Longs. You could MD5 your strings giving
you 128 hashed bits and then make UUIDs out of that. Using Scala:
import java.nio.ByteBuffer
import java.security.MessageDigest
import java.util.UUID
val key = Hello, World!
val md =
Ah. TimeUUID. Not as useful for you then but still something for the toolbox.
On Mar 27, 2013, at 8:42 AM, Lanny Ripple la...@spotright.com wrote:
A type 4 UUID can be created from two Longs. You could MD5 your strings
giving you 128 hashed bits and then make UUIDs out of that. Using Scala
12 matches
Mail list logo
