[DISCUSSION] Java thin client: Continuous Queries public API

[Alexey Plekhanov]

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

[Atri Sharma-2]

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 <[hidden email]> 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

[Alexey Plekhanov]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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
>

[Pavel Tupitsyn]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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
> >
>

[Alexey Plekhanov]

Pavel,

Ok, I agree.

пт, 2 апр. 2021 г. в 18:47, Pavel Tupitsyn <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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
> > >
> >
>

[Atri Sharma-2]

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, <[hidden email]> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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
> >
>

[Alexey Plekhanov]

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 <[hidden email]>:

> 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, <[hidden email]> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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
> > >
> >
>

[Atri Sharma-2]

I do agree with your proposition, but the idea of an interface being
exposed through documentation seems a bit clunky to me.

On Mon, Apr 5, 2021 at 12:40 PM Alex Plehanov <[hidden email]> wrote:

>
> 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 <[hidden email]>:
>
> > 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, <[hidden email]> 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>
> > > > 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
> > > >
> > >
> >

--
Regards,

Atri
Apache Concerted