Crashing cassandra 0.6.2 with a simple JMX connection attempt
Hi! I accidentally swapped the thrift and JMX port when I tried to connect to the JMX interface. This crashes cassandra instantaneously with OOM. $ jconsole service:jmx:rmi:///jndi/rmi://localhost:9160/jmxrmi INFO 16:55:36,568 Binding thrift service to localhost/127.0.0.1:9160 INFO 16:55:36,576 Cassandra starting up... java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid35567.hprof ... Heap dump file created [5834697 bytes in 0.227 secs] ERROR 16:59:41,417 Fatal exception in thread Thread[pool-1-thread-2,5,main] java.lang.OutOfMemoryError: Java heap space at org.apache.thrift.protocol.TBinaryProtocol.readStringBody(TBinaryProtocol.java:296) at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:203) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:1113) at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:253) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637)
Re: Crashing cassandra 0.6.2 with a simple JMX connection attempt
On Thu, Jun 10, 2010 at 10:05 AM, Timo Nentwig wrote: > Hi! > > I accidentally swapped the thrift and JMX port when I tried to connect to > the JMX interface. This crashes cassandra instantaneously with OOM. > https://issues.apache.org/jira/browse/THRIFT-601 -Brandon
Re: Crashing cassandra 0.6.2 with a simple JMX connection attempt
Supposedly that's fixed now, so I've re-opened https://issues.apache.org/jira/browse/CASSANDRA-475 On Thu, Jun 10, 2010 at 8:20 AM, Brandon Williams wrote: > On Thu, Jun 10, 2010 at 10:05 AM, Timo Nentwig wrote: > >> Hi! >> >> I accidentally swapped the thrift and JMX port when I tried to connect to >> the JMX interface. This crashes cassandra instantaneously with OOM. >> > > https://issues.apache.org/jira/browse/THRIFT-601 > > -Brandon > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
New keyspace loading creates 'master'
Hi, We've been fiddling around with a small Cassandra cluster, bringing nodes up and down, to get a feel for how things are replicated and how spinning up a new node works (before having to learn it live :). We are using the trunk because we want to use the expiration feature. Along with that comes the new keyspace api to load the 'schema'. What we found was that, if the node on which we originally installed the keyspace was down when a new node is added, the new node does not get the keyspace schema. In some regards, it is now the 'master', at least in distributing the keyspace data. Is this a known limitation? Thanks, Ron
Re: New keyspace loading creates 'master'
On Thu, Jun 10, 2010 at 17:16, Ronald Park wrote: > What we found was that, if the node on which we originally installed the > keyspace was down when a new node is added, the new node does not get the > keyspace schema. In some regards, it is now the 'master', at least in > distributing the keyspace data. Is this a known limitation? > To clarify, are you saying that on a cluster of N nodes, if the original node was down and there are N-1 live nodes, that new nodes will not receive keyspace definitions? If so, it's less of a limitation and more of a bug. Gary. > Thanks, > Ron >
Handoff on failure.
I am looking at Cassandra 0.6.2's source code, and am unable to figure out where, if at all, repartitioning happens in the case of failure. The Gossiper's onDead message is ignored. Can someone please clarify this for me?
