Alex, 1. Agree to deal with CacheEntryEvent as explained 2. ClientChannelDisconnectListener - can we have an overload with a parameter of this type?
ClientCache#query(ContinuousQuery) - compatible with Thick API ClientCache#query(ContinuousQuery, ClientChannelDisconnectListener) - specific to Thin, easy to discover Thoughts? On Fri, Apr 2, 2021 at 12:02 PM 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 > > >
