Adding protocol buffers binding to client interface

[Amol Deshpande]

For various reasons (existing codebase, clients running C#, etc.), we
are considering implementing a client interface that understands Google
protocol buffers. 
>From browsing the source in trunk, it looks like the model to follow is
CassandraServer.java in org.apache.cassandra.avro

Is that the right place to start ? Are there other parts of the code
that are involved in implementing the client interface ?

Thanks,
-amol

RE: Adding protocol buffers binding to client interface

[Amol Deshpande]

We have our own internal framework on top of protobufs, which is probably the 
way I'm going for now.
Thanks,
-amol

-Original Message-
From: bbo...@gmail.com [mailto:bbo...@gmail.com] 
Sent: Tuesday, August 17, 2010 2:31 PM
To: dev@cassandra.apache.org
Subject: Re: Adding protocol buffers binding to client interface

"Amol Deshpande"  writes:
>
> Is that the right place to start ? Are there other parts of the code
> that are involved in implementing the client interface ?

just out of curiosity, which RPC implementation on top of protobuffers
are you planning on using?

-Bjørn

handling client network connections in Cassandra

[Amol Deshpande]

As I've mentioned before, I'm looking at implementing a  protobuf
interface for clients to talk to Cassandra. Looking at the source, I
don't see a network thread/connection pool that I could easily piggyback
on. This is probably because both thrift and avro seem to have their own
internal connection management.

Any opinions on apache MINA ?

Thanks,
-amol

CassandraDaemon setup() method

[Amol Deshpande]

Hi,
I noticed a lot of common code in the thrift and avro
CassandraDaemon.setup methods. Would it be possible to move those into a
commonSetup() method in the AbstractCassandraDaemon class ? This will be
helpful when I add a protocol buffer client-facing interface.

I just tried that and in a quick test the server seemed to start up just
fine both in thrift and in avro mode. 

Should I file a bug, send a patch, or both ?  (or neither :)

Thanks,
-amol

RE: CassandraDaemon setup() method

[Amol Deshpande]

https://issues.apache.org/jira/browse/CASSANDRA-1500

I've submitted the patch above. Please let me know if I've made  a mistake in 
the patch submission process. I tried to follow the instructions in the wiki.

Thanks,
-amol

-Original Message-
From: Jonathan Ellis [mailto:jbel...@gmail.com] 
Sent: Friday, September 10, 2010 12:17 PM
To: dev@cassandra.apache.org
Subject: Re: CassandraDaemon setup() method

Sounds fine to me.

On Fri, Sep 10, 2010 at 10:34 AM, Amol Deshpande
 wrote:
> Hi,
> I noticed a lot of common code in the thrift and avro
> CassandraDaemon.setup methods. Would it be possible to move those into a
> commonSetup() method in the AbstractCassandraDaemon class ? This will be
> helpful when I add a protocol buffer client-facing interface.
>
> I just tried that and in a quick test the server seemed to start up just
> fine both in thrift and in avro mode.
>
> Should I file a bug, send a patch, or both ?  (or neither :)
>
> Thanks,
> -amol
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

another refactoring proposal

[Amol Deshpande]

Hi,

Would there be any objections to the following code refactoring ?

1. Create a CassandraServerExceptionFactory class that returns various
exceptions that can be thrown by StorageProxy instead of thrift
exceptions.
2. Create a CassandraServerConsistencyLevel enum that is used instead of
thrift/avro definitions by the StorageProxy, with appropriate
translation methods between the enums (and perhaps a startup check
function that makes sure they are identical in value).
3. Create an AbstractCassandraServer superclass that exposes methods
like readColumnFamily in a transport-independent manner.

1 & 2 will make 3 possible and it lot easier to plug in other
client-facing protocols.

Thanks,
-amol