lukecwik commented on code in PR #22002: URL: https://github.com/apache/beam/pull/22002#discussion_r907571003
########## sdks/java/harness/src/main/java/org/apache/beam/fn/harness/control/Metrics.java: ########## @@ -0,0 +1,234 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.beam.fn.harness.control; + +import java.util.Map; +import java.util.concurrent.atomic.AtomicLong; +import java.util.concurrent.atomic.AtomicReference; +import javax.annotation.Nullable; +import javax.annotation.concurrent.NotThreadSafe; +import org.apache.beam.fn.harness.control.ProcessBundleHandler.BundleProcessor; +import org.apache.beam.runners.core.metrics.DistributionData; +import org.apache.beam.runners.core.metrics.MonitoringInfoEncodings; +import org.apache.beam.sdk.metrics.Counter; +import org.apache.beam.sdk.metrics.Distribution; +import org.apache.beam.sdk.metrics.MetricName; +import org.apache.beam.vendor.grpc.v1p43p2.com.google.protobuf.ByteString; + +public class Metrics { + + /** + * A {@link Counter} that is designed to report intermediate and final results and can be re-used + * after being reset. + */ + public interface BundleCounter extends BundleProgressReporter, Counter {} + + /** + * A {@link Distribution} that is designed to report intermediate and final results and can be + * re-used after being reset. + */ + public interface BundleDistribution extends BundleProgressReporter, Distribution {} + + /** + * Returns a counter that will report an accurate final value. + * + * <p>All invocations to {@link Counter} methods, {@link + * BundleProgressReporter#updateFinalMonitoringData}, and {@link BundleProgressReporter#reset()} + * must be done by the same thread. + * + * <p>All invocations to {@link BundleProgressReporter} methods must be done serially. + * + * <p>Invocations to {@link Counter} methods can be done concurrently to {@link + * BundleProgressReporter#updateIntermediateMonitoringData}. + */ + public static BundleCounter serialMutatorAndFinalReaderBundleCounter( + String shortId, MetricName name) { + return new SerialMutatorAndFinalReaderBundleCounter(shortId, name); + } + + /** + * Returns a {@link Distribution} that will report an accurate final value. + * + * <p>All invocations to {@link Distribution} methods, {@link + * BundleProgressReporter#updateFinalMonitoringData}, and {@link BundleProgressReporter#reset()} + * must be done by the same thread. + * + * <p>All invocations to {@link BundleProgressReporter} methods must be done serially. + * + * <p>Invocations to {@link Distribution} methods can be done concurrently to {@link + * BundleProgressReporter#updateIntermediateMonitoringData}. + */ + public static BundleDistribution serialMutatorAndFinalReaderBundleDistribution( + String shortId, MetricName name) { + return new SerialMutatorAndFinalReaderBundleDistribution(shortId, name); + } + + /** + * A {@link Counter} that shares the data using {@link AtomicReference#lazySet} to reduce + * synchronization overhead. This guarantees that intermediate progress reports will report a + * value that has been recently updated while the final progress report will get the true final + * value. + */ + @NotThreadSafe Review Comment: I think the issue is that it isn't thread safe to be called from arbitrary threads but is thread safe if used under a specific pattern. The thread interaction boils down to who owns: * (A) updating the counter * (B) reading intermediate progress * (C) reading final progress * (D) performing the reset The currently added counter requires A, C, D to be done via one thread or under a lock and B, C, D to be done either via one thread or while under a lock. The current setup has the main processing thread do A, C, D since it is one thread that does these always and B, C, D via lock. To address your concerns I simplified the comments down to how to use vs the general thread safety semantics which should help a lot in having them not used inappropriately. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
