Re: Any reason to keep ClientConfiguration final?

[Michael Pollind]

micronaut setups the configuration at compile time. so a lot of the
configuration is through annotating classes. There are two main methods for
this ConfigurationProperties/ConfigurationBuilder. ConfigurationBuilder
maps properties to a factor and ConfigurationProperties maps properties
onto a class object. It's the difference between wrapping a class and
extending it. You can see the differences by looking at these two items
listed below and the sample code that creates the thin client. It's more
useful just to inject the configuration vs having to unwrap the bean.
Hopefully this helps clarify things. The code is just a bit more clumsy
using a wrapping class this way, but it's not too bad from my perspective.


Thin Client:
https://github.com/micronaut-projects/micronaut-ignite/blob/7c767288f540f5ae6dd0479252db9a1c5072d120/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteThinClientConfiguration.java
Thick Client:
https://github.com/micronaut-projects/micronaut-ignite/blob/7c767288f540f5ae6dd0479252db9a1c5072d120/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java

...

/**
 * Ignite {@link ClientConfiguration}.
 * @param clientConfiguration client configuration
 * @return client configuration
 */
@Bean
@Named("default")
@Primary
@Requires(beans = DefaultIgniteThinClientConfiguration.class)
public ClientConfiguration igniteClientConfiguration(@IgnitePrimary
DefaultIgniteThinClientConfiguration clientConfiguration) {
return clientConfiguration.getConfiguration();
}

/**
 *
 * @param configuration client configuration
 * @return Ignite Thin client
 */
@EachBean(ClientConfiguration.class)
@Singleton
@Bean(preDestroy = "close")
public IgniteClient igniteThinClient(ClientConfiguration configuration) {
try {
return Ignition.startClient(configuration);
} catch (Exception e) {
LOG.error("Failed to instantiate Ignite Client: " + e.getMessage(), e);
throw e;
}
}
...


--
Michael Pollind

On Mon, Aug 24, 2020 at 1:43 PM Igor Sapego  wrote:

> No objections from my side.
>
> What is the case? Some kind of new thin client?
>
> Best Regards,
> Igor
>
>
> On Mon, Aug 24, 2020 at 11:40 PM Pavel Tupitsyn 
> wrote:
>
>> Denis,
>>
>> No objections to the removal of the "final" modifier from my side.
>> However, the use case sounds a bit weird to me, can you please describe
>> it in more detail?
>>
>> Thanks,
>> Pavel
>>
>> On Mon, Aug 24, 2020 at 10:47 PM Denis Magda  wrote:
>>
>>> @Pavel Tupitsyn , @Igor Sapego
>>> ,
>>>
>>> Michael has been integrating Ignite with Micronaut and we hit some
>>> limitations related to the configuration. To simplify the configuration of
>>> the thin client instances, we need to inherit from the ClientConfiguration
>>> class
>>> 
>>>  but
>>> the class is made final.
>>>
>>> Is any good reason for keeping its final? Otherwise, I'll go ahead and
>>> remove that modifier.
>>>
>>>
>>> -
>>> Denis
>>>
>>

Re: Micronaut/Ignite

[Michael Pollind]

yea, I'm not sure about ignite-cache config. splitting it into two modules
seems kind of overly complicated, but I also don't really like the random
boolean flag. here is the tweaks from the config your provider:
https://github.com/pollend/micronaut-ignite/pull/2

kind of strange that there are not getters for the
TcpDiscoveryKubernetesIpFinder but there is enough to verify that the
correct ipfinder was set from the unit test i've written.

static ip finder

"ignite.enabled": true,
"ignite.communication-spi.local-port"   : "localhost:1800",
"ignite.discovery-spi.static-ip-finder.enabled" : "true",
"ignite.discovery-spi.static-ip-finder.addresses[0]": "127.0.0.1:47500",
"ignite.discovery-spi.static-ip-finder.addresses[1]": "127.0.0.1:47501",

kubernetties ip finder

"ignite.enabled" : true,
"ignite.communication-spi.local-port": "localhost:1800",
"ignite.discovery-spi.kubernetes-ip-finder.enabled"  : "true",
"ignite.discovery-spi.kubernetes-ip-finder.namespace": "HelloWorld"





On Mon, Aug 24, 2020 at 6:16 PM Denis Magda  wrote:

> Michael,
>
> I was thinking over the idea of splitting the ignite-cache module in two
> (one for a thick-client based connection and the other for thin client
> connections), and would try to avoid this route if possible.
>
> With the @CacheConfig annotation, Micronaut developers can create a generic
> implementation that is agnostic to the Ignite connectivity methods, which
> is good. While internally, the ignite-cache implementation can decide what
> Ignite Cache API to use (the thick or thin client one, depends on the type
> of a client you started with our auto-configuration feature). Let’s discuss
> all the existing issues here and jump on another call to finalize a
> solution if needed.
>
> Denis
>
> On Monday, August 24, 2020, Denis Magda  wrote:
>
> > Michael,
> >
> > Great progress, thanks for your patience. I went ahead and pushed some
> > changes to your working branch. As you'll see, those changes do some
> minor
> > tweaks in the DefaultIgniteThinClientConfiguration class and add Static
> > with Kubernetes IP finders to the DefaultIgniteConfiguration class. The
> > IgniteConfigurationSpec fails for now, but I think we'll figure how to
> > modify the test on the call today.
> >
> > Also, let's decide if we want to configure IgniteCaches via the Micronaut
> > configuration. If an application needs to create any caches, it can do
> this
> > dynamically after an Ignite instance is started.
> >
> > -
> > Denis
> >
> >
> > On Sat, Aug 22, 2020 at 1:15 PM Michael Pollind 
> > wrote:
> >
> > The way i've gone about providing dependencies is that these can be
> > provided through a factory.
> >
> > @Bean
> > @Named("default")
> > @Primary
> > public IgniteConfiguration
> igniteConfiguration(DefaultIgniteConfiguration configuration,
> >
> Collection cacheConfigurations,
> >
> Collection providers,
> >
> Collection executorConfigurations,
> >
> Optional platformConfigurations,
> >Optional
> collisionSpi,
> >
> Collection loadBalancingSpis,
> >Collection
> failoverSpis,
> >@ConsistencyId
> Optional consistencyId,
> >@IgniteLifecycle
> Collection lifecycleBeans) {
> > configuration.setCacheConfiguration(cacheConfigurations.toArray(new
> CacheConfiguration[0]))
> > .setPluginProviders(providers.toArray(new PluginProvider[0]))
> > .setExecutorConfiguration(executorConfigurations.toArray(new
> ExecutorConfiguration[0]))
> > .setPlatformConfiguration(platformConfigurations.orElse(null))
> > .setFailoverSpi(failoverSpis.toArray(new FailoverSpi[0]))
> > .setLoadBalancingSpi(loadBalancingSpis.toArray(new
> LoadBalancingSpi[0]))
> > .setConsistentId(consistencyId.orElse(null))
> > .setLifecycleBeans(lifecycleBeans.toArray(new LifecycleBean[0]))
> > .setCollisionSpi(collisionSpi.orElse(null));
> > return configuration;
> > }
> >
> >
> > On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind 
> > wrote:
> >
> > here is an updated example what the yaml looks like now.
> >
> > ignite:
> > enabled: true
> > comunication-spi:
> > local-port: 
> > cache-configurations:
> > - accounts:
> > table-name: ACCOUNTS
> > key-type: String
> > - books:
> > table-name: BOOKS
> > key-type: String
> >
> > On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind 
> > wrote:
> >
> > micronaut will only inject into a nested object if its static and nested
> > in a class. Its a separate final class so it will not work in this case.
> So
> > DataRegionConfiguration will not get set from the environment. This is a
> > working example but this can be adjusted.  I guess it would have to be
> > setup like

