views:

148

answers:

2

I am having a lot of trouble trying to upgrade my existing library from Cassandra 0.6 to 0.7 beta1. I had originally thought it was a order of operations issue, so I decided to break it down to the basics.

Here is the basic setup that I will be suing

TTransport framedTransport = new TFramedTransport(new TSocket("localhost", 9160));
TTransport socketTransport = new TSocket("localhost", 9160);
TProtocol framedProtocol = new TBinaryProtocol(framedTransport);
TProtocol socketProtocol = new TBinaryProtocol(socketTransport);

Then I have tried to vary the setup of the client in the following ways switching the input and output protocols:

var client = new Cassandra.Client(framedProtocol, framedProtocol); // all framed
var client = new Cassandra.Client(socketProtocol, socketProtocol); // all socket
var client = new Cassandra.Client(framedProtocol, socketProtocol); // in: framed out: socket
var client = new Cassandra.Client(socketProtocol, framedProtocol); // in: socket out: framed

Then I execute the following program which uses the default Cassandra configuration that comes from the download and I am doing a simple request such as a count which I expect it to return zero since no data was inserted.

framedTransport.Open();
socketTransport.Open();
Console.WriteLine("Start");

client.set_keyspace("Keyspace1");

var key = System.Text.Encoding.ASCII.GetBytes("MyKey");
var columns = new List<byte[]>(new[] { System.Text.Encoding.ASCII.GetBytes("MyColumn") });
var column_parent = new ColumnParent {
    Column_family = "Standard1"
};
var predicate = new SlicePredicate {
    Column_names = columns
};
client.get_count(key, column_parent, predicate, ConsistencyLevel.ALL);

Console.WriteLine("Done");
Console.Read();

Each of the 4 different setups I provided above fail to execute. A couple of them just lock up and others throw an exception. So basically I am stuck trying to get a connection to work with the new Cassandra 0.7 with the .NET framework.

Here are the types of problems I found with each:

  • all framed: locks up on set_keyspace
  • all socket: throws Invalid method name: 'set_keyspace' on set_keyspace
  • in: framed out: socket: locks up on set_keyspace
  • in: socket out: framed: locks up on set_keyspace

I am 99% sure it has to do with something I am doing at the Thrift layer of Cassandra since I can't get this simple application to work. But if you want to browser my 0.7 branch you can find it here:

http://github.com/managedfusion/fluentcassandra/tree/0.7

A: 

Probably the C# thrift framed-mode code is buggy, because all that changed on the server side was making framed the default mode instead of unframed. You can switch it back in cassandra.yaml as a workaround.

(It's slightly insane to specify different protocols on the in/out sides of the connection. No other Thrift languages I know do that. If you dig into the code generation that is another thing to potentially fix.)

jbellis
Thrift client code hasn't changed since 0.2 for the most part. Also the input and output is a new addition to 0.7 that allows you to use different servers for your writing and reading. So I was just taking advantage of that to test out my code to see if there was a difference. **But regardless, I found the issue.** Since I was trying out 0.7 I put it in a different path, but what I didn't do was was register the environment variables to the new path I was using. So after that was done everything worked. Out of sight out of mind I guess.
Nick Berardi
A: 

I didn't update the environment variables in Windows to point to the new location of 0.7. So it was essentially running the stable version instead of the beta version. After I updated thee environment variable to point to the new location everything started working again.

Nick Berardi
so it was your fault running cassandra and you have voted -1 for jbellis answer, while he's mentioned most common situation when connecting to 0.7?
Viktor Jevdokimov
BTW, don't use environment variables.
Viktor Jevdokimov
No other way of easily launching the Cassandra batch file other than to use Environment Variables. And jbellis got voted down because everything he said was a personal opinion not based in fact at all. The C# Thrift code is not buggy, it is one of the libraries in Thrift that hasn't experienced any changes from 0.2 to 0.4. Second it is not insane to specify different protocols for in and out, especially if you want to use a different server for reading and writing. It got voted down because none of it was based in fact. BTW you shouldn't be using the voting system for spiteful actions.
Nick Berardi
BTW if you want to complain about the use of environment variables which I agree with you about on the Windows platform. Submit all gripes here https://issues.apache.org/jira/browse/CASSANDRA
Nick Berardi
Also what people call bugs in C# version of Thrift is usually their lack of understanding on Big Endian vs Little Endian. The .NET framework supports both, and Java only supports Big Endian, so if their machine is sending data using Little Endian to Cassandra which is Java based so therefore Big Endian they are going to have mis-matched types. I have seen this proclaimed as a Bug, but it is not because Thrift is a language independent protocol so it shouldn't care about Big vs Little Endian when transmitting data. Another reason why I *downvoted* jbellis, for spreading mis-information.
Nick Berardi