Re: another refactoring proposal

2010-09-19 Thread Morten Wegelbye Nissen

 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?

2010-09-19 Thread Jonathan Ellis
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?

2010-09-19 Thread Zhu Han
>
> (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?

2010-09-19 Thread Jonathan Ellis
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?

2010-09-19 Thread summer.xie
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?

2010-09-19 Thread Jonathan Ellis
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