robertwb commented on a change in pull request #14805:
URL: https://github.com/apache/beam/pull/14805#discussion_r655735752
##########
File path:
runners/core-java/src/main/java/org/apache/beam/runners/core/metrics/MetricsContainerImpl.java
##########
@@ -84,9 +86,22 @@
private MetricsMap<KV<MetricName, HistogramData.BucketType>, HistogramCell>
histograms =
new MetricsMap<>(HistogramCell::new);
- /** Create a new {@link MetricsContainerImpl} associated with the given
{@code stepName}. */
+ /**
+ * Create a new {@link MetricsContainerImpl} associated with the given
{@code stepName}. If
+ * stepName is null, this MetricsContainer is not bound to a step.
+ */
public MetricsContainerImpl(@Nullable String stepName) {
this.stepName = stepName;
+ this.isProcessWide = false;
Review comment:
I must have been looking at a previous iteration of this code (or
getting it mixed up with others).
##########
File path:
runners/core-java/src/main/java/org/apache/beam/runners/core/metrics/MetricsContainerImpl.java
##########
@@ -84,9 +86,22 @@
private MetricsMap<KV<MetricName, HistogramData.BucketType>, HistogramCell>
histograms =
new MetricsMap<>(HistogramCell::new);
- /** Create a new {@link MetricsContainerImpl} associated with the given
{@code stepName}. */
+ /**
+ * Create a new {@link MetricsContainerImpl} associated with the given
{@code stepName}. If
+ * stepName is null, this MetricsContainer is not bound to a step.
Review comment:
It feels like that if MetricContainer[Impls] are only sometimes
associated with steps, the step association should be stored elsewhere, not as
part of this instance. But maybe that's too big a refactoring for now.
+1 to `MetricsContainerImpl.createProcessWideContainer()`; the nullary
constructor doesn't make it obvious the intent is to have this process-wide.
##########
File path:
sdks/java/harness/src/main/java/org/apache/beam/fn/harness/FnHarness.java
##########
@@ -262,6 +265,8 @@ public static void main(
}
});
+ MetricsEnvironment.setProcessWideContainer(new MetricsContainerImpl());
Review comment:
My preference is to have the tests be non-idiomatic (e.g. you could have
a reset-process-container-for-test method) than have the "production" code be
non-idiomatic to accommodate tests. Having a setter doesn't prevent state from
leaking from test to test (though I guess it forces you to set it in at least
one test).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]