Hi Atri, The new interface is only needed for thin client, it's not a good idea to add such a method to thick client too.
пн, 5 апр. 2021 г. в 09:48, Atri Sharma <a...@apache.org>: > Hi Alex, > > Sorry for the late reply. > > Regarding the thick client, would it be a challenge to add a new method > which takes takes interface as parameter? That will not break the back > compatible > > On Fri, 2 Apr 2021, 14:32 Alex Plehanov, <plehanov.a...@gmail.com> wrote: > > > Hello, Atri > > > > 1. ClientChannelDisconnectListener is thin client specific. > > 2. Thick client API uses JCache interfaces, which cannot be modified. > > 2. We can't modify thick client public API either, due to backward > > compatibility. > > > > пт, 2 апр. 2021 г. в 11:51, Atri Sharma <a...@apache.org>: > > > > > Personally, I would disagree with an interface implementation being > > > dictated by the documentation rather than the method signature. > > > > > > How about having a generic interface (placeholder interface), have > > > both the thick and thin clients expose methods using the interface as > > > parameters, then let ClientChannelDisconnectListener actually > > > implement that interface and override the base methods? The methods > > > can be no-op in the thick clients. > > > > > > On Fri, Apr 2, 2021 at 2:04 PM Alex Plehanov <plehanov.a...@gmail.com> > > > wrote: > > > > > > > > Hello, Igniters! > > > > > > > > I'd like to discuss java thin client Continuous Queries public API. > > > > > > > > Currently, the thin client is not JCache compatible and without > JCache > > > > compatible cache instance we can't use classes and API which already > > used > > > > by the thick client for cache entry events listening. > > > > In my first attempt to implement thin client CQ I've tried to create > > own > > > CQ > > > > classes and interfaces for thin client, but such API looks weird. On > > the > > > > one hand, we should use CacheEntryEventFilter (JCache interface) > since > > > it's > > > > required by the server-side, on the other hand, we can't use > > > > CacheEntryUpdatedListener since it requires CacheEntryEvent which > > > requires > > > > an instance of Cache (JCache interface), which doesn't exist on the > > > > thin-client side. > > > > We've already discussed this problem with Pavel Tupitsyn in ticket > [1] > > > and > > > > come to an agreement that the most suitable solution is to implement > > some > > > > private thin-client cache to JCache adapter, but not expose it to > > public > > > > API and don't provide full JCache support by the thin client (see > > > comments > > > > in the ticket for more details). In this case, we can reuse CQ > classes > > > and > > > > interfaces and make the API similar to thick-client. > > > > > > > > Another problem: for the thin client we should be able to inform the > > user > > > > about channel failure. I propose to introduce some interface > > > > ClientChannelDisconnectListener and notify about channel failure if > > > > provided CacheEntryListener implements this interface. Unfortunately, > > if > > > we > > > > want to keep thin client API similar to the thick client we can't > > > > explicitly use this interface in methods parameters, so the knowledge > > > that > > > > user can use this interface for cache entry listener can be obtained > > only > > > > from JavaDoc or Ignite documentation. > > > > > > > > Igniters, WDYT? > > > > > > > > Here is PR with implemented proposals [2]. > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-14402 > > > > [2]: https://github.com/apache/ignite/pull/8960 > > > > > > -- > > > Regards, > > > > > > Atri > > > Apache Concerted > > > > > >
