Re: client connecting to 0.7
Thanks Edward,
It was in fact the server config file. I thought i was missing the
thrift_framed_transport property, but I don't see that in the Config.java
file. Setting thrift_framed_transport_size_in_mb to something other than 0
enables framed on the server. Also mentioned here
http://wiki.apache.org/cassandra/StorageConfiguration. Must have missed that
property after we converted old config. :)
On Sat, Nov 6, 2010 at 8:41 AM, Edward Capriolo wrote:
> On Fri, Nov 5, 2010 at 9:50 PM, CassUser CassUser
> wrote:
> > I agree and we will move to hector at some point, but we have some
> legacy
> > code we need to convert to the new api. What am I doing wrong in the
> code I
> > posted?
> >
> >
> > On Fri, Nov 5, 2010 at 5:45 PM, Jonathan Ellis
> wrote:
> >>
> >> From Java you should be using Hector instead of messing around with
> >> raw Thrift. There is a version for beta2 at
> >> https://github.com/rantav/hector/downloads
> >>
> >> docs are at
> >> http://www.riptano.com/sites/default/files/hector-v2-client-doc.pdf
> >>
> >> On Fri, Nov 5, 2010 at 6:28 PM, CassUser CassUser
> >> wrote:
> >> > Hey I'm testing a client on beta2 cassandra version 0.7.
> >> >
> >> > TFramedTransport transport = new TFramedTransport(new
> >> > TSocket("my.ip", 9160));
> >> > Cassandra.Client client = new Cassandra.Client(new
> >> > TBinaryProtocol(transport));
> >> > transport.open();
> >> > System.out.println(client.describe_cluster_name());
> >> >
> >> > Is giving me the following:
> >> >
> >> > org.apache.thrift.protocol.TProtocolException: Missing version in
> >> > readMessageBegin, old client?
> >> > at
> >> >
> >> >
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:211)
> >> > at
> >> >
> >> >
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2706)
> >> > at
> >> >
> >> >
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167)
> >> > 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:662)
> >> >
> >> > I'm using the cassandra 0.7beta2 code on both client and server.
> >> >
> >>
> >>
> >>
> >> --
> >> Jonathan Ellis
> >> Project Chair, Apache Cassandra
> >> co-founder of Riptano, the source for professional Cassandra support
> >> http://riptano.com
> >
> >
> Strange your code looks just like mine. Possibly check your
> configuration file and make sure you cluster is using framed mode.
>
> package hpcas.c03;
> import org.apache.cassandra.thrift.Cassandra;
> import org.apache.thrift.protocol.*;
> import org.apache.thrift.transport.*;
> public class FramedConnWrapper {
>private TTransport transport;
>private TProtocol proto;
>private TSocket socket;
>public FramedConnWrapper(String host, int port) {
>socket = new TSocket(host,port);
>transport = new TFramedTransport(socket);
>proto = new TBinaryProtocol(transport);
>}
>public void open() throws Exception {
>transport.open();
>}
>public void close() throws Exception {
>transport.close();
>socket.close();
>}
>public Cassandra.Client getClient() {
>Cassandra.Client client = new Cassandra.Client(proto);
>return client;
>}
> }
>
Re: New nodes won't bootstrap on .66
Hi, Did you solve this problem? I'm having the same poblem. I'm trying to bootstrap a third node in a 0.66 cluster. It has two keyspaces: Keyspace1 and KeyspaceLogs, both with replication factor 2. It starts bootstrapping, receives some streams but it keeps waiting for streams. I enabled the debug mode. This lines may be useful: DEBUG [main] 2010-11-07 17:39:50,052 BootStrapper.java (line 70) Beginning bootstrap process DEBUG [main] 2010-11-07 17:39:50,082 StorageService.java (line 160) Added / 10.204.93.16/Keyspace1 as a bootstrap source ... DEBUG [main] 2010-11-07 17:39:50,090 StorageService.java (line 160) Added / 10.204.93.16/KeyspaceLogs as a bootstrap source ... (streaming mesages) DEBUG [Thread-56] 2010-11-07 17:45:51,706 StorageService.java (line 171) Removed /10.204.93.16/Keyspace1 as a bootstrap source; remaining is [/ 10.204.93.16] ... (and never ends). It seems it is waiting for [/10.204.93.16] when it should be waiting for / 10.204.93.16/KeyspaceLogs. The third node is 64 bits, while the two existing nodes are 32 bits. Can this be a problem? Thank you. 2010/10/28 Dimitry Lvovsky > Maybe your7000 is being blocked by iptables > or some firewall or maybe you have it bound ( tag ) to > localhost instead an ip address. > > Hope this helps, > Dimitry. > > > > On Thu, Oct 28, 2010 at 5:35 PM, Thibaut Britz < > thibaut.br...@trendiction.com> wrote: > >> Hi, >> >> I have the same problem with 0.6.5 >> >> New nodes will hang forever in bootstrap mode (no streams are being >> opened) and the receiver thread just waits for data forever: >> >> >> INFO [Thread-53] 2010-10-27 20:33:37,399 SSTableReader.java (line 120) >> Sampling index for /hd2/cassandra/data/table_xyz/ >> table_xyz-3-Data.db >> INFO [Thread-53] 2010-10-27 20:33:37,444 StreamCompletionHandler.java >> (line 64) Streaming added /hd2/cassandra/data/table_xyz/table_xyz-3-Data.db >> >> Stacktracke: >> >> "pool-1-thread-53" prio=10 tid=0x412f2800 nid=0x215c runnable >> [0x7fd7cf217000] >>java.lang.Thread.State: RUNNABLE >> at java.net.SocketInputStream.socketRead0(Native Method) >> at java.net.SocketInputStream.read(SocketInputStream.java:129) >> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) >> at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) >> at java.io.BufferedInputStream.read(BufferedInputStream.java:317) >> - locked <0x7fd7e77e0520> (a java.io.BufferedInputStream) >> at >> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:126) >> at >> org.apache.thrift.transport.TTransport.readAll(TTransport.java:84) >> at >> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:314) >> at >> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:262) >> at >> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:192) >> at >> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:1154) >> at >> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167) >> 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:662) >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Oct 28, 2010 at 12:44 PM, aaron morton >> wrote: >> >>> The best approach is to manually select the tokens, see the Load >>> Balancing section http://wiki.apache.org/cassandra/Operations Also >>> >>> Are there any log messages in the existing nodes or the new one which >>> mention each other? >>> >>> Is this a production system? Is it still running ? >>> >>> Sorry there is not a lot to go on, it sounds like you've done the right >>> thing. I'm assuming things like the Cluster Name, seed list and port numbers >>> are set correct as the new node got some data. >>> >>> You'll need to dig through the logs a bit more to see that the boot >>> strapping started and what was the last message it logged. >>> >>> Good Luck. >>> Aaron >>> >>> On 27 Oct 2010, at 22:40, Dimitry Lvovsky wrote: >>> >>> Hi Aaron, >>> Thanks for your reply. >>> >>> We still haven't solved this unfortunately. >>> >>> How did you start the bootstrap for the .18 node ? >>> >>> >>> Standard way: we set "AutoBootstrap" to true and added all the servers >>> from the working ring as seeds. >>> >>> Was it the .18 or the .17 node you tried to add >>> >>> >>> We first tried adding .17, it streamed for a while, took on a 50GB of >>> load, stopped streaming but then didn't enter into the ring. We left it for >>> a few days to see if it would come in, but no luck. After that we did >>> decommission and removeToken ( in that order) operations. >>> Since we couldn't get .17 in we tried again with .18. Before doing so we >>> increas
Design Question
Hi All, Can someone please validate and recommend a solution for the given design problem? *Problem statement:* Need to de-queue data from Cassandra (from Standard ColumnFamily) using a job but multiple instances of a job can run simultaneously (kinda multiple threads), trying to access a same row but need to make sure that only one instance of a job (thread) can access a row, meaning if job A is accessing Row #1, then job B can't access Row #1. *Possible solutions:* *Solution #1:* Using Cages (and ZooKeeper) to make sure that one only job at a time can access a row in CF. How do we make sure that Cages (transaction coordinator using ZooKeeper) is not a Single Point of Failure? What is the performance impact on write/read on nodes? There is some blog on distributed concurrent queue at http://www.cloudera.com/blog/2009/05/building-a-distributed-concurrent-queue-with-apache-zookeeper/ *Solution #2: *Using some home-grown approach to store/maintain who is accessing what, meaning which job is accessing which row. Are there any other solutions to the above problem? Can someone please help me on validate the design? -- Thanks, Mubarak Seyed.
Re: node won't leave
On 11/6/2010 8:26 PM, Jonathan Ellis wrote: > On Sat, Nov 6, 2010 at 4:51 PM, Reverend Chip wrote: >> Am I to understand that >> ring maintenance requests can just fail when partially complete, in the >> same manner as a regular insert might fail, perhaps due to inter-node >> RPC overflow? > Yes, in beta3 this can happen. This was fixed in CASSANDRA-1676. Interesting. I'll upgrade. Meanwhile, I waited until the next day, (!) and the cluster reformed somewhere in the meantime. I'm now seeing streaming to the new node. Is there an existing tool to just read everything from every node, just to force a read repair on everything? >> It would appear, then, that Cassandra isn't designed to be operated and >> understood without constant log watching of all nodes. > Not in beta, it's not. :) > > (In fact I would recommend running beta nodes at debug log level so > when something goes wrong you have a better picture of what happened.) Point taken :-)
