[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-commits
Subject:    [jira] [Commented] (CASSANDRA-4886) Remote ColumnFamilyInputFormat
From:       "Scott Fines (JIRA)" <jira () apache ! org>
Date:       2012-10-31 19:26:11
Message-ID: 1419172885.52545.1351711571537.JavaMail.jiratomcat () arcas
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/CASSANDRA-4886?page=com.atlassian.jira.plu \
gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488132#comment-13488132 \
] 

Scott Fines commented on CASSANDRA-4886:
----------------------------------------

This is not a new InputFormat, this is a modification to ColumnFamilyRecordReader. \
And yes, this patch also suffers from not having good cross-DC support in a similar \
way. 

It seemed to me when reading CASSANDRA-2388, that there is some difficulty in making \
a single implementation work well in both situations. Rather than attempt to do that, \
then, this patch simply allows one to choose whether or not to act as if it's \
node-local or not.  
> Remote ColumnFamilyInputFormat
> ------------------------------
> 
> Key: CASSANDRA-4886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4886
> Project: Cassandra
> Issue Type: Improvement
> Components: Hadoop
> Affects Versions: 1.1.6
> Reporter: Scott Fines
> Fix For: 1.1.6
> 
> Attachments: CASSANDRA-4886.patch
> 
> 
> As written, the ColumnFamilyInputFormat does not have a great deal of fault \
> tolerance.  It only attempts to perform a read from a single replica, with an \
> infinite timeout. If that replica is not available, then the Task fails, and must \
> be retried on a different node. This is fine if the TaskTrackers are colocated with \
> Cassandra nodes, but is very fragile when this is not possible. When the \
> Tasktrackers are remote to cassandra, the same rules about clients should \
> apply--there should be a strict (configurable) timeout, and the ability to retry \
> requests on a different replica if at single request fails.  It seems obvious that \
> we'd want to support both types of architecture; to do that, we should probably \
> have a configuration which allows the user to specify his architecture choices \
> explicitely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[prev in list] [next in list] [prev in thread] [next in thread]