anton-vinogradov commented on code in PR #13454: URL: https://github.com/apache/ignite/pull/13454#discussion_r3752132092
########## modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerBuiltInUpdater.java: ########## @@ -0,0 +1,70 @@ +/* + * 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.ignite.internal.processors.datastreamer; + +import org.apache.ignite.stream.StreamReceiver; +import org.jetbrains.annotations.Nullable; + +/** + * The built-in updaters. Every node has them, so a request names the one it needs instead of carrying a serialized + * copy. + */ +enum DataStreamerBuiltInUpdater { + /** {@link DataStreamerImpl#ISOLATED_UPDATER}. */ + ISOLATED(DataStreamerImpl.ISOLATED_UPDATER), + + /** {@link DataStreamerCacheUpdaters#individual()}. */ + INDIVIDUAL(DataStreamerCacheUpdaters.individual()), Review Comment: Good catch on the coupling — the lookup no longer depends on it: ```java // Matches by class, so an updater built anew is still recognized as built-in: these updaters hold no state. if (builtIn.updater.getClass() == updater.getClass()) ``` So whatever `DataStreamerCacheUpdaters` decides to do with its instances, a built-in updater keeps travelling as a name. On the instances themselves I would leave them as they are, and not in this ticket: * they are handed out by public factories, so `individual()` and friends returning a new object each time changes what callers get — anyone comparing receivers, ours included until this commit, would notice; * a receiver is typically set once per streamer, but nothing stops a caller from doing it per streamer in a loop, and allocating a stateless object for that is a step back; * it is unrelated to what this ticket does, and the gain is three objects per JVM. Happy to file it separately if you think the factories should change. -- 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]