Re: Micronaut/Ignite

[Denis Magda]

Michael,

I was thinking over the idea of splitting the ignite-cache module in two
(one for a thick-client based connection and the other for thin client
connections), and would try to avoid this route if possible.

With the @CacheConfig annotation, Micronaut developers can create a generic
implementation that is agnostic to the Ignite connectivity methods, which
is good. While internally, the ignite-cache implementation can decide what
Ignite Cache API to use (the thick or thin client one, depends on the type
of a client you started with our auto-configuration feature). Let’s discuss
all the existing issues here and jump on another call to finalize a
solution if needed.

Denis

On Monday, August 24, 2020, Denis Magda  wrote:

> Michael,
>
> Great progress, thanks for your patience. I went ahead and pushed some
> changes to your working branch. As you'll see, those changes do some minor
> tweaks in the DefaultIgniteThinClientConfiguration class and add Static
> with Kubernetes IP finders to the DefaultIgniteConfiguration class. The
> IgniteConfigurationSpec fails for now, but I think we'll figure how to
> modify the test on the call today.
>
> Also, let's decide if we want to configure IgniteCaches via the Micronaut
> configuration. If an application needs to create any caches, it can do this
> dynamically after an Ignite instance is started.
>
> -
> Denis
>
>
> On Sat, Aug 22, 2020 at 1:15 PM Michael Pollind 
> wrote:
>
> The way i've gone about providing dependencies is that these can be
> provided through a factory.
>
> @Bean
> @Named("default")
> @Primary
> public IgniteConfiguration igniteConfiguration(DefaultIgniteConfiguration 
> configuration,
>
> Collection cacheConfigurations,
>Collection 
> providers,
>
> Collection executorConfigurations,
>
> Optional platformConfigurations,
>Optional 
> collisionSpi,
>Collection 
> loadBalancingSpis,
>Collection 
> failoverSpis,
>@ConsistencyId 
> Optional consistencyId,
>@IgniteLifecycle 
> Collection lifecycleBeans) {
> configuration.setCacheConfiguration(cacheConfigurations.toArray(new 
> CacheConfiguration[0]))
> .setPluginProviders(providers.toArray(new PluginProvider[0]))
> .setExecutorConfiguration(executorConfigurations.toArray(new 
> ExecutorConfiguration[0]))
> .setPlatformConfiguration(platformConfigurations.orElse(null))
> .setFailoverSpi(failoverSpis.toArray(new FailoverSpi[0]))
> .setLoadBalancingSpi(loadBalancingSpis.toArray(new 
> LoadBalancingSpi[0]))
> .setConsistentId(consistencyId.orElse(null))
> .setLifecycleBeans(lifecycleBeans.toArray(new LifecycleBean[0]))
> .setCollisionSpi(collisionSpi.orElse(null));
> return configuration;
> }
>
>
> On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind 
> wrote:
>
> here is an updated example what the yaml looks like now.
>
> ignite:
> enabled: true
> comunication-spi:
> local-port: 
> cache-configurations:
> - accounts:
> table-name: ACCOUNTS
> key-type: String
> - books:
> table-name: BOOKS
> key-type: String
>
> On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind 
> wrote:
>
> micronaut will only inject into a nested object if its static and nested
> in a class. Its a separate final class so it will not work in this case. So
> DataRegionConfiguration will not get set from the environment. This is a
> working example but this can be adjusted.  I guess it would have to be
> setup like DefaultIgniteConfiguration. DefaultDataStorageConfiguration
> and a nested EachProperty? Lets try have a minimum working setup and then
> add in the missing configurations as we go?
>
> @ConfigurationBuilder(value = "dataStorageConfiguration", excludes = 
> "dataRegionConfigurations")
> final DataStorageConfiguration dataStorageConfiguration = new 
> DataStorageConfiguration();
>
> @EachProperty("dataRegionConfigurations")
> public static class DefaultDataRegionConfiguration {
> @ConfigurationBuilder()
> DataRegionConfiguration dataRegionConfiguration = new 
> DataRegionConfiguration();
>
> public DataRegionConfiguration getDataRegionConfiguration() {
> return dataRegionConfiguration;
> }
> }
>
>
>
>
> On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind 
> wrote:
>
> Dennis,
>
> oh, so I made those adjustments. I must have missed it because that didn't
> occur to me. So DefaultIgniteConfiguration is fine, but ClientConfiguration
> is a final class so that can't be extended from. This PR is starting to
> shape up from my perspective, I just need to upd

Re: IEP-51: Java Thin Client Async API

