Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.
Andrey,
As you might know Java has it is own Reactive abstractions since 9
[1]. Moreover, an original Reactive Streams library has a bridge with
Java [2].
Personally I do not love CompletableFuture because it's API seems
questionable to me in various aspects, e.g. mentioned cancellation.
Currently I think that the cleanest way is custom abstractions
(possibly implementing CompletionStage) at first. And providing
bridges to other APIs (including CompletableFuture) as a next step.
Various API integrations can come in form of extensions.
> JDK classes are well-known and reactive frameworks usually have converters
to/from CompletableFuture [1] [2].
Here I have doubts that it is feasible to achieve it fairly. E.g. once
again cancellation. While reactive API supports cancellation it will
not be possible to cancel computation for anything built from
CompletableFuture.
[1]
https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/concurrent/Flow.Publisher.html
[2]
https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/FlowAdapters.html
2021-04-02 12:00 GMT+03:00, Andrey Mashenkov :
> Ivan,
> thanks for the link. I think, now I've got what you mean.
>
> I don't think we want to have any framework as a dependency and rely on
> their lifecycle, roadmaps goals and
> bother about compatibility.
> JDK classes are well-known and reactive frameworks usually have converters
> to/from CompletableFuture [1] [2].
> So, users are free to choose any reactive framework.
>
> I think will need reactive abstractions in near future for Queries API and
> maybe Transaction API design.
> These projects are good enough where we can get inspiration.
>
> [1]
> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html#fromFuture-java.util.concurrent.CompletableFuture-
> [2]
> https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/internal/jdk8/CompletableFromCompletionStage.java
>
> On Thu, Apr 1, 2021 at 1:29 PM Ivan Pavlukhin wrote:
>
>> Andrey,
>>
>> > Reactive abstractions look more suitable for Queries rather than
>> > cache/table async operations and don't offer the power of chaining like
>> > CompletableStage.
>>
>> Could you please elaborate what capabilities do you mean? AFAIK there
>> are quite powerful APIs for singular reactive abstractions as well.
>> E.g. [1].
>>
>> [1]
>> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html
>>
>> 2021-04-01 12:33 GMT+03:00, Andrey Mashenkov
>> :
>> > Val,
>> > I just complain JDK CompletableFuture itself is not ideal, but already
>> > implemented, well-known and tested.
>> > It still a good alternative compared to custom future implementation to
>> me.
>> >
>> > Ok, I feel most of us agree with CompletableFuture as a replacement for
>> > custom IgniteFuture.
>> > Let's try to use it, but keep in mind that we MUST return a defective
>> copy
>> > (via copy() or minimalStage()) to user to prevent misusage on the user
>> > side.
>> > It would be nice if we'll follow the same requirement in our internal
>> code,
>> > e.g. if a component returns a future that further can be used in other
>> > components, especially in custom plugins.
>> >
>> > Ivan, thanks for the example.
>> > Reactive abstractions look more suitable for Queries rather than
>> > cache/table async operations and don't offer the power of chaining like
>> > CompletableStage.
>> > AFAIK, guys who involved in SQL engine development based on Calcite
>> already
>> > use reactive patterns.
>> >
>> >
>> > On Thu, Apr 1, 2021 at 3:15 AM Ivan Pavlukhin
>> wrote:
>> >
>> >> Folks,
>> >>
>> >> Regarding Reactive abstractions. While it might look too complex for
>> >> simple KV cases it can be quite powerful for queries. Also there are
>> >> known solutions for cancellation, backpressure and flow control. It
>> >> can greatly simplify things for users familiar with Reactive
>> >> programming rather than learning Ignite-specific Query/QueryCursor
>> >> API.
>> >>
>> >> Also it looks like there are well-defined semantics [1]. E.g.
>> >> cancellation seems to be defined much better than for
>> >> CompletableFuture.
>> >>
>> >> [1]
>> >> https://github.com/reactive-streams/reactive-streams-jvm#specification
>> >>
>> >> 2021-03-31 21:30 GMT+03:00, Valentin Kulichenko <
>> >> valentin.kuliche...@gmail.com>:
>> >> > Hi Andrey,
>> >> >
>> >> > Please see below.
>> >> >
>> >> > -Val
>> >> >
>> >> > On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov
>> >> >
>> >> > wrote:
>> >> >
>> >> >> CompletableFuture cancellation will not work as many users
>> >> >> expected.
>> >> >> Javadoc says:
>> >> >> /* Since (unlike {@link FutureTask}) this class has no direct
>> >> >> * control over the computation that causes it to be completed,
>> >> >> * cancellation is treated as just another form of exceptional
>> >> >> * completion.
>> >> >> */
>> >> >>
>> >> >
>> >> > Let's not make assumptions about the expectations of the users.
>> >> >
Re: [DISCUSS] Release performance-statistics-ext, spring-data-ext and spring-tx-ext Ignite extensions
Is this the first time we're releasing spring data 2.2 as an ext? Can't find any version available for 2.10? What should I use if I need Spring Data integration now for Ignite 2.10? https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data_2.2 - Denis On Fri, Mar 26, 2021 at 12:55 AM Nikita Amelchev wrote: > Hi, Denis. > > > - How is the performance stats ext is different from the profiling tool > > released in 2.10? > > The performance statistics extension is a script to build an HTML > report. The core module collects statistics to binary files and this > feature was released in 2.10. > > чт, 25 мар. 2021 г. в 21:05, Denis Magda : > > > > +1 > > > > I missed our progress on the extensions frontier. Great to see more > > capabilities added to the Spring framework support. > > > > Several questions (but, I fully support the release of the extensions): > > > >- How is the performance stats ext is different from the profiling > tool > >released in 2.10? > >- I've created this tutorial[1] a while ago for the Spring Data > >integration. Would you advise updating it considering any new features > >(such as thin-client support)? > >- Don't you want guys to submit a talk to the Ignite Summit[2]? It can > >be a "hitchhiker guide to the Spring support in Ignite" or "Using > Profiling > >to Solve Performance issues in Ignite". Happy to help with an > abstract. > > > > > > [1] > https://www.gridgain.com/docs/tutorials/spring/spring-ignite-tutorial > > [2] https://ignite-summit.org > > > > - > > Denis > > > > > > On Thu, Mar 25, 2021 at 10:26 AM Nikita Amelchev > > wrote: > > > > > Igniters, > > > > > > Since Ignite 2.10 has been released, I think we can now release new > > > extension modules: > > > > > > performance-statistics-ext > > > spring-data-ext > > > spring-tx-ext > > > > > > I want to be a release manager for these if nobody minds. > > > > > > The release process can be started after resolving a few documentation > > > issues: > > > > > > https://issues.apache.org/jira/browse/IGNITE-14417 > > > https://issues.apache.org/jira/browse/IGNITE-14398 > > > https://issues.apache.org/jira/browse/IGNITE-14397 > > > https://issues.apache.org/jira/browse/IGNITE-13769 > > > > > > -- > > > Best wishes, > > > Amelchev Nikita > > > > > > > -- > Best wishes, > Amelchev Nikita >
Re: [DISCUSSION] Java thin client: Continuous Queries public API
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 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 : > > > 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 > > 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 > > >
[jira] [Created] (IGNITE-14472) Performance drop on primitive operations.
Ivan Daschinskiy created IGNITE-14472: - Summary: Performance drop on primitive operations. Key: IGNITE-14472 URL: https://issues.apache.org/jira/browse/IGNITE-14472 Project: Ignite Issue Type: Bug Components: python, thin client Affects Versions: python-0.4.0 Reporter: Ivan Daschinskiy Reason of performance drop: header struct of Response is not cached (now it is instance variable, earlier it will be class variable) Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14471) JDBCv2: query cursors leak when node to execute queries is specified
Taras Ledkov created IGNITE-14471: - Summary: JDBCv2: query cursors leak when node to execute queries is specified Key: IGNITE-14471 URL: https://issues.apache.org/jira/browse/IGNITE-14471 Project: Ignite Issue Type: Improvement Components: sql Reporter: Taras Ledkov Assignee: Taras Ledkov Query cursors leak when node to execute queries is specified. In this case the query tasks are executed on the remote node instead of client node launched by the JDBC v2 client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14470) Thin client application service
Anton Vinogradov created IGNITE-14470: - Summary: Thin client application service Key: IGNITE-14470 URL: https://issues.apache.org/jira/browse/IGNITE-14470 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Allow starting thin client within the java application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Azure Cloud IP Finder
Hello,
Thank you for sharing.
I was finally able to replicate the issue. However, I tried with other
IPFinders and ran into the same problem (attached are the logs).
Not sure what is causing this?
Atri
On Fri, Apr 2, 2021 at 2:29 PM Ilya Kasnacheev
wrote:
>
> Hello!
>
> Please find attached the log file of errors. This is yesterday's (Apr 1)
> build.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 2 апр. 2021 г. в 11:52, Atri Sharma :
>>
>> I was able to, but then, it might be that something is cached locally.
>>
>> What errors did you run into? (I am assuming you are trying with a
>> build from the latest iteration of the PR).
>>
>> Atri
>>
>> On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev
>> wrote:
>> >
>> > Hello!
>> >
>> > But are you successful in running a node with Azure IP finder enabled in
>> > configuration, starting from that release directory?
>> >
>> > I amn't.
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
>> >
>> > > Hello,
>> > >
>> > > Thank you for taking a look.
>> > >
>> > > I am not sure what the confusion is. On the current iteration of PR, I
>> > > am able to build and release and looking in the location you
>> > > mentioned, I see:
>> > >
>> > > Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
>> > >
>> > > Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
>> > >
>> > > Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
>> > >
>> > > README.txt azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
>> > >
>> > >
>> > > Attached is the screenshot.
>> > >
>> > > I have fixed the comments on the PR, please see and let me know.
>> > >
>> > > Atri
>> > >
>> > > On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
>> > > wrote:
>> > > >
>> > > > Hello!
>> > > >
>> > > > Were you successful with using it from the deliverable of mvn
>> > > > initialize
>> > > > -Prelease?
>> > > >
>> > > > Please refer for example to aws module dependencies section:
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-java-sdk-core
>> > > > ${aws.sdk.version}
>> > > >
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-java-sdk-s3
>> > > > ${aws.sdk.version}
>> > > >
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-java-sdk-ec2
>> > > > ${aws.sdk.version}
>> > > >
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-java-sdk-elasticloadbalancing
>> > > > ${aws.sdk.version}
>> > > >
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-java-sdk-elasticloadbalancingv2
>> > > > ${aws.sdk.version}
>> > > >
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-java-sdk-kms
>> > > > ${aws.sdk.version}
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > com.fasterxml.jackson.core
>> > > > jackson-core
>> > > > ${jackson.version}
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > com.fasterxml.jackson.core
>> > > > jackson-annotations
>> > > > ${jackson.version}
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > com.fasterxml.jackson.core
>> > > > jackson-databind
>> > > > ${jackson.version}
>> > > >
>> > > >
>> > > >
>> > > > com.amazonaws
>> > > > aws-encryption-sdk-java
>> > > > ${aws.encryption.sdk.version}
>> > > >
>> > > >
>> > > > org.bouncycastle
>> > > > bcprov-ext-jdk15on
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > org.bouncycastle
>> > > > bcprov-ext-jdk15on
>> > > > ${bouncycastle.version}
>> > > >
>> > > >
>> > > >
>> > > > joda-time
>> > > > joda-time
>> > > > 2.8.1
>> > > >
>> > > >
>> > > >
>> > > > org.apache.httpcomponents
>> > > > httpclient
>> > > > ${httpclient.version}
>> > > >
>> > > >
>> > > >
>> > > > org.apache.httpcomponents
>> > > > httpcore
>> > > > ${httpcore.version}
>> > > >
>> > > >
>> > > > azure module should likewise list all of its actual dependencies. Right
>> > > now
>> > > > the module directory is empty so I'm not even going to test to run it
>> > > > in
>> > > > stand-alone mode:
>> > > > ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin% ls
>> > > libs/optional/ignite-azure
>> > > > azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
>> > > README.txt
>> > > >
>> > > > Please address this issue along with other things which I have also
>> > > > commented on the PR.
>> > > >
>> > > > Regards,
>> > > > --
>> > > > Ilya Kasnacheev
>> > > >
>> > > >
>> > > > ср, 31 мар. 2021 г. в 08:17, Atri Sharma :
>> > > >
>> > > > > Thank you for the review.
>> > > > >
>> > > > > I have updated the PR. Please see.
>> > > > >
>> > > > > On Mon, Mar 29, 2021 at 8:27 PM Ilya Kasnacheev
>> > > > > wrote:
>> > > > > >
>> > > > > > Hello!
>> > > > > >
>> > > > > > I have left some more comments after trying this change on a real
>> > > Azure
>> > > > > > cluster.
>> > > > > >
>> > > > > > Regards,
>> > > > > > --
>> > > > > > Ilya Kasnacheev
>> > > > > >
>> > > >
[jira] [Created] (IGNITE-14469) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
Kirill Tkalenko created IGNITE-14469: Summary: Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild Key: IGNITE-14469 URL: https://issues.apache.org/jira/browse/IGNITE-14469 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 2.11 After the IGNITE-14321 is implemented, it will be necessary to add to the command *control.sh --cache indexes_force_rebuild* the ability to display to the user that the forced rebuilding of the indexes is impossible, since they are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14468) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
Kirill Tkalenko created IGNITE-14468: Summary: Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild Key: IGNITE-14468 URL: https://issues.apache.org/jira/browse/IGNITE-14468 Project: Ignite Issue Type: Improvement Components: control.sh, sql Reporter: Kirill Tkalenko Fix For: 2.11 After the IGNITE-14321 is implemented, it will be necessary to add to the command the ability to display to the user that the forced rebuilding of the indexes is impossible, since they are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14467) Ignite Compute service.
Andrey Mashenkov created IGNITE-14467: - Summary: Ignite Compute service. Key: IGNITE-14467 URL: https://issues.apache.org/jira/browse/IGNITE-14467 Project: Ignite Issue Type: New Feature Reporter: Andrey Mashenkov Port IgniteCompute component from 2.0 to 3.0. Rework ComputeTask/ComputeJob interfaces to make them compliant with JDK CompletableStage API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14466) Changing cache configuration once cache is created confuses PME on node join
Ilya Kasnacheev created IGNITE-14466:
Summary: Changing cache configuration once cache is created
confuses PME on node join
Key: IGNITE-14466
URL: https://issues.apache.org/jira/browse/IGNITE-14466
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: Ilya Kasnacheev
The following code triggers the issue:
{code:java}
inputCache = ignite.cache(inputCacheName);
CacheConfiguration configuration =
inputCache.getConfiguration(CacheConfiguration.class);
outputCache = ignite.getOrCreateCache(configuration.setName("cache_" +
ctx.name()));
{code}
It is possible for user code to accidentally reuse the same cache configuration
instance when creating caches (see linked example). This causes the following
hard to debug NPE:
{code:java}
Mar 30, 2021 11:53:25 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Exception in discovery notyfier worker thread.
java.lang.NullPointerException
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.addClientNode(GridDiscoveryManager.java:445)
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.processCacheChangeRequests(ClusterCachesInfo.java:596)
at
org.apache.ignite.internal.processors.cache.ClusterCachesInfo.onCacheChangeRequested(ClusterCachesInfo.java:430)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onCustomEvent(GridCacheProcessor.java:3827)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:697)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:604)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2667)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2705)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
We should, maybe, clone a cache configuration before putting it to our internal
data structures? Or better, serialize-deserialize as all of the remaining nodes
in the cluster do.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSSION] Java thin client: Continuous Queries public API
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 : > 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 > 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 >
Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.
Ivan,
thanks for the link. I think, now I've got what you mean.
I don't think we want to have any framework as a dependency and rely on
their lifecycle, roadmaps goals and
bother about compatibility.
JDK classes are well-known and reactive frameworks usually have converters
to/from CompletableFuture [1] [2].
So, users are free to choose any reactive framework.
I think will need reactive abstractions in near future for Queries API and
maybe Transaction API design.
These projects are good enough where we can get inspiration.
[1]
https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html#fromFuture-java.util.concurrent.CompletableFuture-
[2]
https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/internal/jdk8/CompletableFromCompletionStage.java
On Thu, Apr 1, 2021 at 1:29 PM Ivan Pavlukhin wrote:
> Andrey,
>
> > Reactive abstractions look more suitable for Queries rather than
> > cache/table async operations and don't offer the power of chaining like
> > CompletableStage.
>
> Could you please elaborate what capabilities do you mean? AFAIK there
> are quite powerful APIs for singular reactive abstractions as well.
> E.g. [1].
>
> [1]
> https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Mono.html
>
> 2021-04-01 12:33 GMT+03:00, Andrey Mashenkov :
> > Val,
> > I just complain JDK CompletableFuture itself is not ideal, but already
> > implemented, well-known and tested.
> > It still a good alternative compared to custom future implementation to
> me.
> >
> > Ok, I feel most of us agree with CompletableFuture as a replacement for
> > custom IgniteFuture.
> > Let's try to use it, but keep in mind that we MUST return a defective
> copy
> > (via copy() or minimalStage()) to user to prevent misusage on the user
> > side.
> > It would be nice if we'll follow the same requirement in our internal
> code,
> > e.g. if a component returns a future that further can be used in other
> > components, especially in custom plugins.
> >
> > Ivan, thanks for the example.
> > Reactive abstractions look more suitable for Queries rather than
> > cache/table async operations and don't offer the power of chaining like
> > CompletableStage.
> > AFAIK, guys who involved in SQL engine development based on Calcite
> already
> > use reactive patterns.
> >
> >
> > On Thu, Apr 1, 2021 at 3:15 AM Ivan Pavlukhin
> wrote:
> >
> >> Folks,
> >>
> >> Regarding Reactive abstractions. While it might look too complex for
> >> simple KV cases it can be quite powerful for queries. Also there are
> >> known solutions for cancellation, backpressure and flow control. It
> >> can greatly simplify things for users familiar with Reactive
> >> programming rather than learning Ignite-specific Query/QueryCursor
> >> API.
> >>
> >> Also it looks like there are well-defined semantics [1]. E.g.
> >> cancellation seems to be defined much better than for
> >> CompletableFuture.
> >>
> >> [1]
> >> https://github.com/reactive-streams/reactive-streams-jvm#specification
> >>
> >> 2021-03-31 21:30 GMT+03:00, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com>:
> >> > Hi Andrey,
> >> >
> >> > Please see below.
> >> >
> >> > -Val
> >> >
> >> > On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov
> >> >
> >> > wrote:
> >> >
> >> >> CompletableFuture cancellation will not work as many users expected.
> >> >> Javadoc says:
> >> >> /* Since (unlike {@link FutureTask}) this class has no direct
> >> >> * control over the computation that causes it to be completed,
> >> >> * cancellation is treated as just another form of exceptional
> >> >> * completion.
> >> >> */
> >> >>
> >> >
> >> > Let's not make assumptions about the expectations of the users. That's
> >> > exactly why I initially leaned towards a custom interface as well, but
> >> > that's a mistake.
> >> > Indeed, this contract might look weird to us, because the current
> >> > version
> >> > of Ignite behaves differently. However, there are much more developers
> >> > using CompletableFuture and other standard async frameworks, than
> >> > developers using the async functionality of Ignite. Therefore, our
> >> > intuitions can easily be wrong.
> >> >
> >> >
> >> >> Completion of a child future doesn't trigger the completion of a
> >> >> parent.
> >> >> So, we will need to extend the future anyway.
> >> >>
> >> >
> >> > First of all, as Pavel mentioned, you can attach your own listener
> >> > before
> >> > returning a CompletableFuture to the user. You don't need to extend.
> >> > Second of all, there is still a discussion to be had on whether the
> >> parent
> >> > needs to be completed. I don't actually think it's obvious, and most
> >> likely
> >> > it's case by case. With CompletableFuture you have enough flexibility
> >> > to
> >> > control the behavior.
> >> >
> >> >
> >> >>
> >> >> Also, cancel() method contract differs from IgniteFuture in 2.0,
> >> >> Completable method return true if the future was cancelled,
> >> >> but IgniteFuture
Re: Azure Cloud IP Finder
Hello!
Please find attached the log file of errors. This is yesterday's (Apr 1)
build.
Regards,
--
Ilya Kasnacheev
пт, 2 апр. 2021 г. в 11:52, Atri Sharma :
> I was able to, but then, it might be that something is cached locally.
>
> What errors did you run into? (I am assuming you are trying with a
> build from the latest iteration of the PR).
>
> Atri
>
> On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev
> wrote:
> >
> > Hello!
> >
> > But are you successful in running a node with Azure IP finder enabled in
> > configuration, starting from that release directory?
> >
> > I amn't.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
> >
> > > Hello,
> > >
> > > Thank you for taking a look.
> > >
> > > I am not sure what the confusion is. On the current iteration of PR, I
> > > am able to build and release and looking in the location you
> > > mentioned, I see:
> > >
> > > Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
> > >
> > > Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
> > >
> > > Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
> > >
> > > README.txt azure-storage-blob-12.0.0.jar
> ignite-azure-2.11.0-SNAPSHOT.jar
> > >
> > >
> > > Attached is the screenshot.
> > >
> > > I have fixed the comments on the PR, please see and let me know.
> > >
> > > Atri
> > >
> > > On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > Were you successful with using it from the deliverable of mvn
> initialize
> > > > -Prelease?
> > > >
> > > > Please refer for example to aws module dependencies section:
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-java-sdk-core
> > > > ${aws.sdk.version}
> > > >
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-java-sdk-s3
> > > > ${aws.sdk.version}
> > > >
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-java-sdk-ec2
> > > > ${aws.sdk.version}
> > > >
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-java-sdk-elasticloadbalancing
> > > > ${aws.sdk.version}
> > > >
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-java-sdk-elasticloadbalancingv2
> > > > ${aws.sdk.version}
> > > >
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-java-sdk-kms
> > > > ${aws.sdk.version}
> > > >
> > > >
> > > >
> > > >
> > > > com.fasterxml.jackson.core
> > > > jackson-core
> > > > ${jackson.version}
> > > >
> > > >
> > > >
> > > >
> > > > com.fasterxml.jackson.core
> > > > jackson-annotations
> > > > ${jackson.version}
> > > >
> > > >
> > > >
> > > >
> > > > com.fasterxml.jackson.core
> > > > jackson-databind
> > > > ${jackson.version}
> > > >
> > > >
> > > >
> > > > com.amazonaws
> > > > aws-encryption-sdk-java
> > > > ${aws.encryption.sdk.version}
> > > >
> > > >
> > > > org.bouncycastle
> > > > bcprov-ext-jdk15on
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > org.bouncycastle
> > > > bcprov-ext-jdk15on
> > > > ${bouncycastle.version}
> > > >
> > > >
> > > >
> > > > joda-time
> > > > joda-time
> > > > 2.8.1
> > > >
> > > >
> > > >
> > > > org.apache.httpcomponents
> > > > httpclient
> > > > ${httpclient.version}
> > > >
> > > >
> > > >
> > > > org.apache.httpcomponents
> > > > httpcore
> > > > ${httpcore.version}
> > > >
> > > >
> > > > azure module should likewise list all of its actual dependencies.
> Right
> > > now
> > > > the module directory is empty so I'm not even going to test to run
> it in
> > > > stand-alone mode:
> > > > ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin% ls
> > > libs/optional/ignite-azure
> > > > azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
> > > README.txt
> > > >
> > > > Please address this issue along with other things which I have also
> > > > commented on the PR.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 31 мар. 2021 г. в 08:17, Atri Sharma :
> > > >
> > > > > Thank you for the review.
> > > > >
> > > > > I have updated the PR. Please see.
> > > > >
> > > > > On Mon, Mar 29, 2021 at 8:27 PM Ilya Kasnacheev
> > > > > wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I have left some more comments after trying this change on a real
> > > Azure
> > > > > > cluster.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > вт, 23 мар. 2021 г. в 18:32, Atri Sharma :
> > > > > >
> > > > > > > Thank you!
> > > > > > >
> > > > > > > I have updated the PR. Please see and let me know.
> > > > > > >
> > > > > > > On Tue, Mar 23, 2021 at 4:27 PM Ilya Kasnacheev
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > I am going to check this change out when I have time, using
> my
> > > Azure
> > > > > > > > account.
> > > > > > > >
> > > > > > > >
Re: Azure Cloud IP Finder
I was able to, but then, it might be that something is cached locally.
What errors did you run into? (I am assuming you are trying with a
build from the latest iteration of the PR).
Atri
On Fri, Apr 2, 2021 at 2:19 PM Ilya Kasnacheev
wrote:
>
> Hello!
>
> But are you successful in running a node with Azure IP finder enabled in
> configuration, starting from that release directory?
>
> I amn't.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
>
> > Hello,
> >
> > Thank you for taking a look.
> >
> > I am not sure what the confusion is. On the current iteration of PR, I
> > am able to build and release and looking in the location you
> > mentioned, I see:
> >
> > Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
> >
> > Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
> >
> > Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
> >
> > README.txt azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
> >
> >
> > Attached is the screenshot.
> >
> > I have fixed the comments on the PR, please see and let me know.
> >
> > Atri
> >
> > On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
> > wrote:
> > >
> > > Hello!
> > >
> > > Were you successful with using it from the deliverable of mvn initialize
> > > -Prelease?
> > >
> > > Please refer for example to aws module dependencies section:
> > >
> > >
> > > com.amazonaws
> > > aws-java-sdk-core
> > > ${aws.sdk.version}
> > >
> > >
> > >
> > > com.amazonaws
> > > aws-java-sdk-s3
> > > ${aws.sdk.version}
> > >
> > >
> > >
> > > com.amazonaws
> > > aws-java-sdk-ec2
> > > ${aws.sdk.version}
> > >
> > >
> > >
> > > com.amazonaws
> > > aws-java-sdk-elasticloadbalancing
> > > ${aws.sdk.version}
> > >
> > >
> > >
> > > com.amazonaws
> > > aws-java-sdk-elasticloadbalancingv2
> > > ${aws.sdk.version}
> > >
> > >
> > >
> > > com.amazonaws
> > > aws-java-sdk-kms
> > > ${aws.sdk.version}
> > >
> > >
> > >
> > >
> > > com.fasterxml.jackson.core
> > > jackson-core
> > > ${jackson.version}
> > >
> > >
> > >
> > >
> > > com.fasterxml.jackson.core
> > > jackson-annotations
> > > ${jackson.version}
> > >
> > >
> > >
> > >
> > > com.fasterxml.jackson.core
> > > jackson-databind
> > > ${jackson.version}
> > >
> > >
> > >
> > > com.amazonaws
> > > aws-encryption-sdk-java
> > > ${aws.encryption.sdk.version}
> > >
> > >
> > > org.bouncycastle
> > > bcprov-ext-jdk15on
> > >
> > >
> > >
> > >
> > >
> > > org.bouncycastle
> > > bcprov-ext-jdk15on
> > > ${bouncycastle.version}
> > >
> > >
> > >
> > > joda-time
> > > joda-time
> > > 2.8.1
> > >
> > >
> > >
> > > org.apache.httpcomponents
> > > httpclient
> > > ${httpclient.version}
> > >
> > >
> > >
> > > org.apache.httpcomponents
> > > httpcore
> > > ${httpcore.version}
> > >
> > >
> > > azure module should likewise list all of its actual dependencies. Right
> > now
> > > the module directory is empty so I'm not even going to test to run it in
> > > stand-alone mode:
> > > ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin% ls
> > libs/optional/ignite-azure
> > > azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
> > README.txt
> > >
> > > Please address this issue along with other things which I have also
> > > commented on the PR.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 31 мар. 2021 г. в 08:17, Atri Sharma :
> > >
> > > > Thank you for the review.
> > > >
> > > > I have updated the PR. Please see.
> > > >
> > > > On Mon, Mar 29, 2021 at 8:27 PM Ilya Kasnacheev
> > > > wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > I have left some more comments after trying this change on a real
> > Azure
> > > > > cluster.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > вт, 23 мар. 2021 г. в 18:32, Atri Sharma :
> > > > >
> > > > > > Thank you!
> > > > > >
> > > > > > I have updated the PR. Please see and let me know.
> > > > > >
> > > > > > On Tue, Mar 23, 2021 at 4:27 PM Ilya Kasnacheev
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > I am going to check this change out when I have time, using my
> > Azure
> > > > > > > account.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > вт, 23 мар. 2021 г. в 07:20, Atri Sharma :
> > > > > > >
> > > > > > > > Gentle reminder on this -- please help in reviewing this.
> > > > > > > >
> > > > > > > > On Fri, Mar 19, 2021 at 10:23 AM Atri Sharma
> > > > wrote:
> > > > > > > > >
> > > > > > > > > Thanks Denis.
> > > > > > > > >
> > > > > > > > > I have raised a PR for the same:
> > > > > > > > >
> > > > > > > > > https://github.com/apache/ignite/pull/8897
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > >
Re: [DISCUSSION] Java thin client: Continuous Queries public API
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 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
Re: Azure Cloud IP Finder
Hello!
But are you successful in running a node with Azure IP finder enabled in
configuration, starting from that release directory?
I amn't.
Regards,
--
Ilya Kasnacheev
пт, 2 апр. 2021 г. в 07:42, Atri Sharma :
> Hello,
>
> Thank you for taking a look.
>
> I am not sure what the confusion is. On the current iteration of PR, I
> am able to build and release and looking in the location you
> mentioned, I see:
>
> Atris-MacBook-Pro-15:libs atrisharma$ cd optional/
>
> Atris-MacBook-Pro-15:optional atrisharma$ cd ignite-azure/
>
> Atris-MacBook-Pro-15:ignite-azure atrisharma$ ls
>
> README.txt azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
>
>
> Attached is the screenshot.
>
> I have fixed the comments on the PR, please see and let me know.
>
> Atri
>
> On Thu, Apr 1, 2021 at 8:21 PM Ilya Kasnacheev
> wrote:
> >
> > Hello!
> >
> > Were you successful with using it from the deliverable of mvn initialize
> > -Prelease?
> >
> > Please refer for example to aws module dependencies section:
> >
> >
> > com.amazonaws
> > aws-java-sdk-core
> > ${aws.sdk.version}
> >
> >
> >
> > com.amazonaws
> > aws-java-sdk-s3
> > ${aws.sdk.version}
> >
> >
> >
> > com.amazonaws
> > aws-java-sdk-ec2
> > ${aws.sdk.version}
> >
> >
> >
> > com.amazonaws
> > aws-java-sdk-elasticloadbalancing
> > ${aws.sdk.version}
> >
> >
> >
> > com.amazonaws
> > aws-java-sdk-elasticloadbalancingv2
> > ${aws.sdk.version}
> >
> >
> >
> > com.amazonaws
> > aws-java-sdk-kms
> > ${aws.sdk.version}
> >
> >
> >
> >
> > com.fasterxml.jackson.core
> > jackson-core
> > ${jackson.version}
> >
> >
> >
> >
> > com.fasterxml.jackson.core
> > jackson-annotations
> > ${jackson.version}
> >
> >
> >
> >
> > com.fasterxml.jackson.core
> > jackson-databind
> > ${jackson.version}
> >
> >
> >
> > com.amazonaws
> > aws-encryption-sdk-java
> > ${aws.encryption.sdk.version}
> >
> >
> > org.bouncycastle
> > bcprov-ext-jdk15on
> >
> >
> >
> >
> >
> > org.bouncycastle
> > bcprov-ext-jdk15on
> > ${bouncycastle.version}
> >
> >
> >
> > joda-time
> > joda-time
> > 2.8.1
> >
> >
> >
> > org.apache.httpcomponents
> > httpclient
> > ${httpclient.version}
> >
> >
> >
> > org.apache.httpcomponents
> > httpcore
> > ${httpcore.version}
> >
> >
> > azure module should likewise list all of its actual dependencies. Right
> now
> > the module directory is empty so I'm not even going to test to run it in
> > stand-alone mode:
> > ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin% ls
> libs/optional/ignite-azure
> > azure-storage-blob-12.0.0.jar ignite-azure-2.11.0-SNAPSHOT.jar
> README.txt
> >
> > Please address this issue along with other things which I have also
> > commented on the PR.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 31 мар. 2021 г. в 08:17, Atri Sharma :
> >
> > > Thank you for the review.
> > >
> > > I have updated the PR. Please see.
> > >
> > > On Mon, Mar 29, 2021 at 8:27 PM Ilya Kasnacheev
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > I have left some more comments after trying this change on a real
> Azure
> > > > cluster.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > вт, 23 мар. 2021 г. в 18:32, Atri Sharma :
> > > >
> > > > > Thank you!
> > > > >
> > > > > I have updated the PR. Please see and let me know.
> > > > >
> > > > > On Tue, Mar 23, 2021 at 4:27 PM Ilya Kasnacheev
> > > > > wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I am going to check this change out when I have time, using my
> Azure
> > > > > > account.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > вт, 23 мар. 2021 г. в 07:20, Atri Sharma :
> > > > > >
> > > > > > > Gentle reminder on this -- please help in reviewing this.
> > > > > > >
> > > > > > > On Fri, Mar 19, 2021 at 10:23 AM Atri Sharma
> > > wrote:
> > > > > > > >
> > > > > > > > Thanks Denis.
> > > > > > > >
> > > > > > > > I have raised a PR for the same:
> > > > > > > >
> > > > > > > > https://github.com/apache/ignite/pull/8897
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Atri
> > > > > > > >
> > > > > > > > On Wed, Mar 10, 2021 at 1:21 AM Denis Magda <
> dma...@apache.org>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Atri,
> > > > > > > > >
> > > > > > > > > Let's discuss the subj together with the community. Ignite
> > > already
> > > > > > > supports
> > > > > > > > > AWS [1] and GCE [2] IP Finders out of the box, but the
> Azure
> > > one is
> > > > > > > still
> > > > > > > > > missing. I can confirm that the demand exists, and rather
> > > > > frequently,
> > > > > > > I see
> > > > > > > > > developers asking for an Azure-native IP finder for Ignite.
> > > > > > > > >
> > > > > > > > >
[DISCUSSION] Java thin client: Continuous Queries public API
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
