[
https://issues.apache.org/jira/browse/CASSANDRA-11569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299277#comment-15299277
]
stone edited comment on CASSANDRA-11569 at 5/25/16 2:08 AM:
------------------------------------------------------------
I konw that,what I confuse about is how to deal with the async write request.i.e
I have two datacenters,call source dc,dst dc.the CL is LOCAL_QUORUM,and each dc
has 3 replicator.
I run a long continue write workload on source dc,and if the latency between dc
is low,there is no problem,
but when the latency is high,async write request need more time than usual,so
some requests need to wait in the queue.
what I want to know,when the async request time is too long,will the source dc
think the node is down,and give up the request,then write hinted off like the
dst node really down.
I mean in dst dc,some of the async request will success,and some of the async
request will fail.
have found theory that support my thought.
"If the FD gives us the okay but writes time out anyway because of a failure
after the request is sent or because of an overload scenario, StorageProxy will
write a "hint" locally to replay the write when the replica(s) timing out
recover. This is called HintedHandoff. "
http://wiki.apache.org/cassandra/ArchitectureInternals
was (Author: stone):
I konw that,what I confuse about is how to deal with the async write request.i.e
I have two datacenters,call source dc,dst dc.the CL is LOCAL_QUORUM,and each dc
has 3 replicator.
I run a long continue write workload on source dc,and if the latency between dc
is low,there is no problem,
but when the latency is high,async write request need more time than usual,so
some requests need to wait in the queue.
what I want to know,when the async request time is too long,will the source dc
think the node is down,and give up the request,then write hinted off like the
dst node really down.
I mean in dst dc,some of the async request will success,and some of the async
request will fail.
> Track message latency across DCs
> --------------------------------
>
> Key: CASSANDRA-11569
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11569
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability
> Reporter: Chris Lohfink
> Assignee: Chris Lohfink
> Priority: Minor
> Attachments: CASSANDRA-11569.patch, CASSANDRA-11569v2.txt,
> nodeLatency.PNG
>
>
> Since we have the timestamp a message is created and when arrives, we can get
> an approximate time it took relatively easy and would remove necessity for
> more complex hacks to determine latency between DCs.
> Although is not going to be very meaningful when ntp is not setup, it is
> pretty common to have NTP setup and even with clock drift nothing is really
> hurt except the metric becoming whacky.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
