[
https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057392#comment-13057392
]
Brandon Williams edited comment on CASSANDRA-2388 at 6/29/11 6:41 PM:
----------------------------------------------------------------------
{quote}
This does happen already (i've seen it while testing initial patches that were
no good).
Problem is that the TT is blacklisted, reducing hadoop's throughput for all
jobs running.
{quote}
If the cassandra node where the TT resides isn't working, then throughput is
reduced regardless.
bq. I bet too that a fallback to a replica is faster than a fallback to another
TT.
I doubt that for any significant job. Locality is important. Move the job to
the data, not the data to the job.
{quote}
There is no guarantee that any given TT will have its split accessible via a
local c* node - this is only a preference in CFRR. A failed task may just as
likely go to a random c* node. At least now we can actually properly limit to
the one DC and sort by proximity.
{quote}
This sounds like the thing we need to fix, then. Ensuring that the TT assigned
to the map has a local replica.
was (Author: brandon.williams):
{quote}
This does happen already (i've seen it while testing initial patches that were
no good).
Problem is that the TT is blacklisted, reducing hadoop's throughput for all
jobs running.
{quote}
If the cassandra node where the TT resides isn't working, then throughput is
reduced regardless.
bq. I bet too that a fallback to a replica is faster than a fallback to another
TT.
I doubt that for any significant job. Locality is important.
{quote}
There is no guarantee that any given TT will have its split accessible via a
local c* node - this is only a preference in CFRR. A failed task may just as
likely go to a random c* node. At least now we can actually properly limit to
the one DC and sort by proximity.
{quote}
This sounds like the thing we need to fix, then. Ensuring that the TT assigned
to the map has a local replica.
> ColumnFamilyRecordReader fails for a given split because a host is down, even
> if records could reasonably be read from other replica.
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2388
> Project: Cassandra
> Issue Type: Bug
> Components: Hadoop
> Affects Versions: 0.7.6, 0.8.0
> Reporter: Eldon Stegall
> Assignee: Jeremy Hanna
> Labels: hadoop, inputformat
> Fix For: 0.7.7, 0.8.2
>
> Attachments: 0002_On_TException_try_next_split.patch,
> CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch,
> CASSANDRA-2388.patch
>
>
> ColumnFamilyRecordReader only tries the first location for a given split. We
> should try multiple locations for a given split.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
