Skip to content

Conversation

@stillalex
Copy link
Member

No description provided.

Copy link
Contributor

@maedhroz maedhroz Jun 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stillalex There are two kinds of metrics for MVs. The first represents the conditionally registered metrics in TableMetrics, for example viewReadTime. Then you have ViewWriteMetrics which is created on the StorageProxy and spans tables. (I think I mentioned the latter a bit too carelessly in one of my earlier comments on the Jira. Apologies.)

In any case, all I think we need to do is drop this test at the end of TableMetricsTest (maybe renaming to testViewMetricsCleanupOnDrop())and we're golden. That will ensure that even MVs-specific metrics in TableMetrics are removed. Does that make sense?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll move the test over, sure. the trouble is I'm trying to verify (manually) that those metrics are actually created, otherwise that part of the code is not covered, so the test is not actually testing anything :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An MV actually has fewer metrics than a normal table, due to ViewLockAcquireTime and ViewReadTime being present only for the latter. This test is still valuable, as it makes sure removal still works when those aren't present (i.e. the conditional logic in releaseMetric()).

Either way, I don't think we need to worry about ViewWriteMetrics.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to verify here that ViewLockAcquireTime and ViewReadTime are created only the base table and not an MV, you could filter the names on each of them, etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for(ReleasableMetric metric : allMetrics)
for (ReleasableMetric metric : allMetrics)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for(ReleasableMetric entry : all)
for (ReleasableMetric entry : all)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same for KeyspaceMetrics

@stillalex
Copy link
Member Author

@maedhroz updated the PR based on your suggestions, let me know if you want to dig deeper into the MV tests, or if this is sufficient.

Copy link
Contributor

@maedhroz maedhroz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stillalex LGTM

The only other thing I might do w/ the tests is, if any metrics remain after drop, print their names. It might save posterity some time hunting down the offender(s) ;)

Thanks again for the patch!

@stillalex
Copy link
Member Author

@maedhroz very good suggestion! I changed the tests to include the metrics in the error message.

@maedhroz
Copy link
Contributor

@stillalex I think we're probably good to commit this, although squashing first might make it easier for the committer ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants