Re: another refactoring proposal
On 15-09-2010 19:16, Amol Deshpande wrote: 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. That would also open for the possibility to support more then one transport method on a single node. No? Could be handy in the transition phase from thrift to avro. And, one you implment his own transport layer. ./Morten
Re: Randomly read repair?
You're right, the simplest fix here is to just always do the re-read in the strong path. Done in r998720. (IMO the "right" thing is more complicated -- we shouldn't send requests to _all_ the replicas on the _first_ read with CL.QUORUM, except as dictated by randomlyReadRepair.) On Sat, Sep 18, 2010 at 9:39 AM, Zhu Han wrote: > Hi, > > I notice below code snippet in StorageProxy#strongRead(). Why the read > repair is still trigged randomly if digest is mis-matched for CL.Quorum > and CL.ALL. IMHO, the client wants the result to be returned is the > consistent one on those two CL. Read repair should be triggered > definitively here. > > If the client does not care about consistency, CL.ONE is the definitive > choice. For this level, read repair can be trigged randomly per the > configuration of key space. > > try >> { >> long startTime2 = System.currentTimeMillis(); >> row = quorumResponseHandler.get(); >> if (row != null) >> rows.add(row); >> >> if (logger.isDebugEnabled()) >> logger.debug("quorumResponseHandler: " + (System. >> currentTimeMillis() - startTime2) + " ms."); >> } >> catch (DigestMismatchException ex) >> { >> if (randomlyReadRepair(command)) >> { >> AbstractReplicationStrategy rs = StorageService. >> instance.getReplicationStrategy(command.table); >> QuorumResponseHandler qrhRepair = rs. >> getQuorumResponseHandler(new ReadResponseResolver(command.table), >> ConsistencyLevel.QUORUM); >> if (logger.isDebugEnabled()) >> logger.debug("Digest mismatch:", ex); >> Message messageRepair = command.makeReadMessage(); >> MessagingService.instance.sendRR(messageRepair, >> commandEndpoints.get(i), qrhRepair); >> if (repairResponseHandlers == null) >> repairResponseHandlers = new ArrayList< >> QuorumResponseHandler>(); >> repairResponseHandlers.add(qrhRepair); >> } >> > > > > > best regards, > hanzhu > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: Randomly read repair?
> > (IMO the "right" thing is more complicated -- we shouldn't send > requests to _all_ the replicas on the _first_ read with CL.QUORUM, > except as dictated by randomlyReadRepair.) > > I agree with you. But which replicas to send requests depends on the replication strategy... Only the nearest node should receive the requests. BTW, which version of cassandra was the randomly repair feature firstly implemented? 0.7 beta? > On Sat, Sep 18, 2010 at 9:39 AM, Zhu Han wrote: > > Hi, > > > > I notice below code snippet in StorageProxy#strongRead(). Why the read > > repair is still trigged randomly if digest is mis-matched for CL.Quorum > > and CL.ALL. IMHO, the client wants the result to be returned is the > > consistent one on those two CL. Read repair should be triggered > > definitively here. > > > > If the client does not care about consistency, CL.ONE is the definitive > > choice. For this level, read repair can be trigged randomly per the > > configuration of key space. > > > >try > >> { > >> long startTime2 = System.currentTimeMillis(); > >> row = quorumResponseHandler.get(); > >> if (row != null) > >> rows.add(row); > >> > >> if (logger.isDebugEnabled()) > >> logger.debug("quorumResponseHandler: " + (System. > >> currentTimeMillis() - startTime2) + " ms."); > >> } > >> catch (DigestMismatchException ex) > >> { > >> if (randomlyReadRepair(command)) > >> { > >> AbstractReplicationStrategy rs = StorageService. > >> instance.getReplicationStrategy(command.table); > >> QuorumResponseHandler qrhRepair = rs. > >> getQuorumResponseHandler(new ReadResponseResolver(command.table), > >> ConsistencyLevel.QUORUM); > >> if (logger.isDebugEnabled()) > >> logger.debug("Digest mismatch:", ex); > >> Message messageRepair = command.makeReadMessage(); > >> MessagingService.instance.sendRR(messageRepair, > >> commandEndpoints.get(i), qrhRepair); > >> if (repairResponseHandlers == null) > >> repairResponseHandlers = new ArrayList< > >> QuorumResponseHandler>(); > >> repairResponseHandlers.add(qrhRepair); > >> } > >> > > > > > > > > > > best regards, > > hanzhu > > > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
Re: Randomly read repair?
On Sun, Sep 19, 2010 at 8:58 PM, Zhu Han wrote: > BTW, which version of cassandra was the randomly repair feature firstly > implemented? 0.7 beta? yes -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
how to gen java interface source code in cassandra0.6.5?
Hi, I run "thrift -o thrift/ --gen java cassandra.thrift" to generate the java code. But I can't not complie the source code. Thrift version is 0.4.0-dev, My generated code are different from the code from svn. Why? How to generate the interface source code to "apache-cassandra-0.6.5-src/interface/thrift/gen-java"
Re: how to gen java interface source code in cassandra0.6.5?
thrift generated code changes frequently. check out the same revision of the thrift compiler that the jar in lib/ uses. On Mon, Sep 20, 2010 at 1:20 AM, summer.xie wrote: > Hi, > > I run "thrift -o thrift/ --gen java cassandra.thrift" to generate the java > code. But I can't not complie the source code. > > Thrift version is 0.4.0-dev, My generated code are different from the code > from svn. Why? > > How to generate the interface source code to > "apache-cassandra-0.6.5-src/interface/thrift/gen-java" > > > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com