[
https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083133#comment-13083133
]
Sylvain Lebresne commented on CASSANDRA-2034:
---------------------------------------------
I looked at the last patch to see if we don't mess up with counters here, and
it looks ok on that side.
A few comments on the patch while I'm at it:
* There is a few formatting that don't respect the codeStyle: some in
MessageService, some imports moved further from what the codeStyle dictate in
AbstractWriteResponseHandler and StorageProxy (that imports
quicktime.std.movies.ExecutingWiredAction!!)
* It seems we use the exact same timeout for hints and callback. However, given
that ExpiringMap is only so much precise, it seems to me we have like 50%
chance that the hint will expire before the callback, which means no hint will
be recorded (we could bump the timeout for hint to twice the one of callback,
and remove from mutationMessages once the hint is written; though I would
rather go for the next proposition if possible).
* Can't we reuse the callback expiring map for hints instead of creation a new
one. It's not like ExpiringMap is the cheapest thing around, and it seems like
each mutation message always have an attached callback with the exact same
lifetime. We could replace the Pair<InetAddress, IMessageCallback> by a
CallbackInfo (or some better name) class with a InetAddress and
IMessageCallback, and subclass it to CallbackInfoWithMessage when we need to
store the message too. I'm pretty sure it would much more efficient.
* In SP.sendToHintedEndpoints, there is no need to test if hintedHandoff is
enabled, because the hintedEndpoints map will only contain non-hinted target if
it is disabled (see AbstractReplicationStragegy.getHintedEndpoints).
> Make Read Repair unnecessary when Hinted Handoff is enabled
> -----------------------------------------------------------
>
> Key: CASSANDRA-2034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2034
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Patricio Echague
> Fix For: 1.0
>
> Attachments: 2034-formatting.txt, CASSANDRA-2034-trunk-v10.patch,
> CASSANDRA-2034-trunk-v2.patch, CASSANDRA-2034-trunk-v3.patch,
> CASSANDRA-2034-trunk-v4.patch, CASSANDRA-2034-trunk-v5.patch,
> CASSANDRA-2034-trunk-v6.patch, CASSANDRA-2034-trunk-v7.patch,
> CASSANDRA-2034-trunk-v8.patch, CASSANDRA-2034-trunk-v9.patch,
> CASSANDRA-2034-trunk.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> Currently, HH is purely an optimization -- if a machine goes down, enabling
> HH means RR/AES will have less work to do, but you can't disable RR entirely
> in most situations since HH doesn't kick in until the FailureDetector does.
> Let's add a scheduled task to the mutate path, such that we return to the
> client normally after ConsistencyLevel is achieved, but after RpcTimeout we
> check the responseHandler write acks and write local hints for any missing
> targets.
> This would making disabling RR when HH is enabled a much more reasonable
> option, which has a huge impact on read throughput.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
