[jira] [Created] (IGNITE-13989) Destroy of persisted cache doesn't remove cache folder
Pavel Vinokurov created IGNITE-13989: Summary: Destroy of persisted cache doesn't remove cache folder Key: IGNITE-13989 URL: https://issues.apache.org/jira/browse/IGNITE-13989 Project: Ignite Issue Type: Bug Affects Versions: 2.9.1 Reporter: Pavel Vinokurov IgniteCache#destroy doesn't remove the folder in the persistent storage. Creating/Destroying dynamic caches could clutter the PDS and meet with the system limits -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: SHA-512 for Maven deployment
Hi Ivan, No, I haven't found a way yet. SHA1 still works, but I believe we should consider using better options in future releases. Do you have any ideas on how to implement this? -Val On Wed, Jan 13, 2021 at 8:21 AM Ivan Pavlukhin wrote: > Folks, > > Were you able to resolve this? > > 2020-12-28 22:15 GMT+03:00, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > Hi Ivan, > > > > Thanks for your response. I've looked into the PGP plugin, and > > unfortunately it looks like it only can create signatures, but not > > checksums. > > > > -Val > > > > On Sun, Dec 27, 2020 at 11:54 PM Ivan Bessonov > > wrote: > > > >> Hi, > >> > >> I've never done this before, but it seems like we need maven-gpg-plugin > >> for > >> it [1]. > >> > >> Algorithm configuration would look like this: > >> > >> --digest-algo=SHA512 > >> > >> > >> Maybe this will help. > >> > >> [1] > >> > >> > http://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/sign-mojo.html > >> > >> пн, 28 дек. 2020 г. в 01:25, Valentin Kulichenko < > >> valentin.kuliche...@gmail.com>: > >> > >> > Igniters, > >> > > >> > I've been preparing the 3.0.0-alpha1 release and got confused about > the > >> > requirements for checksums in Maven deployments. The Apache > instruction > >> [1] > >> > states that MD5 is deprecated and SHA1 should be avoided in favor of > >> > SHA-256 or SHA-512. However, it looks like we are still using the > >> MD5/SHA1 > >> > combination (at least that's what the staging for 2.9.1 [2] contains). > >> > > >> > On top of that, I can't find an easy way to switch to another checksum > >> > - > >> > Maven deploy plugin [3] creates MD5 and SHA1 files automatically and > >> > doesn't seem to have any options to tweak this behavior. > >> > > >> > That said, I have two questions: > >> > > >> >1. Are we required to use SHA512 or MD5/SHA1 is OK for now? > >> >2. Is there a painless way to include SHA512 in addition to > >> > MD5/SHA1? > >> > > >> > Can anyone shed some light on this? > >> > > >> > [1] https://infra.apache.org/release-signing.html#basic-facts > >> > [2] > >> > > >> > > >> > https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ > >> > [3] > >> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > >> > > >> > -Val > >> > > >> > >> > >> -- > >> Sincerely yours, > >> Ivan Bessonov > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: [DISCUSSION] 3.0.0 Alpha release
Hi! Here's the link for the upcoming meetup (January 26) https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/275722317/ ср, 13 янв. 2021 г. в 21:38, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Hi Ivan, > > Yesterday I created an email thread that can be used for this: > - > > http://apache-ignite-developers.2346864.n4.nabble.com/Looking-for-feedback-on-the-Ignite-3-0-0-Alpha-td51012.html > - > > http://apache-ignite-users.70518.x6.nabble.com/Looking-for-feedback-on-the-Ignite-3-0-0-Alpha-td35089.html > > In addition, we are planning to have a virtual meetup at the end of the > month - we can discuss there as well. The meetup will be scheduled soon. > > -Val > > On Wed, Jan 13, 2021 at 4:25 AM Ivan Pavlukhin > wrote: > > > Val, Igniters, > > > > I thought about possible results of such release. How do we expect to > > receive feedback? It would be interesting personally for me to see > > feedback/results summary. > > > > 2021-01-01 2:59 GMT+03:00, Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > Igniters, > > > > > > Big thanks to everyone involved in the preparation for this alpha > > release! > > > > > > Throughout this week, the current codebase has been tested on Linux and > > > Windows, all the major issues have been resolved, and the Getting > Started > > > guide has been created. We're now ready for the vote - I will start it > > > sometime during the weekend or early next week. > > > > > > Happy New Year everyone! > > > > > > -Val > > > > > > On Thu, Dec 31, 2020 at 3:03 AM Fedor Malchikov < > fmalchi...@gridgain.com > > > > > > wrote: > > > > > >> Hi Valentin, > > >> > > >> Yes, of course. > > >> I closed tickets for fixed issues and created a few more new ones. > > >> > > >> On Thu, Dec 31, 2020 at 8:57 AM Valentin Kulichenko < > > >> valentin.kuliche...@gmail.com> wrote: > > >> > > >> > Hi Fedor, > > >> > > > >> > Thanks again - you're really helping to improve the quality of the > > >> release. > > >> > > > >> > I've fixed everything except for the progress bar issue - should not > > be > > >> > a > > >> > blocker though, I will move it outside of the alpha if I do not > > succeed > > >> by > > >> > the end of tomorrow. > > >> > > > >> > Can you please verify that other issues are fixed (especially > > >> > IGNITE-13936)? Here is the new staging: > > >> > > > https://repository.apache.org/content/repositories/orgapacheignite-1500/ > > >> > > > >> > -Val > > >> > > > >> > On Wed, Dec 30, 2020 at 5:31 AM Fedor Malchikov > > >> > > >> > > > >> > wrote: > > >> > > > >> > > Hi Valentin, > > >> > > I looked at the resources available on staging and found a number > of > > >> > > additional issues: > > >> > > One blocker: > > >> > > https://issues.apache.org/jira/browse/IGNITE-13936 > > >> > > and three minor: > > >> > > https://issues.apache.org/jira/browse/IGNITE-13938 > > >> > > https://issues.apache.org/jira/browse/IGNITE-13937 > > >> > > https://issues.apache.org/jira/browse/IGNITE-13939 > > >> > > > > >> > > On Mon, Dec 28, 2020 at 10:24 PM Valentin Kulichenko < > > >> > > valentin.kuliche...@gmail.com> wrote: > > >> > > > > >> > > > I've also noticed that there is functionality allowing to use > > >> > > > custom > > >> > > Maven > > >> > > > repositories. However, it is available only for the 'module add' > > >> > command, > > >> > > > but not for the 'init' command. Created a ticket for this as > well: > > >> > > > https://issues.apache.org/jira/browse/IGNITE-13923 > > >> > > > > > >> > > > -Val > > >> > > > > > >> > > > On Mon, Dec 28, 2020 at 11:21 AM Valentin Kulichenko < > > >> > > > valentin.kuliche...@gmail.com> wrote: > > >> > > > > > >> > > > > Hi Fedor, > > >> > > > > > > >> > > > > Thanks for doing this! > > >> > > > > > > >> > > > > Regarding IGNITE-13921: in the first version, the tool created > > >> > > > > the > > >> > > > folders > > >> > > > > in the current directory, which created unpredictable > behavior, > > >> > > > > so > > >> we > > >> > > > > switched to home as default. However, using the folder where > the > > >> tool > > >> > > is > > >> > > > > located instead of the home folder seems fair - I've included > > the > > >> > > ticket > > >> > > > > into the alpha1. Also, note that in the next versions, there > > will > > >> be > > >> > an > > >> > > > > option to customize the paths, so the user will not have to > rely > > >> > > > > on > > >> > > > default > > >> > > > > values. > > >> > > > > > > >> > > > > If you don't mind, I suggest to postpone other issues for > > further > > >> > > > > development - they do not look so critical. > > >> > > > > > > >> > > > > -Val > > >> > > > > > > >> > > > > On Mon, Dec 28, 2020 at 9:45 AM Fedor Malchikov < > > >> > > fmalchi...@gridgain.com > > >> > > > > > > >> > > > > wrote: > > >> > > > > > > >> > > > >> Hello everyone, > > >> > > > >> I smoke tested the alpha version of the CLI tool on ubuntu > and > > >> > > windows. > > >> > > > So > > >> > > > >> I found the following issues: > >
Re: [DISCUSSION] .Net BinaryTypes transparency
> I propose to implicitly register classes only in the case they are sent to the Java side. Ok, I guess we can do this when all of the following is true - We are inside ExecuteJavaTask or Java service call - FQN mapper is used (default or explicit) - There is no BinaryIdMapper on .NET or Java side On Wed, Jan 13, 2021 at 6:30 PM Nikolay Izhikov wrote: > Pavel. > > > Yes, but they are registered separately for .NET and Java, please see > how MarshallerContextImpl stores typeId->typeName mappings. > > This will not change. We still will have separate type registration. > > > With the proposal we put all class names in the same pile. > > Implementation of type registration will not be changed. > What I propose is to simplify user life in the exact places we can do it > for free. > > > Now imagine that the user has a cluster with C# and Java clients. > > C# client uses class "foo.bar.Aa" for Compute, > > Java client uses class "foo.bar.BB" for Services - independent use > cases, > > all is well. > > I propose to implicitly register classes only in the case they are sent to > the Java side. > So, for all classes that is used only in .Net nothing will change. > > > > 13 янв. 2021 г., в 15:14, Pavel Tupitsyn > написал(а): > > > >> Classes MUST be registered to be used in compute or cache. > > > > Yes, but they are registered separately for .NET and Java, > > please see how MarshallerContextImpl stores typeId->typeName mappings. > > > > With the proposal we put all class names in the same pile. > > > > Now imagine that the user has a cluster with C# and Java clients. > > C# client uses class "foo.bar.Aa" for Compute, > > Java client uses class "foo.bar.BB" for Services - independent use > cases, > > all is well. > > > > As soon as we put all class names in the same map, the app breaks, > > because "foo.bar.Aa" and "foo.bar.BB" have the same hash code, > > and DuplicateTypeIdException is thrown by Ignite. > > > > On Wed, Jan 13, 2021 at 1:54 PM Nikolay Izhikov > wrote: > > > >> Hello, Pavel. > >> > >>> Imagine that some Ignite user has lots of .NET and Java classes being > >> stored in cache, used in compute, > >> > >> Classes MUST be registered to be used in compute or cache. > >> So, in your example, user registered classes by hand, already. > >> > >>> Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, > >> > >> We already have this «flag». > >> It a default INameMapper implementation that assumes we use the same > class > >> names both in Java and .Net. > >> > >>> This is not up for discussion, we do not break compatibility like this. > >> > >> Sorry, I don’t see compatibility issues in the proposal. > >> Can you, please, provide an example? > >> > >>> 13 янв. 2021 г., в 13:46, Pavel Tupitsyn > >> написал(а): > >>> > >>> Nikolay, > >>> > >>> I agree with your proposal, with one addition: > >>> this behavior must be disabled by default for compatibility reasons. > >>> > >>> Imagine that some Ignite user has lots of .NET and Java classes being > >>> stored in cache, > >>> used in compute, etc. Now with the proposal implemented, all .NET > classes > >>> are registered > >>> as Java classes too, which has a potential for hash code collisions, > >>> resulting in DuplicateTypeIdException. > >>> > >>> So the user can't upgrade to 2.11, their app does not work anymore, > which > >>> is not acceptable. > >>> This is not up for discussion, we do not break compatibility like this. > >>> > >>> Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, > >>> which enables the behavior globally and both ways: > >>> all type names become shared across all platforms in > >> MarshallerContextImpl. > >>> > >>> > >>> On Wed, Jan 13, 2021 at 11:21 AM Nikolay Izhikov > >>> wrote: > >>> > Hello, Pavel > > My proposal is the following: > > *When Ignite configured with FQN NameMapper.* > And user invokes > > 1. Service method from .Net to Java. > 2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync` > 3. Cache operations. > > Ignite should implicitly register types both for .Net and Java > platform. > > = > My intentions is to simplify usage of the Ignite .Net platform by > eliminating necessity of BinaryConfiguration in .Net. > > Approach when user should modify Ignite configuration on both sides > Java > and .Net every time he use new class as a service parameter looks > ugly, > >> for > me. > > You can see an example of my idea in services test [1] > In current release, user forced to enlist each type in configuration. > Now, you just deploy Java service and use it. > > Please, Note: > > 1. FQN NameMapper is a default value. > 2. FQN NameMapper requires from the user to have exactly same names > for > custom binary types in Java and .Net. > 3. Improvals for Services in master, already. > > [1] > > >> >
Re: SHA-512 for Maven deployment
Folks, Were you able to resolve this? 2020-12-28 22:15 GMT+03:00, Valentin Kulichenko : > Hi Ivan, > > Thanks for your response. I've looked into the PGP plugin, and > unfortunately it looks like it only can create signatures, but not > checksums. > > -Val > > On Sun, Dec 27, 2020 at 11:54 PM Ivan Bessonov > wrote: > >> Hi, >> >> I've never done this before, but it seems like we need maven-gpg-plugin >> for >> it [1]. >> >> Algorithm configuration would look like this: >> >> --digest-algo=SHA512 >> >> >> Maybe this will help. >> >> [1] >> >> http://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/sign-mojo.html >> >> пн, 28 дек. 2020 г. в 01:25, Valentin Kulichenko < >> valentin.kuliche...@gmail.com>: >> >> > Igniters, >> > >> > I've been preparing the 3.0.0-alpha1 release and got confused about the >> > requirements for checksums in Maven deployments. The Apache instruction >> [1] >> > states that MD5 is deprecated and SHA1 should be avoided in favor of >> > SHA-256 or SHA-512. However, it looks like we are still using the >> MD5/SHA1 >> > combination (at least that's what the staging for 2.9.1 [2] contains). >> > >> > On top of that, I can't find an easy way to switch to another checksum >> > - >> > Maven deploy plugin [3] creates MD5 and SHA1 files automatically and >> > doesn't seem to have any options to tweak this behavior. >> > >> > That said, I have two questions: >> > >> >1. Are we required to use SHA512 or MD5/SHA1 is OK for now? >> >2. Is there a painless way to include SHA512 in addition to >> > MD5/SHA1? >> > >> > Can anyone shed some light on this? >> > >> > [1] https://infra.apache.org/release-signing.html#basic-facts >> > [2] >> > >> > >> https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ >> > [3] >> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html >> > >> > -Val >> > >> >> >> -- >> Sincerely yours, >> Ivan Bessonov >> > -- Best regards, Ivan Pavlukhin
Re: [DISCUSSION] 3.0.0 Alpha release
Hi Ivan, Yesterday I created an email thread that can be used for this: - http://apache-ignite-developers.2346864.n4.nabble.com/Looking-for-feedback-on-the-Ignite-3-0-0-Alpha-td51012.html - http://apache-ignite-users.70518.x6.nabble.com/Looking-for-feedback-on-the-Ignite-3-0-0-Alpha-td35089.html In addition, we are planning to have a virtual meetup at the end of the month - we can discuss there as well. The meetup will be scheduled soon. -Val On Wed, Jan 13, 2021 at 4:25 AM Ivan Pavlukhin wrote: > Val, Igniters, > > I thought about possible results of such release. How do we expect to > receive feedback? It would be interesting personally for me to see > feedback/results summary. > > 2021-01-01 2:59 GMT+03:00, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > Igniters, > > > > Big thanks to everyone involved in the preparation for this alpha > release! > > > > Throughout this week, the current codebase has been tested on Linux and > > Windows, all the major issues have been resolved, and the Getting Started > > guide has been created. We're now ready for the vote - I will start it > > sometime during the weekend or early next week. > > > > Happy New Year everyone! > > > > -Val > > > > On Thu, Dec 31, 2020 at 3:03 AM Fedor Malchikov > > > wrote: > > > >> Hi Valentin, > >> > >> Yes, of course. > >> I closed tickets for fixed issues and created a few more new ones. > >> > >> On Thu, Dec 31, 2020 at 8:57 AM Valentin Kulichenko < > >> valentin.kuliche...@gmail.com> wrote: > >> > >> > Hi Fedor, > >> > > >> > Thanks again - you're really helping to improve the quality of the > >> release. > >> > > >> > I've fixed everything except for the progress bar issue - should not > be > >> > a > >> > blocker though, I will move it outside of the alpha if I do not > succeed > >> by > >> > the end of tomorrow. > >> > > >> > Can you please verify that other issues are fixed (especially > >> > IGNITE-13936)? Here is the new staging: > >> > > https://repository.apache.org/content/repositories/orgapacheignite-1500/ > >> > > >> > -Val > >> > > >> > On Wed, Dec 30, 2020 at 5:31 AM Fedor Malchikov > >> > >> > > >> > wrote: > >> > > >> > > Hi Valentin, > >> > > I looked at the resources available on staging and found a number of > >> > > additional issues: > >> > > One blocker: > >> > > https://issues.apache.org/jira/browse/IGNITE-13936 > >> > > and three minor: > >> > > https://issues.apache.org/jira/browse/IGNITE-13938 > >> > > https://issues.apache.org/jira/browse/IGNITE-13937 > >> > > https://issues.apache.org/jira/browse/IGNITE-13939 > >> > > > >> > > On Mon, Dec 28, 2020 at 10:24 PM Valentin Kulichenko < > >> > > valentin.kuliche...@gmail.com> wrote: > >> > > > >> > > > I've also noticed that there is functionality allowing to use > >> > > > custom > >> > > Maven > >> > > > repositories. However, it is available only for the 'module add' > >> > command, > >> > > > but not for the 'init' command. Created a ticket for this as well: > >> > > > https://issues.apache.org/jira/browse/IGNITE-13923 > >> > > > > >> > > > -Val > >> > > > > >> > > > On Mon, Dec 28, 2020 at 11:21 AM Valentin Kulichenko < > >> > > > valentin.kuliche...@gmail.com> wrote: > >> > > > > >> > > > > Hi Fedor, > >> > > > > > >> > > > > Thanks for doing this! > >> > > > > > >> > > > > Regarding IGNITE-13921: in the first version, the tool created > >> > > > > the > >> > > > folders > >> > > > > in the current directory, which created unpredictable behavior, > >> > > > > so > >> we > >> > > > > switched to home as default. However, using the folder where the > >> tool > >> > > is > >> > > > > located instead of the home folder seems fair - I've included > the > >> > > ticket > >> > > > > into the alpha1. Also, note that in the next versions, there > will > >> be > >> > an > >> > > > > option to customize the paths, so the user will not have to rely > >> > > > > on > >> > > > default > >> > > > > values. > >> > > > > > >> > > > > If you don't mind, I suggest to postpone other issues for > further > >> > > > > development - they do not look so critical. > >> > > > > > >> > > > > -Val > >> > > > > > >> > > > > On Mon, Dec 28, 2020 at 9:45 AM Fedor Malchikov < > >> > > fmalchi...@gridgain.com > >> > > > > > >> > > > > wrote: > >> > > > > > >> > > > >> Hello everyone, > >> > > > >> I smoke tested the alpha version of the CLI tool on ubuntu and > >> > > windows. > >> > > > So > >> > > > >> I found the following issues: > >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13914 > >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13924 > >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13921 > >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13922 > >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13920 > >> > > > >> > >> > > > >> > >> > > > >> On Sun, Dec 27, 2020 at 2:18 AM Valentin Kulichenko < > >> > > > >> valentin.kuliche...@gmail.com> wrote: > >> > > > >> > >> > > > >> > Folks, > >> > > > >> > > >> > > > >> >
Re: SHA-512 for Maven deployment
Maybe, we could donate to maven plugin possibility to switch to SHA-512. Hopefully, a new plugin version will be released before we have any release candidate. Is it looks like a big deal? ср, 13 янв. 2021 г., 21:32 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Hi Ivan, > > No, I haven't found a way yet. SHA1 still works, but I believe we should > consider using better options in future releases. > > Do you have any ideas on how to implement this? > > -Val > > On Wed, Jan 13, 2021 at 8:21 AM Ivan Pavlukhin > wrote: > > > Folks, > > > > Were you able to resolve this? > > > > 2020-12-28 22:15 GMT+03:00, Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > Hi Ivan, > > > > > > Thanks for your response. I've looked into the PGP plugin, and > > > unfortunately it looks like it only can create signatures, but not > > > checksums. > > > > > > -Val > > > > > > On Sun, Dec 27, 2020 at 11:54 PM Ivan Bessonov > > > wrote: > > > > > >> Hi, > > >> > > >> I've never done this before, but it seems like we need > maven-gpg-plugin > > >> for > > >> it [1]. > > >> > > >> Algorithm configuration would look like this: > > >> > > >> --digest-algo=SHA512 > > >> > > >> > > >> Maybe this will help. > > >> > > >> [1] > > >> > > >> > > > http://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/sign-mojo.html > > >> > > >> пн, 28 дек. 2020 г. в 01:25, Valentin Kulichenko < > > >> valentin.kuliche...@gmail.com>: > > >> > > >> > Igniters, > > >> > > > >> > I've been preparing the 3.0.0-alpha1 release and got confused about > > the > > >> > requirements for checksums in Maven deployments. The Apache > > instruction > > >> [1] > > >> > states that MD5 is deprecated and SHA1 should be avoided in favor of > > >> > SHA-256 or SHA-512. However, it looks like we are still using the > > >> MD5/SHA1 > > >> > combination (at least that's what the staging for 2.9.1 [2] > contains). > > >> > > > >> > On top of that, I can't find an easy way to switch to another > checksum > > >> > - > > >> > Maven deploy plugin [3] creates MD5 and SHA1 files automatically and > > >> > doesn't seem to have any options to tweak this behavior. > > >> > > > >> > That said, I have two questions: > > >> > > > >> >1. Are we required to use SHA512 or MD5/SHA1 is OK for now? > > >> >2. Is there a painless way to include SHA512 in addition to > > >> > MD5/SHA1? > > >> > > > >> > Can anyone shed some light on this? > > >> > > > >> > [1] https://infra.apache.org/release-signing.html#basic-facts > > >> > [2] > > >> > > > >> > > > >> > > > https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ > > >> > [3] > > >> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > >> > > > >> > -Val > > >> > > > >> > > >> > > >> -- > > >> Sincerely yours, > > >> Ivan Bessonov > > >> > > > > > > > > > -- > > > > Best regards, > > Ivan Pavlukhin > > >
Re: Looking for feedback on the Ignite 3.0.0 Alpha
The meetup has been scheduled, please RSVP here: https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/275722317/ -Val On Wed, Jan 13, 2021 at 11:21 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Link to the Getting Started Guide: > https://ignite.apache.org/docs/3.0.0-alpha/quick-start/getting-started-guide > > -Val > > On Tue, Jan 12, 2021 at 7:55 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Igniters, >> >> I'm excited to announce that the first alpha build of the Ignite 3 is out >> and available for download! >> >> Ignite 3 is the new project that was initiated by the Ignite community >> last year. Please refer to this page if you want to learn more: >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 >> >> The just-released alpha build is a sneak peek into the future of Ignite. >> It doesn't represent a fully-functional product (no discovery, caches, >> compute, etc.), but demonstrates major mechanics of how you will interact >> with Ignite going forward. >> >> The main goal of the release is to gather feedback from the community so >> that we can adjust further development if needed. That said, I would ask >> and encourage everyone to go through the Getting Started Guide [1] and play >> with the build. If you have any questions, issues, concerns, wishes, >> requests, or any other thoughts, please reply directly to this thread. We >> will carefully accumulate all the feedback and make sure it is considered >> going forward. >> >> Another opportunity to share your feedback will come closer to the end of >> January when we will have a virtual meetup. I will present a quick demo of >> the alpha build, after which we will have an open discussion. Please stay >> tuned - I will send a message here when the meetup is scheduled. >> >> -Val >> >
Re: Looking for feedback on the Ignite 3.0.0 Alpha
Link to the Getting Started Guide: https://ignite.apache.org/docs/3.0.0-alpha/quick-start/getting-started-guide -Val On Tue, Jan 12, 2021 at 7:55 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Igniters, > > I'm excited to announce that the first alpha build of the Ignite 3 is out > and available for download! > > Ignite 3 is the new project that was initiated by the Ignite community > last year. Please refer to this page if you want to learn more: > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 > > The just-released alpha build is a sneak peek into the future of Ignite. > It doesn't represent a fully-functional product (no discovery, caches, > compute, etc.), but demonstrates major mechanics of how you will interact > with Ignite going forward. > > The main goal of the release is to gather feedback from the community so > that we can adjust further development if needed. That said, I would ask > and encourage everyone to go through the Getting Started Guide [1] and play > with the build. If you have any questions, issues, concerns, wishes, > requests, or any other thoughts, please reply directly to this thread. We > will carefully accumulate all the feedback and make sure it is considered > going forward. > > Another opportunity to share your feedback will come closer to the end of > January when we will have a virtual meetup. I will present a quick demo of > the alpha build, after which we will have an open discussion. Please stay > tuned - I will send a message here when the meetup is scheduled. > > -Val >
Re: SHA-512 for Maven deployment
Hi Andrey, This indeed sounds like the cleanest way. I don't know how much effort that would be though. -Val On Wed, Jan 13, 2021 at 11:01 AM Andrey Mashenkov < andrey.mashen...@gmail.com> wrote: > Maybe, we could donate to maven plugin possibility to switch to SHA-512. > Hopefully, a new plugin version will be released before we have any release > candidate. > > Is it looks like a big deal? > > ср, 13 янв. 2021 г., 21:32 Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > Hi Ivan, > > > > No, I haven't found a way yet. SHA1 still works, but I believe we should > > consider using better options in future releases. > > > > Do you have any ideas on how to implement this? > > > > -Val > > > > On Wed, Jan 13, 2021 at 8:21 AM Ivan Pavlukhin > > wrote: > > > > > Folks, > > > > > > Were you able to resolve this? > > > > > > 2020-12-28 22:15 GMT+03:00, Valentin Kulichenko < > > > valentin.kuliche...@gmail.com>: > > > > Hi Ivan, > > > > > > > > Thanks for your response. I've looked into the PGP plugin, and > > > > unfortunately it looks like it only can create signatures, but not > > > > checksums. > > > > > > > > -Val > > > > > > > > On Sun, Dec 27, 2020 at 11:54 PM Ivan Bessonov < > bessonov...@gmail.com> > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> I've never done this before, but it seems like we need > > maven-gpg-plugin > > > >> for > > > >> it [1]. > > > >> > > > >> Algorithm configuration would look like this: > > > >> > > > >> --digest-algo=SHA512 > > > >> > > > >> > > > >> Maybe this will help. > > > >> > > > >> [1] > > > >> > > > >> > > > > > > http://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/sign-mojo.html > > > >> > > > >> пн, 28 дек. 2020 г. в 01:25, Valentin Kulichenko < > > > >> valentin.kuliche...@gmail.com>: > > > >> > > > >> > Igniters, > > > >> > > > > >> > I've been preparing the 3.0.0-alpha1 release and got confused > about > > > the > > > >> > requirements for checksums in Maven deployments. The Apache > > > instruction > > > >> [1] > > > >> > states that MD5 is deprecated and SHA1 should be avoided in favor > of > > > >> > SHA-256 or SHA-512. However, it looks like we are still using the > > > >> MD5/SHA1 > > > >> > combination (at least that's what the staging for 2.9.1 [2] > > contains). > > > >> > > > > >> > On top of that, I can't find an easy way to switch to another > > checksum > > > >> > - > > > >> > Maven deploy plugin [3] creates MD5 and SHA1 files automatically > and > > > >> > doesn't seem to have any options to tweak this behavior. > > > >> > > > > >> > That said, I have two questions: > > > >> > > > > >> >1. Are we required to use SHA512 or MD5/SHA1 is OK for now? > > > >> >2. Is there a painless way to include SHA512 in addition to > > > >> > MD5/SHA1? > > > >> > > > > >> > Can anyone shed some light on this? > > > >> > > > > >> > [1] https://infra.apache.org/release-signing.html#basic-facts > > > >> > [2] > > > >> > > > > >> > > > > >> > > > > > > https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ > > > >> > [3] > > > >> > https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > > >> > > > > >> > -Val > > > >> > > > > >> > > > >> > > > >> -- > > > >> Sincerely yours, > > > >> Ivan Bessonov > > > >> > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Ivan Pavlukhin > > > > > >
Re: SHA-512 for Maven deployment
Val, I've just found Maven projects use SHA-512. I passed through commits and found they just switched to newer parent org.apache:apache pom. I've compared our current parent pom with the latest available one (org.apache:apache:16 vs org.apache:apache:23) and then found checksum-maven-plugin was added [1] somewhen in between. So, seems we have to switched to newer apache pom and maybe add checksum-maven-plugin to our main pom. [1] https://github.com/apache/maven-apache-parent/commit/a46aa52b4b56d9b7aa62e1b8cbea5ff0af434a On Wed, Jan 13, 2021 at 10:41 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Andrey, > > This indeed sounds like the cleanest way. I don't know how much effort that > would be though. > > -Val > > On Wed, Jan 13, 2021 at 11:01 AM Andrey Mashenkov < > andrey.mashen...@gmail.com> wrote: > > > Maybe, we could donate to maven plugin possibility to switch to SHA-512. > > Hopefully, a new plugin version will be released before we have any > release > > candidate. > > > > Is it looks like a big deal? > > > > ср, 13 янв. 2021 г., 21:32 Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > > > Hi Ivan, > > > > > > No, I haven't found a way yet. SHA1 still works, but I believe we > should > > > consider using better options in future releases. > > > > > > Do you have any ideas on how to implement this? > > > > > > -Val > > > > > > On Wed, Jan 13, 2021 at 8:21 AM Ivan Pavlukhin > > > wrote: > > > > > > > Folks, > > > > > > > > Were you able to resolve this? > > > > > > > > 2020-12-28 22:15 GMT+03:00, Valentin Kulichenko < > > > > valentin.kuliche...@gmail.com>: > > > > > Hi Ivan, > > > > > > > > > > Thanks for your response. I've looked into the PGP plugin, and > > > > > unfortunately it looks like it only can create signatures, but not > > > > > checksums. > > > > > > > > > > -Val > > > > > > > > > > On Sun, Dec 27, 2020 at 11:54 PM Ivan Bessonov < > > bessonov...@gmail.com> > > > > > wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> I've never done this before, but it seems like we need > > > maven-gpg-plugin > > > > >> for > > > > >> it [1]. > > > > >> > > > > >> Algorithm configuration would look like this: > > > > >> > > > > >> --digest-algo=SHA512 > > > > >> > > > > >> > > > > >> Maybe this will help. > > > > >> > > > > >> [1] > > > > >> > > > > >> > > > > > > > > > > http://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/sign-mojo.html > > > > >> > > > > >> пн, 28 дек. 2020 г. в 01:25, Valentin Kulichenko < > > > > >> valentin.kuliche...@gmail.com>: > > > > >> > > > > >> > Igniters, > > > > >> > > > > > >> > I've been preparing the 3.0.0-alpha1 release and got confused > > about > > > > the > > > > >> > requirements for checksums in Maven deployments. The Apache > > > > instruction > > > > >> [1] > > > > >> > states that MD5 is deprecated and SHA1 should be avoided in > favor > > of > > > > >> > SHA-256 or SHA-512. However, it looks like we are still using > the > > > > >> MD5/SHA1 > > > > >> > combination (at least that's what the staging for 2.9.1 [2] > > > contains). > > > > >> > > > > > >> > On top of that, I can't find an easy way to switch to another > > > checksum > > > > >> > - > > > > >> > Maven deploy plugin [3] creates MD5 and SHA1 files automatically > > and > > > > >> > doesn't seem to have any options to tweak this behavior. > > > > >> > > > > > >> > That said, I have two questions: > > > > >> > > > > > >> >1. Are we required to use SHA512 or MD5/SHA1 is OK for now? > > > > >> >2. Is there a painless way to include SHA512 in addition to > > > > >> > MD5/SHA1? > > > > >> > > > > > >> > Can anyone shed some light on this? > > > > >> > > > > > >> > [1] https://infra.apache.org/release-signing.html#basic-facts > > > > >> > [2] > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ > > > > >> > [3] > > > > >> > > https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > > > >> > > > > > >> > -Val > > > > >> > > > > > >> > > > > >> > > > > >> -- > > > > >> Sincerely yours, > > > > >> Ivan Bessonov > > > > >> > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > -- Best regards, Andrey V. Mashenkov
Re: SHA-512 for Maven deployment
Andrey, This sounds even better. Can you create a ticket for this change? -Val On Wed, Jan 13, 2021 at 2:34 PM Andrey Mashenkov wrote: > Val, > > I've just found Maven projects use SHA-512. > I passed through commits and found they just switched to newer parent > org.apache:apache pom. > I've compared our current parent pom with the latest available one > (org.apache:apache:16 vs org.apache:apache:23) > and then found checksum-maven-plugin was added [1] somewhen in between. > > So, seems we have to switched to newer apache pom and maybe add > checksum-maven-plugin > to our main pom. > > [1] > > https://github.com/apache/maven-apache-parent/commit/a46aa52b4b56d9b7aa62e1b8cbea5ff0af434a > > On Wed, Jan 13, 2021 at 10:41 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Hi Andrey, > > > > This indeed sounds like the cleanest way. I don't know how much effort > that > > would be though. > > > > -Val > > > > On Wed, Jan 13, 2021 at 11:01 AM Andrey Mashenkov < > > andrey.mashen...@gmail.com> wrote: > > > > > Maybe, we could donate to maven plugin possibility to switch to > SHA-512. > > > Hopefully, a new plugin version will be released before we have any > > release > > > candidate. > > > > > > Is it looks like a big deal? > > > > > > ср, 13 янв. 2021 г., 21:32 Valentin Kulichenko < > > > valentin.kuliche...@gmail.com>: > > > > > > > Hi Ivan, > > > > > > > > No, I haven't found a way yet. SHA1 still works, but I believe we > > should > > > > consider using better options in future releases. > > > > > > > > Do you have any ideas on how to implement this? > > > > > > > > -Val > > > > > > > > On Wed, Jan 13, 2021 at 8:21 AM Ivan Pavlukhin > > > > wrote: > > > > > > > > > Folks, > > > > > > > > > > Were you able to resolve this? > > > > > > > > > > 2020-12-28 22:15 GMT+03:00, Valentin Kulichenko < > > > > > valentin.kuliche...@gmail.com>: > > > > > > Hi Ivan, > > > > > > > > > > > > Thanks for your response. I've looked into the PGP plugin, and > > > > > > unfortunately it looks like it only can create signatures, but > not > > > > > > checksums. > > > > > > > > > > > > -Val > > > > > > > > > > > > On Sun, Dec 27, 2020 at 11:54 PM Ivan Bessonov < > > > bessonov...@gmail.com> > > > > > > wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> I've never done this before, but it seems like we need > > > > maven-gpg-plugin > > > > > >> for > > > > > >> it [1]. > > > > > >> > > > > > >> Algorithm configuration would look like this: > > > > > >> > > > > > >> --digest-algo=SHA512 > > > > > >> > > > > > >> > > > > > >> Maybe this will help. > > > > > >> > > > > > >> [1] > > > > > >> > > > > > >> > > > > > > > > > > > > > > > http://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/sign-mojo.html > > > > > >> > > > > > >> пн, 28 дек. 2020 г. в 01:25, Valentin Kulichenko < > > > > > >> valentin.kuliche...@gmail.com>: > > > > > >> > > > > > >> > Igniters, > > > > > >> > > > > > > >> > I've been preparing the 3.0.0-alpha1 release and got confused > > > about > > > > > the > > > > > >> > requirements for checksums in Maven deployments. The Apache > > > > > instruction > > > > > >> [1] > > > > > >> > states that MD5 is deprecated and SHA1 should be avoided in > > favor > > > of > > > > > >> > SHA-256 or SHA-512. However, it looks like we are still using > > the > > > > > >> MD5/SHA1 > > > > > >> > combination (at least that's what the staging for 2.9.1 [2] > > > > contains). > > > > > >> > > > > > > >> > On top of that, I can't find an easy way to switch to another > > > > checksum > > > > > >> > - > > > > > >> > Maven deploy plugin [3] creates MD5 and SHA1 files > automatically > > > and > > > > > >> > doesn't seem to have any options to tweak this behavior. > > > > > >> > > > > > > >> > That said, I have two questions: > > > > > >> > > > > > > >> >1. Are we required to use SHA512 or MD5/SHA1 is OK for now? > > > > > >> >2. Is there a painless way to include SHA512 in addition to > > > > > >> > MD5/SHA1? > > > > > >> > > > > > > >> > Can anyone shed some light on this? > > > > > >> > > > > > > >> > [1] https://infra.apache.org/release-signing.html#basic-facts > > > > > >> > [2] > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ > > > > > >> > [3] > > > > > >> > > > https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html > > > > > >> > > > > > > >> > -Val > > > > > >> > > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> Sincerely yours, > > > > > >> Ivan Bessonov > > > > > >> > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > -- > Best regards, > Andrey V. Mashenkov >
[jira] [Created] (IGNITE-13983) Provide the ability to collect CQ performance statistics
Amelchev Nikita created IGNITE-13983: Summary: Provide the ability to collect CQ performance statistics Key: IGNITE-13983 URL: https://issues.apache.org/jira/browse/IGNITE-13983 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Assignee: Amelchev Nikita Provide the ability to collect CQ performance statistics -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13984) Provide the ability to collect Services performance statistics
Amelchev Nikita created IGNITE-13984: Summary: Provide the ability to collect Services performance statistics Key: IGNITE-13984 URL: https://issues.apache.org/jira/browse/IGNITE-13984 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Assignee: Amelchev Nikita Provide the ability to collect Services performance statistics -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite Extensions TeamCity project
Added you to Ignite Test Managers. Please check access level. > On 13 Jan 2021, at 03:49, Saikat Maitra wrote: > > Hi Petr, > > Thank you for your response. I am not able to access the project due to > error > > "You do not have enough permissions to access project with id > IgniteExtensions_Tests" > > Can you please provide me access? My username is samaitra > > Regards, > Saikat > > On Mon, Jan 11, 2021 at 2:55 AM Petr Ivanov wrote: > >> Hi. >> >> >> I've refactored the hierarchy of the project and moved it here: >> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds < >> https://ci.ignite.apache.org/project/IgniteExtensions_Tests?mode=builds> >> Check your permissions, please. >> >>> On 11 Jan 2021, at 01:01, Saikat Maitra wrote: >>> >>> Hi, >>> >>> We had a project for IgniteExtensions under Tests main project in >> TeamCity. >>> >>> >> https://ci.ignite.apache.org/project.html?projectId=Tests_IgniteExtensions >>> >>> I am no longer able to access the IgniteExtensions project. >>> >>> Was it refactored and moved to another location? >>> >>> Regards, >>> Saikat >> >>
Re: [DISCUSSION] .Net BinaryTypes transparency
Hello, Pavel
My proposal is the following:
*When Ignite configured with FQN NameMapper.*
And user invokes
1. Service method from .Net to Java.
2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync`
3. Cache operations.
Ignite should implicitly register types both for .Net and Java platform.
=
My intentions is to simplify usage of the Ignite .Net platform by eliminating
necessity of BinaryConfiguration in .Net.
Approach when user should modify Ignite configuration on both sides Java and
.Net every time he use new class as a service parameter looks ugly, for me.
You can see an example of my idea in services test [1]
In current release, user forced to enlist each type in configuration.
Now, you just deploy Java service and use it.
Please, Note:
1. FQN NameMapper is a default value.
2. FQN NameMapper requires from the user to have exactly same names for custom
binary types in Java and .Net.
3. Improvals for Services in master, already.
[1]
https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Services/ServiceTypeAutoResolveTest.cs#L146
> 13 янв. 2021 г., в 10:13, Pavel Tupitsyn написал(а):
>
> Nikolay,
>
> As I understand, you insist on changing the default behavior, is this
> correct?
>
>
> On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov wrote:
>
>> Hello, Igor, Pavel.
>>
>> Thanks for the feedback
>>
>>> Agree with Pavel, this should be disabled by default.
>>
>> Right now, Ignite, by default, forcing users to enlist every single value
>> object they have in project in the config.
>> Do you think it’s a right way to go?
>>
>>> To me it looks pretty dangerous as users do not explicitly control
>> what’s going to be registered and it could lead to hard-to-debug mistakes
>> when wrong classes get registered or with wrong names.
>>
>> Approach with transparent type registration implemented in every RPC
>> framework I know.
>> I think user expect it from the modern software.
>> Can you, please, highlight dangerous part of the approach?
>>
>>> Wouldn't
>>> it be more reasonable to only register those which are used with Java
>>> services?
>>
>> Correct. Will do it.
>>
>>> Registering every .NET type as a Java type can lead to typeId collisions
>> and break existing user code,
>>
>> For Service and Compute API binary type registration both in Java and .Net
>> will happen anyway.
>> It’s required just to get things work.
>>
>>> 12 янв. 2021 г., в 20:31, Igor Sapego написал(а):
>>>
>>> Agree with Pavel, this should be disabled by default.
>>>
>>> To me it looks pretty dangerous as users do not explicitly control what's
>>> going to be
>>> registered and it could lead to hard-to-debug mistakes when wrong classes
>>> get
>>> registered or with wrong names. Also it can be hard to use with classes
>>> that should
>>> not be registered at all, which is often the case because not everyone
>> use
>>> .NET client
>>> with Java services.
>>>
>>> To me it looks familiar to another of our features - peer class loading,
>>> which is disabled
>>> by default for similar reasons.
>>>
>>> Also, why register types which are used as method arguments for any
>>> service? Wouldn't
>>> it be more reasonable to only register those which are used with Java
>>> services?
>>>
>>> Best Regards,
>>> Igor
>>>
>>>
>>> On Tue, Jan 12, 2021 at 7:35 PM Pavel Tupitsyn
>> wrote:
>>>
Nikolay,
I think this behavior should be opt-in - let's add a flag to
BinaryConfiguration.
Registering every .NET type as a Java type can lead to typeId collisions
and break existing user code,
so we can't enable this by default.
Ignite stores typeId -> className mappings separately for Java and .NET
[1].
Separate maps were introduced because C# and Java have different naming
conventions,
typically you have org.foo.bar.Person in Java and Foo.Bar.Person in
>> .NET,
so we allow the users to map two different type names to the same typeId
with a custom name or id mapper.
This proposal says we should always put Foo.Bar.Person from .NET to the
Java mapping,
in the hope that there is a class with that name in Java, which is a
>> very
rare use case.
[1]
org.apache.ignite.internal.MarshallerContextImpl#registerClassName(byte,
int, java.lang.String, boolean)
On Tue, Jan 12, 2021 at 4:56 PM Nikolay Izhikov
wrote:
> Hello, Igniters.
>
> Currently, in case of usage .Net platform client it’s required for the
> user to explicitly register each custom type.
>
> ```
> _marsh = new Marshaller(new BinaryConfiguration
> {
> TypeConfigurations = new List
> {
> new BinaryTypeConfiguration(typeof (Address)),
> new BinaryTypeConfiguration(typeof (TestModel))
> }
> });
> ```
>
> Note, we have a special public interface to map java type to .net
>> types -
>
[jira] [Created] (IGNITE-13985) C++: Continuous Queries should fail to register if remote filter is in C++ and there are non-C++ affinity nodes
Stanislav Lukyanov created IGNITE-13985: --- Summary: C++: Continuous Queries should fail to register if remote filter is in C++ and there are non-C++ affinity nodes Key: IGNITE-13985 URL: https://issues.apache.org/jira/browse/IGNITE-13985 Project: Ignite Issue Type: Improvement Reporter: Stanislav Lukyanov See https://issues.apache.org/jira/browse/IGNITE-6800. Currently, if there is a pure Java node in the cluster and a CQ is being registered from C++, the C++ remote filter will just be ignored on the pure Java node leading to unexpected CQ notifications. Need to add a validation to prevent incorrect results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] .Net BinaryTypes transparency
> Classes MUST be registered to be used in compute or cache. Yes, but they are registered separately for .NET and Java, please see how MarshallerContextImpl stores typeId->typeName mappings. With the proposal we put all class names in the same pile. Now imagine that the user has a cluster with C# and Java clients. C# client uses class "foo.bar.Aa" for Compute, Java client uses class "foo.bar.BB" for Services - independent use cases, all is well. As soon as we put all class names in the same map, the app breaks, because "foo.bar.Aa" and "foo.bar.BB" have the same hash code, and DuplicateTypeIdException is thrown by Ignite. On Wed, Jan 13, 2021 at 1:54 PM Nikolay Izhikov wrote: > Hello, Pavel. > > > Imagine that some Ignite user has lots of .NET and Java classes being > stored in cache, used in compute, > > Classes MUST be registered to be used in compute or cache. > So, in your example, user registered classes by hand, already. > > > Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, > > We already have this «flag». > It a default INameMapper implementation that assumes we use the same class > names both in Java and .Net. > > > This is not up for discussion, we do not break compatibility like this. > > Sorry, I don’t see compatibility issues in the proposal. > Can you, please, provide an example? > > > 13 янв. 2021 г., в 13:46, Pavel Tupitsyn > написал(а): > > > > Nikolay, > > > > I agree with your proposal, with one addition: > > this behavior must be disabled by default for compatibility reasons. > > > > Imagine that some Ignite user has lots of .NET and Java classes being > > stored in cache, > > used in compute, etc. Now with the proposal implemented, all .NET classes > > are registered > > as Java classes too, which has a potential for hash code collisions, > > resulting in DuplicateTypeIdException. > > > > So the user can't upgrade to 2.11, their app does not work anymore, which > > is not acceptable. > > This is not up for discussion, we do not break compatibility like this. > > > > Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, > > which enables the behavior globally and both ways: > > all type names become shared across all platforms in > MarshallerContextImpl. > > > > > > On Wed, Jan 13, 2021 at 11:21 AM Nikolay Izhikov > > wrote: > > > >> Hello, Pavel > >> > >> My proposal is the following: > >> > >> *When Ignite configured with FQN NameMapper.* > >> And user invokes > >> > >> 1. Service method from .Net to Java. > >> 2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync` > >> 3. Cache operations. > >> > >> Ignite should implicitly register types both for .Net and Java platform. > >> > >> = > >> My intentions is to simplify usage of the Ignite .Net platform by > >> eliminating necessity of BinaryConfiguration in .Net. > >> > >> Approach when user should modify Ignite configuration on both sides Java > >> and .Net every time he use new class as a service parameter looks ugly, > for > >> me. > >> > >> You can see an example of my idea in services test [1] > >> In current release, user forced to enlist each type in configuration. > >> Now, you just deploy Java service and use it. > >> > >> Please, Note: > >> > >> 1. FQN NameMapper is a default value. > >> 2. FQN NameMapper requires from the user to have exactly same names for > >> custom binary types in Java and .Net. > >> 3. Improvals for Services in master, already. > >> > >> [1] > >> > https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Services/ServiceTypeAutoResolveTest.cs#L146 > >> > >>> 13 янв. 2021 г., в 10:13, Pavel Tupitsyn > >> написал(а): > >>> > >>> Nikolay, > >>> > >>> As I understand, you insist on changing the default behavior, is this > >>> correct? > >>> > >>> > >>> On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov > >> wrote: > >>> > Hello, Igor, Pavel. > > Thanks for the feedback > > > Agree with Pavel, this should be disabled by default. > > Right now, Ignite, by default, forcing users to enlist every single > >> value > object they have in project in the config. > Do you think it’s a right way to go? > > > To me it looks pretty dangerous as users do not explicitly control > what’s going to be registered and it could lead to hard-to-debug > >> mistakes > when wrong classes get registered or with wrong names. > > Approach with transparent type registration implemented in every RPC > framework I know. > I think user expect it from the modern software. > Can you, please, highlight dangerous part of the approach? > > > Wouldn't > > it be more reasonable to only register those which are used with Java > > services? > > Correct. Will do it. > > > Registering every .NET type as a Java type can lead to typeId > >> collisions > and break existing user code, > > For Service and Compute API binary type
[jira] [Created] (IGNITE-13986) Proof of concept - SWIM group membership protocol for discovery
Ivan Bessonov created IGNITE-13986: -- Summary: Proof of concept - SWIM group membership protocol for discovery Key: IGNITE-13986 URL: https://issues.apache.org/jira/browse/IGNITE-13986 Project: Ignite Issue Type: New Feature Reporter: Ivan Bessonov Assignee: Ivan Bessonov In IEP-61 it is mentioned that discovery protocol will be updated. We need to play with mentioned options for a little bit to conclude if they match our needs: [http://www.cs.cornell.edu/Info/Projects/Spinglass/public_pdfs/SWIM.pdf] [https://github.com/scalecube/scalecube-cluster] -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] .Net BinaryTypes transparency
Hello, Pavel. > Imagine that some Ignite user has lots of .NET and Java classes being stored > in cache, used in compute, Classes MUST be registered to be used in compute or cache. So, in your example, user registered classes by hand, already. > Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, We already have this «flag». It a default INameMapper implementation that assumes we use the same class names both in Java and .Net. > This is not up for discussion, we do not break compatibility like this. Sorry, I don’t see compatibility issues in the proposal. Can you, please, provide an example? > 13 янв. 2021 г., в 13:46, Pavel Tupitsyn написал(а): > > Nikolay, > > I agree with your proposal, with one addition: > this behavior must be disabled by default for compatibility reasons. > > Imagine that some Ignite user has lots of .NET and Java classes being > stored in cache, > used in compute, etc. Now with the proposal implemented, all .NET classes > are registered > as Java classes too, which has a potential for hash code collisions, > resulting in DuplicateTypeIdException. > > So the user can't upgrade to 2.11, their app does not work anymore, which > is not acceptable. > This is not up for discussion, we do not break compatibility like this. > > Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, > which enables the behavior globally and both ways: > all type names become shared across all platforms in MarshallerContextImpl. > > > On Wed, Jan 13, 2021 at 11:21 AM Nikolay Izhikov > wrote: > >> Hello, Pavel >> >> My proposal is the following: >> >> *When Ignite configured with FQN NameMapper.* >> And user invokes >> >> 1. Service method from .Net to Java. >> 2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync` >> 3. Cache operations. >> >> Ignite should implicitly register types both for .Net and Java platform. >> >> = >> My intentions is to simplify usage of the Ignite .Net platform by >> eliminating necessity of BinaryConfiguration in .Net. >> >> Approach when user should modify Ignite configuration on both sides Java >> and .Net every time he use new class as a service parameter looks ugly, for >> me. >> >> You can see an example of my idea in services test [1] >> In current release, user forced to enlist each type in configuration. >> Now, you just deploy Java service and use it. >> >> Please, Note: >> >> 1. FQN NameMapper is a default value. >> 2. FQN NameMapper requires from the user to have exactly same names for >> custom binary types in Java and .Net. >> 3. Improvals for Services in master, already. >> >> [1] >> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Services/ServiceTypeAutoResolveTest.cs#L146 >> >>> 13 янв. 2021 г., в 10:13, Pavel Tupitsyn >> написал(а): >>> >>> Nikolay, >>> >>> As I understand, you insist on changing the default behavior, is this >>> correct? >>> >>> >>> On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov >> wrote: >>> Hello, Igor, Pavel. Thanks for the feedback > Agree with Pavel, this should be disabled by default. Right now, Ignite, by default, forcing users to enlist every single >> value object they have in project in the config. Do you think it’s a right way to go? > To me it looks pretty dangerous as users do not explicitly control what’s going to be registered and it could lead to hard-to-debug >> mistakes when wrong classes get registered or with wrong names. Approach with transparent type registration implemented in every RPC framework I know. I think user expect it from the modern software. Can you, please, highlight dangerous part of the approach? > Wouldn't > it be more reasonable to only register those which are used with Java > services? Correct. Will do it. > Registering every .NET type as a Java type can lead to typeId >> collisions and break existing user code, For Service and Compute API binary type registration both in Java and >> .Net will happen anyway. It’s required just to get things work. > 12 янв. 2021 г., в 20:31, Igor Sapego написал(а): > > Agree with Pavel, this should be disabled by default. > > To me it looks pretty dangerous as users do not explicitly control >> what's > going to be > registered and it could lead to hard-to-debug mistakes when wrong >> classes > get > registered or with wrong names. Also it can be hard to use with classes > that should > not be registered at all, which is often the case because not everyone use > .NET client > with Java services. > > To me it looks familiar to another of our features - peer class >> loading, > which is disabled > by default for similar reasons. > > Also, why register types which are used as method arguments for any >
Re: [DISCUSSION] 3.0.0 Alpha release
Val, Igniters, I thought about possible results of such release. How do we expect to receive feedback? It would be interesting personally for me to see feedback/results summary. 2021-01-01 2:59 GMT+03:00, Valentin Kulichenko : > Igniters, > > Big thanks to everyone involved in the preparation for this alpha release! > > Throughout this week, the current codebase has been tested on Linux and > Windows, all the major issues have been resolved, and the Getting Started > guide has been created. We're now ready for the vote - I will start it > sometime during the weekend or early next week. > > Happy New Year everyone! > > -Val > > On Thu, Dec 31, 2020 at 3:03 AM Fedor Malchikov > wrote: > >> Hi Valentin, >> >> Yes, of course. >> I closed tickets for fixed issues and created a few more new ones. >> >> On Thu, Dec 31, 2020 at 8:57 AM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >> > Hi Fedor, >> > >> > Thanks again - you're really helping to improve the quality of the >> release. >> > >> > I've fixed everything except for the progress bar issue - should not be >> > a >> > blocker though, I will move it outside of the alpha if I do not succeed >> by >> > the end of tomorrow. >> > >> > Can you please verify that other issues are fixed (especially >> > IGNITE-13936)? Here is the new staging: >> > https://repository.apache.org/content/repositories/orgapacheignite-1500/ >> > >> > -Val >> > >> > On Wed, Dec 30, 2020 at 5:31 AM Fedor Malchikov >> > > > >> > wrote: >> > >> > > Hi Valentin, >> > > I looked at the resources available on staging and found a number of >> > > additional issues: >> > > One blocker: >> > > https://issues.apache.org/jira/browse/IGNITE-13936 >> > > and three minor: >> > > https://issues.apache.org/jira/browse/IGNITE-13938 >> > > https://issues.apache.org/jira/browse/IGNITE-13937 >> > > https://issues.apache.org/jira/browse/IGNITE-13939 >> > > >> > > On Mon, Dec 28, 2020 at 10:24 PM Valentin Kulichenko < >> > > valentin.kuliche...@gmail.com> wrote: >> > > >> > > > I've also noticed that there is functionality allowing to use >> > > > custom >> > > Maven >> > > > repositories. However, it is available only for the 'module add' >> > command, >> > > > but not for the 'init' command. Created a ticket for this as well: >> > > > https://issues.apache.org/jira/browse/IGNITE-13923 >> > > > >> > > > -Val >> > > > >> > > > On Mon, Dec 28, 2020 at 11:21 AM Valentin Kulichenko < >> > > > valentin.kuliche...@gmail.com> wrote: >> > > > >> > > > > Hi Fedor, >> > > > > >> > > > > Thanks for doing this! >> > > > > >> > > > > Regarding IGNITE-13921: in the first version, the tool created >> > > > > the >> > > > folders >> > > > > in the current directory, which created unpredictable behavior, >> > > > > so >> we >> > > > > switched to home as default. However, using the folder where the >> tool >> > > is >> > > > > located instead of the home folder seems fair - I've included the >> > > ticket >> > > > > into the alpha1. Also, note that in the next versions, there will >> be >> > an >> > > > > option to customize the paths, so the user will not have to rely >> > > > > on >> > > > default >> > > > > values. >> > > > > >> > > > > If you don't mind, I suggest to postpone other issues for further >> > > > > development - they do not look so critical. >> > > > > >> > > > > -Val >> > > > > >> > > > > On Mon, Dec 28, 2020 at 9:45 AM Fedor Malchikov < >> > > fmalchi...@gridgain.com >> > > > > >> > > > > wrote: >> > > > > >> > > > >> Hello everyone, >> > > > >> I smoke tested the alpha version of the CLI tool on ubuntu and >> > > windows. >> > > > So >> > > > >> I found the following issues: >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13914 >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13924 >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13921 >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13922 >> > > > >> https://issues.apache.org/jira/browse/IGNITE-13920 >> > > > >> >> > > > >> >> > > > >> On Sun, Dec 27, 2020 at 2:18 AM Valentin Kulichenko < >> > > > >> valentin.kuliche...@gmail.com> wrote: >> > > > >> >> > > > >> > Folks, >> > > > >> > >> > > > >> > I've created a version in Jira and a Wiki page for the alpha >> > > release: >> > > > >> > >> > > > >> > >> > > > >> >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0.0-alpha1 >> > > > >> > >> > > > >> > Based on the scope described earlier, all code changes are >> > > completed - >> > > > >> only >> > > > >> > documentation is left. Code freeze starts now - only bug fixes >> are >> > > > >> > permitted. >> > > > >> > >> > > > >> > I'm planning to start the vote next week, presumably on >> > > > >> > Tuesday. >> > > > >> > >> > > > >> > -Val >> > > > >> > >> > > > >> > On Tue, Dec 22, 2020 at 9:56 AM Valentin Kulichenko < >> > > > >> > valentin.kuliche...@gmail.com> wrote: >> > > > >> > >> > > > >> > > Ivan, >> > > > >> > > >> > > > >> > > Yes, you are correct -
Re: [DISCUSSION] .Net BinaryTypes transparency
Nikolay, I agree with your proposal, with one addition: this behavior must be disabled by default for compatibility reasons. Imagine that some Ignite user has lots of .NET and Java classes being stored in cache, used in compute, etc. Now with the proposal implemented, all .NET classes are registered as Java classes too, which has a potential for hash code collisions, resulting in DuplicateTypeIdException. So the user can't upgrade to 2.11, their app does not work anymore, which is not acceptable. This is not up for discussion, we do not break compatibility like this. Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, which enables the behavior globally and both ways: all type names become shared across all platforms in MarshallerContextImpl. On Wed, Jan 13, 2021 at 11:21 AM Nikolay Izhikov wrote: > Hello, Pavel > > My proposal is the following: > > *When Ignite configured with FQN NameMapper.* > And user invokes > > 1. Service method from .Net to Java. > 2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync` > 3. Cache operations. > > Ignite should implicitly register types both for .Net and Java platform. > > = > My intentions is to simplify usage of the Ignite .Net platform by > eliminating necessity of BinaryConfiguration in .Net. > > Approach when user should modify Ignite configuration on both sides Java > and .Net every time he use new class as a service parameter looks ugly, for > me. > > You can see an example of my idea in services test [1] > In current release, user forced to enlist each type in configuration. > Now, you just deploy Java service and use it. > > Please, Note: > > 1. FQN NameMapper is a default value. > 2. FQN NameMapper requires from the user to have exactly same names for > custom binary types in Java and .Net. > 3. Improvals for Services in master, already. > > [1] > https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Services/ServiceTypeAutoResolveTest.cs#L146 > > > 13 янв. 2021 г., в 10:13, Pavel Tupitsyn > написал(а): > > > > Nikolay, > > > > As I understand, you insist on changing the default behavior, is this > > correct? > > > > > > On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov > wrote: > > > >> Hello, Igor, Pavel. > >> > >> Thanks for the feedback > >> > >>> Agree with Pavel, this should be disabled by default. > >> > >> Right now, Ignite, by default, forcing users to enlist every single > value > >> object they have in project in the config. > >> Do you think it’s a right way to go? > >> > >>> To me it looks pretty dangerous as users do not explicitly control > >> what’s going to be registered and it could lead to hard-to-debug > mistakes > >> when wrong classes get registered or with wrong names. > >> > >> Approach with transparent type registration implemented in every RPC > >> framework I know. > >> I think user expect it from the modern software. > >> Can you, please, highlight dangerous part of the approach? > >> > >>> Wouldn't > >>> it be more reasonable to only register those which are used with Java > >>> services? > >> > >> Correct. Will do it. > >> > >>> Registering every .NET type as a Java type can lead to typeId > collisions > >> and break existing user code, > >> > >> For Service and Compute API binary type registration both in Java and > .Net > >> will happen anyway. > >> It’s required just to get things work. > >> > >>> 12 янв. 2021 г., в 20:31, Igor Sapego написал(а): > >>> > >>> Agree with Pavel, this should be disabled by default. > >>> > >>> To me it looks pretty dangerous as users do not explicitly control > what's > >>> going to be > >>> registered and it could lead to hard-to-debug mistakes when wrong > classes > >>> get > >>> registered or with wrong names. Also it can be hard to use with classes > >>> that should > >>> not be registered at all, which is often the case because not everyone > >> use > >>> .NET client > >>> with Java services. > >>> > >>> To me it looks familiar to another of our features - peer class > loading, > >>> which is disabled > >>> by default for similar reasons. > >>> > >>> Also, why register types which are used as method arguments for any > >>> service? Wouldn't > >>> it be more reasonable to only register those which are used with Java > >>> services? > >>> > >>> Best Regards, > >>> Igor > >>> > >>> > >>> On Tue, Jan 12, 2021 at 7:35 PM Pavel Tupitsyn > >> wrote: > >>> > Nikolay, > > I think this behavior should be opt-in - let's add a flag to > BinaryConfiguration. > Registering every .NET type as a Java type can lead to typeId > collisions > and break existing user code, > so we can't enable this by default. > > > Ignite stores typeId -> className mappings separately for Java and > .NET > [1]. > Separate maps were introduced because C# and Java have different > naming > conventions, > typically you have org.foo.bar.Person in Java and Foo.Bar.Person in > >> .NET, >
[jira] [Created] (IGNITE-13987) Improve dependencies management.
Andrey Mashenkov created IGNITE-13987: - Summary: Improve dependencies management. Key: IGNITE-13987 URL: https://issues.apache.org/jira/browse/IGNITE-13987 Project: Ignite Issue Type: Improvement Components: build Reporter: Andrey Mashenkov Let's avoid hardcoded dependency versions in module pom files and use properties for versions as it is done Ignite 2.x. As more than one module can have same dependency, the proper place to define versions is the parent pom. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13988) Version dropdown on docs is not aligned to the right on Safari
Mauricio Stekl created IGNITE-13988: --- Summary: Version dropdown on docs is not aligned to the right on Safari Key: IGNITE-13988 URL: https://issues.apache.org/jira/browse/IGNITE-13988 Project: Ignite Issue Type: Bug Components: website Reporter: Mauricio Stekl Assignee: Mauricio Stekl Attachments: Screen Shot 2021-01-13 at 11.10.04.png This can be reproduced only on Safari. Basically caused because 'text-align-last' doesn't work on this browser. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [COMMUNITY] Recognizing those who contribute to user support and project awareness
Hi Ksenia, Folks, Thank you for providing this information, and thank all of you for your contributions. Speaking about how the community recognizes these efforts, it's pretty much up to PMC to decide. There is nothing in Apache policies that says that you should contribute code to be invited to be Committer/PMC. There are examples when the Apache Foundation itself invites non-technical folks to be members of the foundation. So we have a formal way to recognize it, feel free to start a discussion. I really looking forward to seeing new statistics for 2021, coz it is still important to mention, even if a community-champion is already a member of the PMC. Sincerely, Dmitriy Pavlov вт, 5 янв. 2021 г. в 03:50, Saikat Maitra : > Hi Kseniya, > > Much appreciate it. > > Thank you and Happy New Year! > > Regards, > Saikat > > On Wed, Dec 30, 2020 at 6:50 AM Ivan Pavlukhin > wrote: > > > Great news! Thanks and Happy holidays! > > > > 2020-12-30 12:10 GMT+03:00, Alexey Zinoviev : > > > Thanks for recognition! Happy New Year! > > > > > > вт, 29 дек. 2020 г. в 21:36, Kseniya Romanova < > romanova.ks@gmail.com > > >: > > > > > >> Hi, Igniters! > > >> > > >> > > >> ASF welcomes all types of contributions, including responses to user > > >> questions and promotion of projects. And, the GriGain DelRel team > knows > > >> that people spend a lot of their private time on such activities. Our > > >> code > > >> and documentation contributors are recognized by being promoted to the > > >> role > > >> of " committer." But, unfortunately, we don't have a formal way to > > >> recognize our user-support and project-promotion contributors. > > >> > > >> > > >> In 2020, more than 40 people contributed their time and experience to > > >> promote project visibility and encourage adoption by developers: > > >> > > >> > > >> > > >>- > > >> > > >>59 talks to 2400 developers and architects at meetup and conference > > >>events > > >>- > > >> > > >>60+ blog posts and tutorials > > >>- > > >> > > >>2000+ questions answered on the User list and Stackoverflow > > >> > > >> > > >> Let’s praise some of our most active Ignite supporters in 2020: > > >> > > >> > > >> > > >>- > > >> > > >>In user support, Ilya Kasnacheev is our absolute user support > > >> champion. > > >>He alone answered 756 questions on Stackoverflow and the User list. > > >>- > > >> > > >>Val Kulichenko posted 9 articles and presented at 6 meetups. > > >>- > > >> > > >>Denis Magda created 10 demos and 4 tutorials and presented at 14 > > >> meetups > > >>and 7 conferences. > > >>- > > >> > > >>Alexey Zinoviev wrote 4 articles about Ignite ML and presented at 1 > > >>meetup and 1 conference. > > >>- > > >> > > >>Pavel Tupitsyn created 4 articles and helped Ignite users on the > > >> mailing > > >>list and Stackoverflow. > > >>- > > >> > > >>Saikat Maitra presented at 2 conferences. > > >>- > > >> > > >>Ivan Pavlukhin helped many new developers to start contributing to > > >>Ignite. > > >> > > >> > > >> As a sign of our gratitude for their efforts, these contributors will > > >> receive special New Year gifts. > > >> > > >> > > >> In 2021, we want to track this type of contribution and ensure that > the > > >> contributors are recognized within the community. The Alfa version of > > our > > >> tracking system is already functioning inside GridGain, so the next > step > > >> is > > >> to upgrade the current system and start a discussion with PMC members. > > >> Those who help to attract and retain users are definitely worthy of > > >> praise > > >> and promotion, as the value of their contribution matches the value > that > > >> is > > >> provided through code and documentation. > > >> > > >> > > >> Keep being awesome and have a Happy New Year! > > >> > > >> > > >> Kseniya > > >> > > >> DevRel at GridGain > > >> > > > > > > > > > -- > > > > Best regards, > > Ivan Pavlukhin > > >
Re: [DISCUSSION] .Net BinaryTypes transparency
Pavel. > Yes, but they are registered separately for .NET and Java, please see how > MarshallerContextImpl stores typeId->typeName mappings. This will not change. We still will have separate type registration. > With the proposal we put all class names in the same pile. Implementation of type registration will not be changed. What I propose is to simplify user life in the exact places we can do it for free. > Now imagine that the user has a cluster with C# and Java clients. > C# client uses class "foo.bar.Aa" for Compute, > Java client uses class "foo.bar.BB" for Services - independent use cases, > all is well. I propose to implicitly register classes only in the case they are sent to the Java side. So, for all classes that is used only in .Net nothing will change. > 13 янв. 2021 г., в 15:14, Pavel Tupitsyn написал(а): > >> Classes MUST be registered to be used in compute or cache. > > Yes, but they are registered separately for .NET and Java, > please see how MarshallerContextImpl stores typeId->typeName mappings. > > With the proposal we put all class names in the same pile. > > Now imagine that the user has a cluster with C# and Java clients. > C# client uses class "foo.bar.Aa" for Compute, > Java client uses class "foo.bar.BB" for Services - independent use cases, > all is well. > > As soon as we put all class names in the same map, the app breaks, > because "foo.bar.Aa" and "foo.bar.BB" have the same hash code, > and DuplicateTypeIdException is thrown by Ignite. > > On Wed, Jan 13, 2021 at 1:54 PM Nikolay Izhikov wrote: > >> Hello, Pavel. >> >>> Imagine that some Ignite user has lots of .NET and Java classes being >> stored in cache, used in compute, >> >> Classes MUST be registered to be used in compute or cache. >> So, in your example, user registered classes by hand, already. >> >>> Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, >> >> We already have this «flag». >> It a default INameMapper implementation that assumes we use the same class >> names both in Java and .Net. >> >>> This is not up for discussion, we do not break compatibility like this. >> >> Sorry, I don’t see compatibility issues in the proposal. >> Can you, please, provide an example? >> >>> 13 янв. 2021 г., в 13:46, Pavel Tupitsyn >> написал(а): >>> >>> Nikolay, >>> >>> I agree with your proposal, with one addition: >>> this behavior must be disabled by default for compatibility reasons. >>> >>> Imagine that some Ignite user has lots of .NET and Java classes being >>> stored in cache, >>> used in compute, etc. Now with the proposal implemented, all .NET classes >>> are registered >>> as Java classes too, which has a potential for hash code collisions, >>> resulting in DuplicateTypeIdException. >>> >>> So the user can't upgrade to 2.11, their app does not work anymore, which >>> is not acceptable. >>> This is not up for discussion, we do not break compatibility like this. >>> >>> Let's add a flag like BinaryConfiguration.AssumeSameJavaTypeNames, >>> which enables the behavior globally and both ways: >>> all type names become shared across all platforms in >> MarshallerContextImpl. >>> >>> >>> On Wed, Jan 13, 2021 at 11:21 AM Nikolay Izhikov >>> wrote: >>> Hello, Pavel My proposal is the following: *When Ignite configured with FQN NameMapper.* And user invokes 1. Service method from .Net to Java. 2. Compute methods `ExecuteJavaTask`, `ExecuteJavaTaskAsync` 3. Cache operations. Ignite should implicitly register types both for .Net and Java platform. = My intentions is to simplify usage of the Ignite .Net platform by eliminating necessity of BinaryConfiguration in .Net. Approach when user should modify Ignite configuration on both sides Java and .Net every time he use new class as a service parameter looks ugly, >> for me. You can see an example of my idea in services test [1] In current release, user forced to enlist each type in configuration. Now, you just deploy Java service and use it. Please, Note: 1. FQN NameMapper is a default value. 2. FQN NameMapper requires from the user to have exactly same names for custom binary types in Java and .Net. 3. Improvals for Services in master, already. [1] >> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/Services/ServiceTypeAutoResolveTest.cs#L146 > 13 янв. 2021 г., в 10:13, Pavel Tupitsyn написал(а): > > Nikolay, > > As I understand, you insist on changing the default behavior, is this > correct? > > > On Tue, Jan 12, 2021 at 9:51 PM Nikolay Izhikov wrote: > >> Hello, Igor, Pavel. >> >> Thanks for the feedback >> >>> Agree with Pavel, this should be disabled by default. >> >> Right now, Ignite, by default, forcing
