Re: Micronaut/Ignite

Here is a sample project I threw together and I've also updated the wiki just a bit. working on updating the documentation on the micronaut end. https://cwiki.apache.org/confluence/display/IGNITE/Micronaut+Integration https://github.com/pollend/micronaut-ignite-sample On Mon, Aug 24, 2020 at

Re: Ignite 3.0 meetups

Hi Val, Thank you for scheduling the meetups. Will join and connect on Ignite 3.0 release planning. Regards, Saikat On Tue, Aug 25, 2020 at 4:49 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Igniters, > > As was discussed before, we've scheduled two meetups devoted to Ignite

Ignite 3.0 meetups

Igniters, As was discussed before, we've scheduled two meetups devoted to Ignite 3.0: - Sep 15 (in English): https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272675408/ - Sep 17 (in Russian): https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/272675398/ I will

Suggest add Serializable to Blas class (Ignite ML)

Hi, @Alexey Zinoviev . I found that class Blas (org.apache.ignite.ml.math) is not Serializable but fields f2jBlas and nativeBlas are transient. So I suggest adding a Serializable to Blas class. -- Best regards, Mark Andreev

Suggest improvement to Util classes (Ignite ML)

Hi, @Alexey Zinoviev . I suggest to add a final class modifier and to add a private constructor to Util classes in ignite ml. This is Sonar rule RSPEC-1118 ( https://rules.sonarsource.com/java/tag/design/RSPEC-1118). Motivation: Utility classes, which are collections of static members, are not

Re: Editing rights

Hi, You may create an INFRA ticket in JIRA https://issues.apache.org/jira/projects/INFRA/issues describing the problem. As a workaround you can try your gmail address in cwiki. I expect it might be simpler than using a corporate one. 2020-08-25 10:49 GMT+03:00, lonsdalel lonsdalel : > Thanks!

[jira] [Created] (IGNITE-13385) Documentation of cache warm-up strategy

Kirill Tkalenko created IGNITE-13385: Summary: Documentation of cache warm-up strategy Key: IGNITE-13385 URL: https://issues.apache.org/jira/browse/IGNITE-13385 Project: Ignite Issue

Re: Editing rights

Thanks! But now, I have another problem, which is I can't log in, because some time ago I forgot my password and needed to get a new one by e-mail, but it didn't come. COuld we find any solution to this problem? Maybe you could send a new password to my account e-mail, or delete my account? In

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

Hi Igniters, Separate API module sounds nice to me as well. And I also think it is fine that thin client does not support as much operations as client node, because it is appealing to evolve API not strictly synchronously. And I can imagine several options: 1. Have rich API with possibility to

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

I am wrong Alex but let me provide some history: when I originally developed the Java thin client 3 years ago I suggested to take all public API out of ignite-core.jar into a separate ignite-api.jar and develop Java thin client implementing the common API from the ignite-api.jar. So the

[jira] [Created] (IGNITE-13384) Auto-generated README.txt contains invalid workingDirectory property name

Alexey Kukushkin created IGNITE-13384: - Summary: Auto-generated README.txt contains invalid workingDirectory property name Key: IGNITE-13384 URL: https://issues.apache.org/jira/browse/IGNITE-13384

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

Thanks ! now its clear for me, ones more want to repeat my position — sending exceptions to the client side looks like bad design, because exceptions its about unhealthy system recognition from administrator side, not from client of course, but looks like for now it`s more informative than

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

> > Alexey. > > This option should be on the server side, so server administrator can > disable stack trace for all clients. > Correct? > Yes, correct.

Re: IEP-51: Java Thin Client Async API

Hello folks, I agree with Val: IgniteFuture was created long before we could use the Java futures and is being kept for compatibility reasons. While keeping API consistent between thin/thick clients is a good reason, I think moving to Java futures benefits more to the project and end-users.

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

Alexey. This option should be on the server side, so server administrator can disable stack trace for all clients. Correct? > 25 авг. 2020 г., в 12:47, Alexey Goncharuk > написал(а): > > Zhenya, > > Stacktraces are considered to be able to expose sensitive information about > code, see [1].

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

Zhenya, Stacktraces are considered to be able to expose sensitive information about code, see [1]. So as previously, I agree with Pavel that we should have an option to disable this behavior. [1]

[jira] [Created] (IGNITE-13383) Java thin client improvements: channel reconnect and redundant concurrency structures replacement.

Stanilovsky Evgeny created IGNITE-13383: --- Summary: Java thin client improvements: channel reconnect and redundant concurrency structures replacement. Key: IGNITE-13383 URL:

Re: First contribute to Ignite ML

Great, I'll create a ticket for that case and assign it for you, I think it could be very useful contribution. вт, 25 авг. 2020 г., 10:07 Mark Andreev : > Hi, @Alexey Zinoviev . > > Currently, Ignite supports only these distances > (org.apache.ignite.ml.math.distances) : > - ChebyshevDistance

Re: IEP-51: Java Thin Client Async API

Hi guys, It would be really cool to have async operations. My point is that the worst thing that we have at the moment is that we need to write data to the socket under the sndLock. It makes it nearly impossible for users to implement async operations on their side. Of course they can scale up by

Re: First contribute to Ignite ML

Hi, @Alexey Zinoviev . Currently, Ignite supports only these distances (org.apache.ignite.ml.math.distances) : - ChebyshevDistance - CosineSimilarity - EuclideanDistance - HammingDistance - JaccardIndex - ManhattanDistance - MinkowskiDistance But in scipy (

Re: Any reason to keep ClientConfiguration final?

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