[Igor Sapego]

Alexey, what do you think? Which Future should be used here?

Now, about the "not fully sync" interface - I believe this is acceptable as
a first
approach.

Best Regards,
Igor


On Mon, Aug 24, 2020 at 12:37 PM Pavel Tupitsyn 
wrote:

> I've changed the IEP and added a new future interface to the POC:
> interface IgniteClientFuture extends Future, CompletionStage
>
> The implementation simply wraps the CompletableFuture.
>
> On Fri, Aug 21, 2020 at 11:22 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Pavel,
> >
> > Interesting findings :) Agree that we should not use the
> CompletableFuture
> > - it clearly has a different purpose.
> >
> > I think that the approach taken by Redis makes more sense. I don't like
> > that it requires a custom interface, but I think we can live with that.
> >
> > I would be glad to hear other opinions though.
> >
> > -Val
> >
> > On Fri, Aug 21, 2020 at 1:02 AM Pavel Tupitsyn 
> > wrote:
> >
> > > Val,
> > >
> > > The problems with CompletableFuture in public API are:
> > > * It is a class, not an interface
> > > * It is completable - anyone can call .complete(), which is not what we
> > > want
> > >
> > > There seems to be no clear guidance in Java world on async API design;
> > > however, it is often recommended to return CompletionStage instead of
> > > CompletableFuture
> > > from the public APIs [1] [2], and some products follow this [3].
> > >
> > > Other products return their own future interface that extends both
> Future
> > > and CompletionStage,
> > > which seems to be a better alternative to me [4].
> > >
> > > Thoughts?
> > >
> > > [1]
> > >
> > >
> >
> https://stackoverflow.com/questions/47571117/what-is-the-difference-between-completionstage-and-completablefuture
> > > [2]
> > >
> > >
> >
> https://stackoverflow.com/questions/34930840/should-i-return-completablefuture-or-future-when-defining-api
> > > <
> > >
> >
> https://stackoverflow.com/questions/34930840/should-i-return-completablefuture-or-future-when-defining-api#:~:text=by%20returning%20a%20CompletableFuture%2C%20you,API%2C%20which%20is%20not%20good
> > > .>
> > > [3]
> > >
> > >
> >
> https://docs.hazelcast.org/docs/latest/javadoc/com/hazelcast/cache/ICache.html
> > > [4]
> > >
> > >
> >
> https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html
> > >
> > > On Fri, Aug 21, 2020 at 10:28 AM Alex Plehanov <
> plehanov.a...@gmail.com>
> > > wrote:
> > >
> > > > Pavel,
> > > >
> > > > Thanks for the discussion, I've also faced with the necessity of
> having
> > > > async calls while implementing POC for thin client data streamer [1]
> > and
> > > > solve it similarly (but in my case it's required only for internal
> > > > implementation, so I've only changed the internal API).
> > > >
> > > > I want to note that described in IEP approach (and implemented in
> POC)
> > is
> > > > not fully async, since "send" is still used in the user's thread. To
> > make
> > > > it fully async we need additional sending thread (since blocking IO
> is
> > > used
> > > > for communication with the server). If partition awareness is enabled
> > > there
> > > > will be 2 threads per each server connection, perhaps we should think
> > > about
> > > > moving to NIO and introducing some kind of communication thread pool.
> > > >
> > > > [1]: https://github.com/apache/ignite/pull/8175
> > > >
> > > > пт, 21 авг. 2020 г. в 03:35, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com>:
> > > >
> > > > > Sounds good. I've added this to the 3.0 roadmap:
> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
> > > > >
> > > > > Unless there are any objections from others, let's stick with the
> > > > > CompletableFuture for any future development, including the thin
> > > client.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Aug 20, 2020 at 9:30 AM Pavel Tupitsyn <
> ptupit...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Val, no objections from my side.
> > > > > > As noted above, the only benefit of IgniteFuture is consistency
> > > across
> > > > > > thin/thick APIs,
> > > > > > which is probably not so important.
> > > > > >
> > > > > > On Thu, Aug 20, 2020 at 6:28 PM Valentin Kulichenko <
> > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > >
> > > > > > > Hi Pavel,
> > > > > > >
> > > > > > > Are there any benefits of IgniteFuture over CompletableFuture?
> > > > > > >
> > > > > > > IgniteFuture was created long ago, during the time when
> > > > > CompletableFuture
> > > > > > > did not exist. There is a big chance that IgniteFuture actually
> > > > became
> > > > > > > redundant at the moment we transitioned to Java8. If that's the
> > > > case, I
> > > > > > > would prefer using CompletableFuture in the thin client and
> > getting
> > > > rid
> > > > > > of
> > > > > > > IgniteFuture altogether in 3.0.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Thu, Aug 20, 

Re: First contribute to Ignite ML

[Denis Magda]

Hi Mark,

Welcome to the community! Hope you'll find it delightful to contribute to
the Ignite ML component.

I've added you to JIRA's contributors' list, so you're good to go. Just in
case, @Alexey Zinoviev   is our main ML maintainer,
but, probably, you already know him.

-
Denis


On Mon, Aug 24, 2020 at 3:42 PM Mark Andreev  wrote:

> Hello, I want to join the Ignite community as a developer. My field of
> interests is Machine learning, so I can start with extending
> DistanceMeasure implementations (migrate from scipy).
>
> Please, could you give me a contribution permission (username: mrkandreev)?
>
> --
> Best regards,
> Mark Andreev
>

First contribute to Ignite ML

[Mark Andreev]

Hello, I want to join the Ignite community as a developer. My field of
interests is Machine learning, so I can start with extending
DistanceMeasure implementations (migrate from scipy).

Please, could you give me a contribution permission (username: mrkandreev)?

-- 
Best regards,
Mark Andreev

Re: Micronaut/Ignite

[Denis Magda]

Michael,

Great progress, thanks for your patience. I went ahead and pushed some
changes to your working branch. As you'll see, those changes do some minor
tweaks in the DefaultIgniteThinClientConfiguration class and add Static
with Kubernetes IP finders to the DefaultIgniteConfiguration class. The
IgniteConfigurationSpec fails for now, but I think we'll figure how to
modify the test on the call today.

Also, let's decide if we want to configure IgniteCaches via the Micronaut
configuration. If an application needs to create any caches, it can do this
dynamically after an Ignite instance is started.

-
Denis


On Sat, Aug 22, 2020 at 1:15 PM Michael Pollind  wrote:

> The way i've gone about providing dependencies is that these can be
> provided through a factory.
>
> @Bean
> @Named("default")
> @Primary
> public IgniteConfiguration igniteConfiguration(DefaultIgniteConfiguration 
> configuration,
>
> Collection cacheConfigurations,
>Collection 
> providers,
>
> Collection executorConfigurations,
>
> Optional platformConfigurations,
>Optional 
> collisionSpi,
>Collection 
> loadBalancingSpis,
>Collection 
> failoverSpis,
>@ConsistencyId 
> Optional consistencyId,
>@IgniteLifecycle 
> Collection lifecycleBeans) {
> configuration.setCacheConfiguration(cacheConfigurations.toArray(new 
> CacheConfiguration[0]))
> .setPluginProviders(providers.toArray(new PluginProvider[0]))
> .setExecutorConfiguration(executorConfigurations.toArray(new 
> ExecutorConfiguration[0]))
> .setPlatformConfiguration(platformConfigurations.orElse(null))
> .setFailoverSpi(failoverSpis.toArray(new FailoverSpi[0]))
> .setLoadBalancingSpi(loadBalancingSpis.toArray(new 
> LoadBalancingSpi[0]))
> .setConsistentId(consistencyId.orElse(null))
> .setLifecycleBeans(lifecycleBeans.toArray(new LifecycleBean[0]))
> .setCollisionSpi(collisionSpi.orElse(null));
> return configuration;
> }
>
>
> On Sat, Aug 22, 2020 at 8:37 AM Michael Pollind 
> wrote:
>
>> here is an updated example what the yaml looks like now.
>>
>> ignite:
>> enabled: true
>> comunication-spi:
>> local-port: 
>> cache-configurations:
>> - accounts:
>> table-name: ACCOUNTS
>> key-type: String
>> - books:
>> table-name: BOOKS
>> key-type: String
>>
>> On Fri, Aug 21, 2020 at 10:28 PM Michael Pollind 
>> wrote:
>>
>>> micronaut will only inject into a nested object if its static and nested
>>> in a class. Its a separate final class so it will not work in this case. So
>>> DataRegionConfiguration will not get set from the environment. This is a
>>> working example but this can be adjusted.  I guess it would have to be
>>> setup like DefaultIgniteConfiguration. DefaultDataStorageConfiguration and
>>> a nested EachProperty? Lets try have a minimum working setup and then add
>>> in the missing configurations as we go?
>>>
>>> @ConfigurationBuilder(value = "dataStorageConfiguration", excludes = 
>>> "dataRegionConfigurations")
>>> final DataStorageConfiguration dataStorageConfiguration = new 
>>> DataStorageConfiguration();
>>>
>>> @EachProperty("dataRegionConfigurations")
>>> public static class DefaultDataRegionConfiguration {
>>> @ConfigurationBuilder()
>>> DataRegionConfiguration dataRegionConfiguration = new 
>>> DataRegionConfiguration();
>>>
>>> public DataRegionConfiguration getDataRegionConfiguration() {
>>> return dataRegionConfiguration;
>>> }
>>> }
>>>
>>>
>>>
>>>
>>> On Fri, Aug 21, 2020 at 7:08 PM Michael Pollind 
>>> wrote:
>>>
 Dennis,

 oh, so I made those adjustments. I must have missed it because that
 didn't occur to me. So DefaultIgniteConfiguration is fine, but
 ClientConfiguration is a final class so that can't be extended from. This
 PR is starting to shape up from my perspective, I just need to update the
 documentation. The other thing I did was add a flag for the associated
 cache to use micronuat-cache. umm, I'll play with this a bit and see If I
 can work out something better. ignite.enabled can be false but you can
 provide your own bean in place but that doesn't seem quite right.

 [image: image.png]


 https://github.com/micronaut-projects/micronaut-ignite/pull/33

 On Fri, Aug 21, 2020 at 6:29 PM Denis Magda  wrote:

> Michael,
>
> Thanks, for verifying.
>
> I've tried extending ClientConfiguration but couldn't get the
> > getters/setters working with ConfigurationBuilder. Instead t

Re: [DISCUSSION] Consistency across java thin/thick APIs

[Igor Sapego]

Yes, it was an attempt to separate thick and thin clients as much as
possible
to move them in separate libs in future.

Alex, what do you think? What is the right path here from the Java
developer viewpoint?

Best Regards,
Igor


On Mon, Aug 24, 2020 at 9:40 AM Alex Plehanov 
wrote:

> Hi Val,
>
> No, I don't know why ClientException was introduced. Perhaps it was an
> attempt to strictly separate thin and thick implementations. But there
> still some API and thick implementation reused in thin client
> (BinaryObjects, Queries).
>
> пт, 21 авг. 2020 г. в 23:28, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Hi Alex,
> >
> > Do you know if there is any particular reason why we introduced
> > the ClientException in the first place? Generally, I believe that
> > consistency is a good thing, but there might be something that we're
> > missing.
> >
> > -Val
> >
> > On Fri, Aug 21, 2020 at 2:33 AM Alex Plehanov 
> > wrote:
> >
> > > Hello, Igniters!
> > >
> > > Since we touched on the subject of consistency across thin/thick APIs
> in
> > > thread [1] I would like to continue the discussion here.
> > >
> > > Currently, thick and thin APIs look similar but have no common
> parents. A
> > > set of ClientCache methods is almost a subset of IgniteCache methods,
> but
> > > these interfaces are fully independent. So we can't build common
> > > abstraction which can work with ClientCache and IgniteCache without
> code
> > > duplication. For example, we have ignite-spring-data module, to make it
> > > thin-client compliant we should copy-paste all cache methods
> invocations.
> > >
> > > It's impossible to make thin and thick interfaces absolutely identical
> > and
> > > we can't extend one from another since there thick and thin specific
> > > methods needed, but we can move common methods to the parent interface.
> > But
> > > here is another problem: exceptions. Thick methods declared as throwing
> > > IgniteException and IgniteCheckedException, but all thin-client
> > interfaces
> > > use ClientException. Without common exceptions for thin and thick
> > clients,
> > > we can't build common parent interface.
> > >
> > > Currently, only a small amount of thick interfaces can be fully reused
> by
> > > thin-client (Queries, IgniteBinary, ClusterNode)
> > >
> > > Also, I would like to discuss JCache support by thin-client. We already
> > use
> > > some of JCache specification for thin-client, but not fully support
> > JCache.
> > > For example, we use Cache.Entry for queries and JCache expiration
> > policies
> > > in public thin-client API (also, some of JCache interfaces are used by
> > the
> > > internal implementation).
> > >
> > > I've tried to implement POC for continuous queries for java thin
> client,
> > > but without JCache support 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 have plans to change public API in Ignite 3.0, perhaps it makes
> sense
> > to
> > > make thick and thin API consistent. WDYT?
> > > What about JCache support by thin-client in Ignite 3.0?
> > > Please, share your thoughts.
> > >
> > > [1]:
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-51-Java-Thin-Client-Async-API-td48900.html
> > >
> >
>

Re: Cpp thin client transactions support ready for review.

[Igor Sapego]

Great, I'll take a look.

Best Regards,
Igor


On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky
 wrote:

>
>
> Thanks Ivan Daschinsky for review, does anyone more who could check it ?
>
> thanks !
> >Igniters, seems i complete with transactions in thin cpp client
> >implementation [1], part of iep-34 [2].
> >Can anyone review my decision ?
> >Failed test seems not mine, looks like after fresh master rebase it will
> >gone.
> >
> >[1]  https://issues.apache.org/jira/browse/IGNITE-13308
> >[2]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> >
> >
>
>
>
>

Re: Ignite thin client in Rust

[Igor Sapego]

Hi, Val,

I've been working on my implementation for some time, but
didn't commit to it lately so it's pretty much abandoned. Maybe we should
join our forces here :)

