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/
ailto: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.s
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
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 connectio
ffers 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
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 ri
