[
https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678348#comment-17678348
]
Josh McKenzie commented on CASSANDRA-16325:
-------------------------------------------
{quote}if processing of downstream streaming listeners turn out to be a
bottleneck I think we should send the notifications on a separate thread versus
adding special logic to batch metric updates to not make this overly complex.
{quote}
In the "how do we solve for this case" I 100% agree. From the "we have lots of
metrics that are potentially contended and will be queried programmatically by
users via vtables" angle / lens, I think there might be a {{NoSpamLogger}}
analog worth pursuing here to socket and update metrics when something crosses
a certain threshold; trade off memory for reduced contention in general.
Definitely wouldn't block here on it but might be a nice defensive paradigm for
us to make idiomatic as we add more metrics.
> Update streaming metrics incrementally
> --------------------------------------
>
> Key: CASSANDRA-16325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16325
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
> Reporter: Paulo Motta
> Assignee: Isaac Reath
> Priority: Normal
> Labels: lhf
> Fix For: 4.2
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> Currently the inbound and outbound streamed bytes metrics are incremented
> after each file is streamed, what doesn't represent the current number of
> bytes streamed since it can take a long time for a large file to be streamed.
> We should update the metric incrementally as data is streamed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
