Re: Exception handling in thin client: should we pass stack traces to the client?

I think this behavior should be configurable. We can have it on by default, but have a setting to disable, e.g.: ThinClientConfiguration.excludeErrorStackTraces On Fri, Aug 21, 2020 at 9:54 AM Zhenya Stanilovsky wrote: > > Guys, does anyone else bothers about it ?) > Ones more — i really not sur

Re: IEP-51: Java Thin Client Async API

Ok, I've reflected this in the IEP On Fri, Aug 21, 2020 at 3:35 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > 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,

Re: IEP-51: Java Thin Client Async API

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 de

Re: IEP-51: Java Thin Client Async API

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 CompletionSt

Re: IEP-51: Java Thin Client Async API

Alex, > not fully async, since "send" is still used in the user's thread Correct. I've added those details to the IEP. I'll investigate the ways to make this fully non-blocking, but for now let's consider this to be out of scope of this IEP. > POC for thin client data streamer Very interesting, i

Skip distributed metastorage entries that can not be unmarshalled

Hello, Igniters. I would add the feature that allows skipping the distributed metastorage entries that can not be unmarshalled [1]. These entries can be created by the product that built on Apache Ignite and incorporates additional features. It will be useful during migrating with keeping user per

Re: Skip distributed metastorage entries that can not be unmarshalled

+1 > 21 авг. 2020 г., в 12:17, Nikita Amelchev написал(а): > > Hello, Igniters. > > I would add the feature that allows skipping the distributed > metastorage entries that can not be unmarshalled [1]. > These entries can be created by the product that built on Apache > Ignite and incorporates a

[DISCUSSION] Consistency across java thin/thick APIs

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 th

Re: IEP-51: Java Thin Client Async API

Pavel, > Very interesting, is there a ticket or IEP to follow? No, there is no ticket or IEP. I will create ticket, IEP and dev-list discussion after benchmarking of POC implementation. пт, 21 авг. 2020 г. в 12:17, Pavel Tupitsyn : > Alex, > > > not fully async, since "send" is still used in the

[jira] [Created] (IGNITE-13378) .NET: Thin Client: Use non-blocking socket IO

Pavel Tupitsyn created IGNITE-13378: --- Summary: .NET: Thin Client: Use non-blocking socket IO Key: IGNITE-13378 URL: https://issues.apache.org/jira/browse/IGNITE-13378 Project: Ignite Issue

[jira] [Created] (IGNITE-13379) Exception occur on SQL caches when client reconnect

Vladislav Pyatkov created IGNITE-13379: -- Summary: Exception occur on SQL caches when client reconnect Key: IGNITE-13379 URL: https://issues.apache.org/jira/browse/IGNITE-13379 Project: Ignite

[DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello, Igniters. For now, we have dozens of the `IgniteSystemProperties` [1] that can tweak Ignite behaviour in the very wide limits. But, the issue, for the administrator is the following - Documentation about existing properties can be outdated. - The only place of the truth is the source cod

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Good catch, as for me, do you plan some autogeneration here?   >  >>  >>>Hello, Igniters. >>> >>>For now, we have dozens of the `IgniteSystemProperties` [1] that can tweak >>>Ignite behaviour in the very wide limits. >>>But, the issue, for the administrator is the following >>> >>>- Documentatio

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Yes, of course. I think we have to make IgniteSystemProperties enum and traverse it in runtime. Отправлено с iPhone > 21 авг. 2020 г., в 17:54, Zhenya Stanilovsky > написал(а): > >  > > Good catch, as for me, do you plan some autogeneration here? > >> >>> Hello, Igniters. >>

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Nikolay, I fully support the idea as well but wonder if the "-X" is the best name. Is this a common practice to use the "-X"? Should we consider a longer name such as "-systemProps"? - Denis On Fri, Aug 21, 2020 at 7:57 AM Николай Ижиков wrote: > Yes, of course. > I think we have to make Ign

Re: IEP-51: Java Thin Client Async API

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

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

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!

Re: Micronaut/Ignite

Michael, Finally, I figured out Micronaut configuration specificities. What confused me before, is that even though the beans configuration in Micronaut looks quite similar to the Spring Boot approach, the former automates a lot with the help of reflection in runtime. That's how our default Spring

Re: [DISCUSSION] Output IgniteSystemProperties via ignite.sh

Hello, Denis. Thanks, for the support. The name of the parameter is the matter of discussion, of course. I just take the JVM approach as an example. Let’s go with the -systemProps :) > 21 авг. 2020 г., в 18:04, Denis Magda написал(а): > > Nikolay, > > I fully support the idea as well but won

Re: Queries on setting up real-time analytics platform on ignite.

Hi Ed, 1. Yes, that's possible and you do this in Ignite by configuring several data regions . All the caches/tables with hot data will be mapped to data regions that are given most of the memory resources, while caches

Re: Micronaut/Ignite

Dennis, This is what I came up with with some of the suggestions: https://github.com/micronaut-projects/micronaut-ignite/blob/3e1529ca4a40c2eb00793e344a36bb48d2a7d3fe/ignite-core/src/main/java/io/micronaut/ignite/configuration/DefaultIgniteConfiguration.java and https://github.com/micronaut-projec

Re: Micronaut/Ignite

Michael, Thanks, for verifying. I've tried extending ClientConfiguration but couldn't get the > getters/setters working with ConfigurationBuilder. Instead they are just > placed into wrapper classes. Have a look at how Hazelcast implemented the default configuration for its thin client by exten