Best Regards,
Igor


On Thu, Jul 2, 2020 at 1:00 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Pavel,
>
> Yes, I definitely plan to continue working on this going forward. No
> deadlines though :)
>
> -Val
>
> On Wed, Jul 1, 2020 at 1:09 AM Pavel Tupitsyn 
> wrote:
>
> > Hi Val,
> >
> > This is great!
> > I'm a Rust enthusiast too, the language is awesome.
> > Is it time to rewrite Ignite in Rust? :)
> >
> > In all seriousness, do you have plans to continue working
> > on this thin client and make it production-ready?
> >
> > On Wed, Jul 1, 2020 at 8:01 AM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > I've been learning the Rust language lately and though that creating a
> > thin
> > > client in Rust would be a great exercise.
> > >
> > > I went ahead and create a prototype which currently supports only put
> and
> > > get operations with primitives and strings:
> > > https://github.com/vkulichenko/ignite-rust-client
> > >
> > > Feedback and participation are welcome!
> > >
> > > Do we have any Rust enthusiasts in our community?
> > >
> > > -Val
> > >
> >
>

Re: Any reason to keep ClientConfiguration final?

[Igor Sapego]

No objections from my side.

What is the case? Some kind of new thin client?

Best Regards,
Igor


On Mon, Aug 24, 2020 at 11:40 PM Pavel Tupitsyn 
wrote:

