cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Lohfink (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11569) Track message latency across DCs
Date Tue, 24 May 2016 18:34:13 GMT


Chris Lohfink commented on CASSANDRA-11569:

Thats how the messaging service works, droppable verbs will have a timeout associated with
them. If that timeout has passed, the message will be load shed. i.e. a write has a 5 second
timeout, if the mutation was received after 5 seconds, cassandra knows the client would of
gotten a timeout exception if it was required for the requested CL. That is essentially the
client being notified of the write /possibly/ failing (failed on this node but not necessarily
all of them).

Kinda not related to this ticket though.

> Track message latency across DCs
> --------------------------------
>                 Key: CASSANDRA-11569
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message