alex-plekhanov commented on a change in pull request #8960: URL: https://github.com/apache/ignite/pull/8960#discussion_r607567991
########## File path: modules/core/src/main/java/org/apache/ignite/internal/client/thin/ClientCacheEntryListenersRegistry.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.client.thin; + +import java.util.Map; +import java.util.concurrent.ConcurrentHashMap; +import javax.cache.configuration.CacheEntryListenerConfiguration; + +/** + * Per-cache cache entry listeners registry. Listeners can't be stored inside ClientCache instance, since there can be + * several such instances per one cache. + */ +public class ClientCacheEntryListenersRegistry { Review comment: > The same is true for Continuous Query - you can get a notification before you know the query ID and register the listener (and you can have multiple active queries). For CQ we don't need such strong guarantees. We can skip some events from the start and CQ still will be valid (it's like if we start listening a little bit later). > This is another piece of logic to be reused. > We can queue "unknown" notifications per resourceId and handle them as soon as listener is registered The difference between CQ and compute: compute can't skip notifications, compute has exactly one notification, taking into account this logic compute was implemented in such way, that unregistering listener performed when receiving notification. For CQ there can be many notifications per listener and listener unregistering should be performed when we close CQ. And if we will use some queue for pending notifications there will be notifications leaks after CQ closing, some notifications can stay in queue forever (as far as I understand C# implementation has the same problem). We can use some flag for notification type (use pending notification queue for compute and don't use it for CQ) to solve this problem, but I'm not sure that it's better than solution with different logic for different components. -- 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]