> Denis,
>
> No objections to the removal of the "final" modifier from my side.
> However, the use case sounds a bit weird to me, can you please describe it
> in more detail?
>
> Thanks,
> Pavel
>
> On Mon, Aug 24, 2020 at 10:47 PM Denis Magda  wrote:
>
>> @Pavel Tupitsyn , @Igor Sapego 
>> ,
>>
>> Michael has been integrating Ignite with Micronaut and we hit some
>> limitations related to the configuration. To simplify the configuration of
>> the thin client instances, we need to inherit from the ClientConfiguration
>> class
>> 
>>  but
>> the class is made final.
>>
>> Is any good reason for keeping its final? Otherwise, I'll go ahead and
>> remove that modifier.
>>
>>
>> -
>> Denis
>>
>

Re: Any reason to keep ClientConfiguration final?

[Pavel Tupitsyn]

Denis,

No objections to the removal of the "final" modifier from my side.
However, the use case sounds a bit weird to me, can you please describe it
in more detail?

Thanks,
Pavel

On Mon, Aug 24, 2020 at 10:47 PM Denis Magda  wrote:

> @Pavel Tupitsyn , @Igor Sapego ,
>
> Michael has been integrating Ignite with Micronaut and we hit some
> limitations related to the configuration. To simplify the configuration of
> the thin client instances, we need to inherit from the ClientConfiguration
> class
> 
>  but
> the class is made final.
>
> Is any good reason for keeping its final? Otherwise, I'll go ahead and
> remove that modifier.
>
>
> -
> Denis
>

Any reason to keep ClientConfiguration final?

[Denis Magda]

@Pavel Tupitsyn , @Igor Sapego ,

Michael has been integrating Ignite with Micronaut and we hit some
limitations related to the configuration. To simplify the configuration of
the thin client instances, we need to inherit from the ClientConfiguration
class

but
the class is made final.

Is any good reason for keeping its final? Otherwise, I'll go ahead and
remove that modifier.


-
Denis

[jira] [Created] (IGNITE-13382) DurableBackgroundTask can abandon incomplete task

[Maria Makedonskaya (Jira)]

Maria Makedonskaya created IGNITE-13382:
---

 Summary: DurableBackgroundTask can abandon incomplete task
 Key: IGNITE-13382
 URL: https://issues.apache.org/jira/browse/IGNITE-13382
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Maria Makedonskaya
Assignee: Maria Makedonskaya


DurableBackgroundTasks are tracked using metastorage, there's a specific marker 
for every task, and it is removed right after the task is complete.

But there's a race between checkpointer and metastorage. End-marker removal is 
a logical operation, while task itself is mostly physical (at least the 
existing one). So, following scenario is possible:
* Checkpoint occurs in the middle of the task;
* Task is completed before the next checkpoint;
* Metastorage record is deleted, this fact if written to WAL and synced to the 
storage;
* Node failed;
* Recovery process applies deletion from metastorage, this means that 
DurableBackgroundTasks info is lost;
* But part of the index is still present in the storage.

I think that we should remove markers from metastorage only after the next 
checkpoint, this will 100% save us from such situation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Editing rights

[Denis Magda]

Evgeniy,

You're in. Go ahead and do the necessary edits on the page.

-
Denis


On Mon, Aug 24, 2020 at 3:36 AM lonsdalel lonsdalel <
eugenezabot...@gmail.com> wrote:

> Hi,
> my cwiki account is evzabotkin, e-mail evzabot...@sberbank.ru.
>
> On 2020/08/19 18:20:41, Denis Magda  wrote:
> > Yes, I confused JIRA with wiki in the last response. Ivan, thanks for
> > catching that.
> >
> > -
> > Denis
> >
> >
> > On Wed, Aug 19, 2020 at 11:08 AM Ivan Pavlukhin 
> wrote:
> >
> > > > We'd like to edit an article on cwiki. How can I get the editing
> rights
> > > as a technical writer?
> > >
> > > I suppose we are talking about cwiki, not JIRA. Have you registered
> there?
> > > https://cwiki.apache.org/confluence/signup.action
> > >
> > > 19.08.2020, Denis Magda написал(а):
> > > > Evgeniy,
> > > >
> > > > Please tell your JIRA id/account_name. For some reason, I can't
> locate
> > > your
> > > > account with the email.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Wed, Aug 19, 2020 at 7:29 AM lonsdalel lonsdalel <
> > > > eugenezabot...@gmail.com> wrote:
> > > >
> > > >> Hi Denis,
> > > >>
> > > >> my JIRA account is evzabot...@sberbank.ru.
> > > >>
> > > >> BR,
> > > >> Evgeniy
> > > >>
> > > >> On 2020/08/17 18:31:33, Denis Magda  wrote:
> > > >> > Hi Evgeniy,
> > > >> >
> > > >> > Please tell the email address of your JIRA account and we'll
> grant you
> > > >> all
> > > >> > necessary permissions.
> > > >> >
> > > >> > -
> > > >> > Denis
> > > >> >
> > > >> >
> > > >> > On Mon, Aug 17, 2020 at 9:28 AM Заботкин Евгений Владимирович
> > > >> >  wrote:
> > > >> >
> > > >> > > Hello,
> > > >> > >
> > > >> > > We'd like to edit an article on cwiki. How can I get the editing
> > > >> rights as
> > > >> > > a technical writer?
> > > >> > >
> > > >> > > Best regards,
> > > >> > > Evgeniy Zabotkin
> > > >> > >
> > > >> > > С уважением,
> > > >> > > Евгений Заботкин<
> > > >> > > http://addressbook.ca.sbrf.ru/home/Index?type=0&search=1818683>
> > > >> > > ИТ-инженер (Технический писатель)
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Даем людям уверенность и надежность!
> > > >> > >
> > > >> > > УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: Это электронное сообщение и
> любые
> > > >> > > документы, приложенные к нему, содержат конфиденциальную
> информацию.
> > > >> > > Настоящим уведомляем Вас о том, что если это сообщение не
> > > >> > > предназначено
> > > >> > > Вам, использование, копирование, распространение информации,
> > > >> содержащейся в
> > > >> > > настоящем сообщении, а также осуществление любых действий на
> основе
> > > >> этой
> > > >> > > информации, строго запрещено. Если Вы получили это сообщение по
> > > >> > > ошибке,
> > > >> > > пожалуйста, сообщите об этом отправителю по электронной почте и
> > > >> удалите это
> > > >> > > сообщение. CONFIDENTIALITY NOTICE: This email and any files
> attached
> > > >> to it
> > > >> > > are confidential. If you are not the intended recipient you are
> > > >> notified
> > > >> > > that using, copying, distributing or taking any action in
> reliance
> > > on
> > > >> the
> > > >> > > contents of this information is strictly prohibited. If you have
> > > >> received
> > > >> > > this email in error please notify the sender and delete this
> email.
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
>

Re: Stuck in solving class not found exception

[Belal Ahmed Khan]

Hi Team,

Awaiting your reply, can you please have a look.

Thanks,
Belal khan

On Wednesday, August 19, 2020, Belal Ahmed Khan 
wrote:

> Hi Team,
>
> I am getting an exception when my client tries to connect to the cluster,
> i have copied my application jar in the libs folder of the cluster still
> did not get why this issue is coming, please help me !
> I have written my application code in the spring boot gradle project which
> will act as a client. I can't share the project as it has some privacy of
> company
> Thanks in advance !
>
>
> centralizedAff=false, forceAffReassignment=false, exchangeLocE=null,
> cacheChangeFailureMsgSent=false, done=true, state=CRD,
> registerCachesFuture=null, partitionsSent=false, partitionsReceived=false,
> delayedLatestMsg=null, afterLsnrCompleteFut=GridFutureAdapter
> [ignoreInterrupts=false, state=DONE, res=null, hash=154939842],
> timeBag=o.a.i.i.util.TimeBag@1facd339, startTime=83336384510500,
> initTime=1597765529826, rebalanced=false, evtLatch=0, remaining=HashSet [],
> mergedJoinExchMsgs=null, awaitMergedMsgs=0, super=GridFutureAdapter
> [ignoreInterrupts=false, state=DONE, res=class o.a.i.IgniteException:
> Failed to enrich cache configuration [cacheName=positionCache],
> hash=1194223146]]
> class org.apache.ignite.IgniteCheckedException: Failed to enrich cache
> configuration [cacheName=positionCache]
> at org.apache.ignite.internal.util.IgniteUtils.cast(
> IgniteUtils.java:7507)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> resolve(GridFutureAdapter.java:260)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> get0(GridFutureAdapter.java:209)
> at org.apache.ignite.internal.util.future.GridFutureAdapter.
> get(GridFutureAdapter.java:160)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.body0(
> GridCachePartitionExchangeManager.java:3242)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.body(
> GridCachePartitionExchangeManager.java:3063)
> at org.apache.ignite.internal.util.worker.GridWorker.run(
> GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to enrich
> cache configuration [cacheName=positionCache]
> at org.apache.ignite.internal.processors.cache.
> CacheConfigurationEnricher.enrich(CacheConfigurationEnricher.java:129)
> at org.apache.ignite.internal.processors.cache.
> CacheConfigurationEnricher.enrich(CacheConfigurationEnricher.java:62)
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> prepareCacheContext(GridCacheProcessor.java:1958)
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> prepareCacheStart(GridCacheProcessor.java:1926)
> at org.apache.ignite.internal.processors.cache.
> GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(
> GridCacheProcessor.java:1801)
> at org.apache.ignite.internal.processors.cache.
> GridCacheProcessor.lambda$prepareStartCaches$8(
> GridCacheProcessor.java:1754)
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> prepareStartCaches(GridCacheProcessor.java:1798)
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> prepareStartCaches(GridCacheProcessor.java:1753)
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> startReceivedCaches(GridCacheProcessor.java:1734)
> at org.apache.ignite.internal.processors.cache.distributed.
> dht.preloader.GridDhtPartitionsExchangeFuture.init(
> GridDhtPartitionsExchangeFuture.java:840)
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.body0(
> GridCachePartitionExchangeManager.java:3214)
> ... 3 more
> Caused by: class org.apache.ignite.IgniteException: Failed to deserialize
> field storeSesLsnrs
> at org.apache.ignite.internal.processors.cache.
> CacheConfigurationEnricher.deserialize(CacheConfigurationEnricher.
> java:154)
> at org.apache.ignite.internal.processors.cache.
> CacheConfigurationEnricher.enrich(CacheConfigurationEnricher.java:122)
> ... 13 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to find
> class with given class loader for unmarshalling (make sure same versions of
> all classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=com.globant.ignite.config.CutomStoreSessionListener]
> at org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(
> JdkMarshaller.java:129)
> at org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(
> JdkMarshaller.java:139)
> at org.apache.ignite.marshaller.AbstractNodeNameAwareMarshalle
> r.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
> at org.apache.ignite.internal.u

[jira] [Created] (IGNITE-13381) ClusterGroupEmptyException: Cluster group is empty error after client reconnect

[Andrey Aleksandrov (Jira)]

Andrey Aleksandrov created IGNITE-13381:
---

 Summary: ClusterGroupEmptyException: Cluster group is empty error 
after client reconnect
 Key: IGNITE-13381
 URL: https://issues.apache.org/jira/browse/IGNITE-13381
 Project: Ignite
  Issue Type: Bug
  Components: networking
Affects Versions: 2.8.1
Reporter: Andrey Aleksandrov
Assignee: Andrey Aleksandrov
 Fix For: 2.9
 Attachments: SendMessageAfterClientReconnect.java

Please run the attached test.

It will produce the following exception:

Exception in thread "main" class 
org.apache.ignite.cluster.ClusterGroupEmptyException: Cluster group is empty.
at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:927)
at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:925)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1083)
at 
org.apache.ignite.internal.IgniteMessagingImpl.send0(IgniteMessagingImpl.java:105)
at 
org.apache.ignite.internal.IgniteMessagingImpl.send(IgniteMessagingImpl.java:81)
at npe.IgnitePartitioningTest.main(IgnitePartitioningTest.java:110)
Caused by: class 
org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster 
group is empty.
at 
org.apache.ignite.internal.util.IgniteUtils.emptyTopologyException(IgniteUtils.java:5106)
at 
org.apache.ignite.internal.IgniteMessagingImpl.send0(IgniteMessagingImpl.java:100)
... 2 more

Fix:

change

return new ClusterGroupAdapter(ctx, null, 
Collections.singleton(cfg.getNodeId()));

on

return new ClusterGroupAdapter(ctx, null, 
Collections.singleton(ctx.discovery().localNode().id()));



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Editing rights

[lonsdalel lonsdalel]

Hi,
my cwiki account is evzabotkin, e-mail evzabot...@sberbank.ru.

On 2020/08/19 18:20:41, Denis Magda  wrote: 
> Yes, I confused JIRA with wiki in the last response. Ivan, thanks for
> catching that.
> 
> -
> Denis
> 
> 
> On Wed, Aug 19, 2020 at 11:08 AM Ivan Pavlukhin  wrote:
> 
> > > We'd like to edit an article on cwiki. How can I get the editing rights
> > as a technical writer?
> >
> > I suppose we are talking about cwiki, not JIRA. Have you registered there?
> > https://cwiki.apache.org/confluence/signup.action
> >
> > 19.08.2020, Denis Magda написал(а):
> > > Evgeniy,
> > >
> > > Please tell your JIRA id/account_name. For some reason, I can't locate
> > your
> > > account with the email.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Aug 19, 2020 at 7:29 AM lonsdalel lonsdalel <
> > > eugenezabot...@gmail.com> wrote:
> > >
> > >> Hi Denis,
> > >>
> > >> my JIRA account is evzabot...@sberbank.ru.
> > >>
> > >> BR,
> > >> Evgeniy
> > >>
> > >> On 2020/08/17 18:31:33, Denis Magda  wrote:
> > >> > Hi Evgeniy,
> > >> >
> > >> > Please tell the email address of your JIRA account and we'll grant you
> > >> all
> > >> > necessary permissions.
> > >> >
> > >> > -
> > >> > Denis
> > >> >
> > >> >
> > >> > On Mon, Aug 17, 2020 at 9:28 AM Заботкин Евгений Владимирович
> > >> >  wrote:
> > >> >
> > >> > > Hello,
> > >> > >
> > >> > > We'd like to edit an article on cwiki. How can I get the editing
> > >> rights as
> > >> > > a technical writer?
> > >> > >
> > >> > > Best regards,
> > >> > > Evgeniy Zabotkin
> > >> > >
> > >> > > С уважением,
> > >> > > Евгений Заботкин<
> > >> > > http://addressbook.ca.sbrf.ru/home/Index?type=0&search=1818683>
> > >> > > ИТ-инженер (Технический писатель)
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > Даем людям уверенность и надежность!
> > >> > >
> > >> > > УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: Это электронное сообщение и любые
> > >> > > документы, приложенные к нему, содержат конфиденциальную информацию.
> > >> > > Настоящим уведомляем Вас о том, что если это сообщение не
> > >> > > предназначено
> > >> > > Вам, использование, копирование, распространение информации,
> > >> содержащейся в
> > >> > > настоящем сообщении, а также осуществление любых действий на основе
> > >> этой
> > >> > > информации, строго запрещено. Если Вы получили это сообщение по
> > >> > > ошибке,
> > >> > > пожалуйста, сообщите об этом отправителю по электронной почте и
> > >> удалите это
> > >> > > сообщение. CONFIDENTIALITY NOTICE: This email and any files attached
> > >> to it
> > >> > > are confidential. If you are not the intended recipient you are
> > >> notified
> > >> > > that using, copying, distributing or taking any action in reliance
> > on
> > >> the
> > >> > > contents of this information is strictly prohibited. If you have
> > >> received
> > >> > > this email in error please notify the sender and delete this email.
> > >> > >
> > >> >
> > >>
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> 

Re: IEP-51: Java Thin Client Async API

[Pavel Tupitsyn]

I've changed the IEP and added a new future interface to the POC:
interface IgniteClientFuture extends Future, CompletionStage

The implementation simply wraps the CompletableFuture.

On Fri, Aug 21, 2020 at 11:22 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Pavel,
>
> Interesting findings :) Agree that we should not use the CompletableFuture
> - it clearly has a different purpose.
>
> I think that the approach taken by Redis makes more sense. I don't like
> that it requires a custom interface, but I think we can live with that.
>
> I would be glad to hear other opinions though.
>
> -Val
>
> On Fri, Aug 21, 2020 at 1:02 AM Pavel Tupitsyn 
> wrote:
>
> > Val,
> >
> > The problems with CompletableFuture in public API are:
> > * It is a class, not an interface
> > * It is completable - anyone can call .complete(), which is not what we
> > want
> >
> > There seems to be no clear guidance in Java world on async API design;
> > however, it is often recommended to return CompletionStage instead of
> > CompletableFuture
> > from the public APIs [1] [2], and some products follow this [3].
> >
> > Other products return their own future interface that extends both Future
> > and CompletionStage,
> > which seems to be a better alternative to me [4].
> >
> > Thoughts?
> >
> > [1]
> >
> >
> https://stackoverflow.com/questions/47571117/what-is-the-difference-between-completionstage-and-completablefuture
> > [2]
> >
> >
> https://stackoverflow.com/questions/34930840/should-i-return-completablefuture-or-future-when-defining-api
> > <
> >
> https://stackoverflow.com/questions/34930840/should-i-return-completablefuture-or-future-when-defining-api#:~:text=by%20returning%20a%20CompletableFuture%2C%20you,API%2C%20which%20is%20not%20good
> > .>
> > [3]
> >
> >
> https://docs.hazelcast.org/docs/latest/javadoc/com/hazelcast/cache/ICache.html
> > [4]
> >
> >
> https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html
> >
> > On Fri, Aug 21, 2020 at 10:28 AM Alex Plehanov 
> > wrote:
> >
> > > Pavel,
> > >
> > > Thanks for the discussion, I've also faced with the necessity of having
> > > async calls while implementing POC for thin client data streamer [1]
> and
> > > solve it similarly (but in my case it's required only for internal
> > > implementation, so I've only changed the internal API).
> > >
> > > I want to note that described in IEP approach (and implemented in POC)
> is
> > > not fully async, since "send" is still used in the user's thread. To
> make
> > > it fully async we need additional sending thread (since blocking IO is
> > used
> > > for communication with the server). If partition awareness is enabled
> > there
> > > will be 2 threads per each server connection, perhaps we should think
> > about
> > > moving to NIO and introducing some kind of communication thread pool.
> > >
> > > [1]: https://github.com/apache/ignite/pull/8175
> > >
> > > пт, 21 авг. 2020 г. в 03:35, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > > Sounds good. I've added this to the 3.0 roadmap:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0
> > > >
> > > > Unless there are any objections from others, let's stick with the
> > > > CompletableFuture for any future development, including the thin
> > client.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 20, 2020 at 9:30 AM Pavel Tupitsyn  >
> > > > wrote:
> > > >
> > > > > Val, no objections from my side.
> > > > > As noted above, the only benefit of IgniteFuture is consistency
> > across
> > > > > thin/thick APIs,
> > > > > which is probably not so important.
> > > > >
> > > > > On Thu, Aug 20, 2020 at 6:28 PM Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > Hi Pavel,
> > > > > >
> > > > > > Are there any benefits of IgniteFuture over CompletableFuture?
> > > > > >
> > > > > > IgniteFuture was created long ago, during the time when
> > > > CompletableFuture
> > > > > > did not exist. There is a big chance that IgniteFuture actually
> > > became
> > > > > > redundant at the moment we transitioned to Java8. If that's the
> > > case, I
> > > > > > would prefer using CompletableFuture in the thin client and
> getting
> > > rid
> > > > > of
> > > > > > IgniteFuture altogether in 3.0.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Thu, Aug 20, 2020 at 7:19 AM Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I've prepared an IEP [1], please review and let me know what
> you
> > > > think.
> > > > > > >
> > > > > > > In particular, I'd like to discuss the Future interface to be
> > used:
> > > > > > > * IgniteFuture is the first candidate - Thin APIs will be
> > > consistent
> > > > > with
> > > > > > > Thick APIs, probably better for existing Ignite users.
> > > > > > > * CompletableFuture is the standard for async Java APIs.

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

[Nikita Amelchev]

I think this is a helpful feature. I have created the issue:

https://issues.apache.org/jira/browse/IGNITE-13380

[jira] [Created] (IGNITE-13380) Output IgniteSystemProperties via ignite.sh

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-13380:


 Summary: Output IgniteSystemProperties via ignite.sh
 Key: IGNITE-13380
 URL: https://issues.apache.org/jira/browse/IGNITE-13380
 Project: Ignite
  Issue Type: New Feature
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


Provide the ability output of all available Ignite properties 
(`IgniteSystemProperties`) with its descriptions in the `ignite.sh` command. 
For example, `ignite.sh -systemProps`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)