[DISCUSSION] Shmem removal.
Hi, igniters. Recently I've discovered one fact 1. GridShmemCommunicationClient and all shmem functionality are broken since 2.10. In master it is broken since August 2020. And nobody have noticed it, only one thread in user list. 2. We have source code for native JNI library (that is shipped in ignite-shmem.jar), but we never built it since 2015. 3. This code is of questionable quality, contains outdated internal gcc api (__sync builtins, now deprecated in favour of __atomic builtins in gcc and is not advisable to use since C++ 11). It contains a lot of autotool mess, while just one CMakeFile.txt is enough to build the same 4. This code doesn't even compile on modern gcc (gcc 9.3.0 namely) We have 2 options 1. If this concept is useful, we (for example I can do it) should rewrite native part, a. Use C++ 11 and header-only boost.interprocess [1] b. Build it regularly with CMake and incorporate build in regular TC runs (via maven-cmake-plugin, see for example my numa-allocator [2]). 2. If this concept and functionality is not useful, we should remove it, may be even in 2.12 [1] -- https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess.html [2] -- https://github.com/apache/ignite/pull/9569/files#diff-77baf2378aa83911a8c3091814db3ff60b7bf328c4ab4850f707717ed96f3d92 -- Sincerely yours, Ivan Daschinskiy
Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x
So if nobody wants it to resurrect, maybe it is worth removing it? пт, 3 дек. 2021 г. в 09:25, Ivan Pavlukhin : > Latest that I heard that it literally was never in use. > > 2021-11-29 19:44 GMT+03:00, Ivan Daschinsky : > > There is JNI library in ipc/shmem directory. It even compiles with > minimal > > modification on modern gcc (9.3.0) > > But there is no script to build jar with native library. > > > > May be it is possible to create separate module, refactor it a bit, > change > > build process (CMake)? > > Is there a technical reason why it is abandoned? > > > > пн, 29 нояб. 2021 г. в 19:24, Ivan Daschinsky : > > > >> Guys, what is the status of ignite-shmem and TcpCommunication through > it? > >> > >> 1. Native part has not been built at all since 2015 > >> 2. It is currently broken in master -- I've fixed some NPE and metrics > >> conversion locally and it works for me. It is broken for almost a year. > >> 3. GridShmemCommunicationClient is not covered by tests. > >> > >> What do you think we should do with this? > >> > >> сб, 27 нояб. 2021 г. в 23:32, Vyacheslav Daradur : > >> > >>> LGTM. Merged to master. > >>> > >>> Thank you for your contribution! > >>> > >>> On Fri, Nov 26, 2021 at 12:20 PM Maxim Muzafarov > >>> wrote: > >>> > >>> > Folks, > >>> > > >>> > This is a friendly reminder :-) > >>> > PR [1] is ready for review. Will anyone take a look? > >>> > > >>> > [1] https://github.com/apache/ignite/pull/9577/files > >>> > > >>> > On Sat, 20 Nov 2021 at 03:17, Maxim Muzafarov > >>> wrote: > >>> > > > >>> > > Folks, > >>> > > > >>> > > > >>> > > I've prepared the changes related to the legacy Service Grid > removal > >>> > > for the 2.13 release. Here is the issue [1] and the PR [2] of these > >>> > > changes. > >>> > > > >>> > > Some important notes: > >>> > > > >>> > > - Removed GridServiceProcessor legacy implementation (internal) > >>> > > - The IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED system property > >>> > > was removed (this is a breaking change) > >>> > > - The ATTR_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED node attribute > was > >>> > > removed (this is a breaking change) > >>> > > - The node with 2.13 won't be able to connect to 2.12 (assume > Ignite > >>> > > services are used) > >>> > > > >>> > > The legacy test suite [3] will be removed after the [1] issue will > >>> > > be > >>> > merged. > >>> > > > >>> > > > >>> > > Who can take a look at this PR? > >>> > > > >>> > > > >>> > > [1] https://issues.apache.org/jira/browse/IGNITE-15758 > >>> > > [2] https://github.com/apache/ignite/pull/9577/files > >>> > > [3] > >>> > > >>> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode > >>> > > > >>> > > On Fri, 22 Oct 2021 at 12:43, Nikolay Izhikov > > >>> > wrote: > >>> > > > > >>> > > > Hello. > >>> > > > > >>> > > > In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the > >>> > following API are prepared: > >>> > > > > >>> > > > 1. MVCC > >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15757 > >>> > > > - https://github.com/apache/ignite/pull/9516 > >>> > > > > >>> > > > 2. LOCAL caches > >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15756 > >>> > > > - https://github.com/apache/ignite/pull/9515 > >>> > > > > >>> > > > 3. CacheConfiguration#rebalanceDelay > >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15764 > >>> > > > - https://github.com/apache/ignite/pull/9515 > >>> > > > > >>> > > > Please, review. > >>> > > > > >>> > > > > 15 окт. 2021 г., в 16:23, Nikolay Izhikov > >>> > > > > >>> > > >>> > написал(а): > >>> > > > > > >>> > > > > THanks, Maksim. > >>> > > > > > >>> > > > > Tickets included in IEP scope and marked for d in 2.12-2.13 > >>> > > > > > >>> > > > >> 15 окт. 2021 г., в 16:03, Maxim Muzafarov > >>> > написал(а): > >>> > > > >> > >>> > > > >> Let's deprecate RebalanceDelay and RebalanceMode=NONE also. > >>> > > > >> > >>> > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12662 > >>> > > > >> [2] https://issues.apache.org/jira/browse/IGNITE-14613 > >>> > > > >> > >>> > > > >> On Fri, 15 Oct 2021 at 15:46, Anton Vinogradov > > >>> > wrote: > >>> > > > >>> > >>> > > > >>> +1 > >>> > > > >>> > >>> > > > >>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev < > >>> > namelc...@apache.org> > >>> > > > >>> wrote: > >>> > > > >>> > >>> > > > +1 for deprecation in the 2.12 release > >>> > > > > >>> > > > пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov < > >>> nizhi...@apache.org > >>> > >: > >>> > > > > > >>> > > > > Hello, Igniters. > >>> > > > > > >>> > > > > I’ve prepared IEP-80 [1] to track breaking changes that > >>> > > > > should > >>> > be done > >>> > > > in Ignite 2.x. > >>> > > > > > >>> > > > > We agreed on the following algorithm to deal with breaking > >>> > changes: > >>> > > > > > >>> > > > > - Ignite 2.[x] - deprecate the API + notification of the > >>> users. > >>> > > > > -
Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x
Latest that I heard that it literally was never in use. 2021-11-29 19:44 GMT+03:00, Ivan Daschinsky : > There is JNI library in ipc/shmem directory. It even compiles with minimal > modification on modern gcc (9.3.0) > But there is no script to build jar with native library. > > May be it is possible to create separate module, refactor it a bit, change > build process (CMake)? > Is there a technical reason why it is abandoned? > > пн, 29 нояб. 2021 г. в 19:24, Ivan Daschinsky : > >> Guys, what is the status of ignite-shmem and TcpCommunication through it? >> >> 1. Native part has not been built at all since 2015 >> 2. It is currently broken in master -- I've fixed some NPE and metrics >> conversion locally and it works for me. It is broken for almost a year. >> 3. GridShmemCommunicationClient is not covered by tests. >> >> What do you think we should do with this? >> >> сб, 27 нояб. 2021 г. в 23:32, Vyacheslav Daradur : >> >>> LGTM. Merged to master. >>> >>> Thank you for your contribution! >>> >>> On Fri, Nov 26, 2021 at 12:20 PM Maxim Muzafarov >>> wrote: >>> >>> > Folks, >>> > >>> > This is a friendly reminder :-) >>> > PR [1] is ready for review. Will anyone take a look? >>> > >>> > [1] https://github.com/apache/ignite/pull/9577/files >>> > >>> > On Sat, 20 Nov 2021 at 03:17, Maxim Muzafarov >>> wrote: >>> > > >>> > > Folks, >>> > > >>> > > >>> > > I've prepared the changes related to the legacy Service Grid removal >>> > > for the 2.13 release. Here is the issue [1] and the PR [2] of these >>> > > changes. >>> > > >>> > > Some important notes: >>> > > >>> > > - Removed GridServiceProcessor legacy implementation (internal) >>> > > - The IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED system property >>> > > was removed (this is a breaking change) >>> > > - The ATTR_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED node attribute was >>> > > removed (this is a breaking change) >>> > > - The node with 2.13 won't be able to connect to 2.12 (assume Ignite >>> > > services are used) >>> > > >>> > > The legacy test suite [3] will be removed after the [1] issue will >>> > > be >>> > merged. >>> > > >>> > > >>> > > Who can take a look at this PR? >>> > > >>> > > >>> > > [1] https://issues.apache.org/jira/browse/IGNITE-15758 >>> > > [2] https://github.com/apache/ignite/pull/9577/files >>> > > [3] >>> > >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode >>> > > >>> > > On Fri, 22 Oct 2021 at 12:43, Nikolay Izhikov >>> > wrote: >>> > > > >>> > > > Hello. >>> > > > >>> > > > In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the >>> > following API are prepared: >>> > > > >>> > > > 1. MVCC >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15757 >>> > > > - https://github.com/apache/ignite/pull/9516 >>> > > > >>> > > > 2. LOCAL caches >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15756 >>> > > > - https://github.com/apache/ignite/pull/9515 >>> > > > >>> > > > 3. CacheConfiguration#rebalanceDelay >>> > > > - https://issues.apache.org/jira/browse/IGNITE-15764 >>> > > > - https://github.com/apache/ignite/pull/9515 >>> > > > >>> > > > Please, review. >>> > > > >>> > > > > 15 окт. 2021 г., в 16:23, Nikolay Izhikov >>> > > > > >> > >>> > написал(а): >>> > > > > >>> > > > > THanks, Maksim. >>> > > > > >>> > > > > Tickets included in IEP scope and marked for d in 2.12-2.13 >>> > > > > >>> > > > >> 15 окт. 2021 г., в 16:03, Maxim Muzafarov >>> > написал(а): >>> > > > >> >>> > > > >> Let's deprecate RebalanceDelay and RebalanceMode=NONE also. >>> > > > >> >>> > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12662 >>> > > > >> [2] https://issues.apache.org/jira/browse/IGNITE-14613 >>> > > > >> >>> > > > >> On Fri, 15 Oct 2021 at 15:46, Anton Vinogradov >>> > wrote: >>> > > > >>> >>> > > > >>> +1 >>> > > > >>> >>> > > > >>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev < >>> > namelc...@apache.org> >>> > > > >>> wrote: >>> > > > >>> >>> > > > +1 for deprecation in the 2.12 release >>> > > > >>> > > > пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov < >>> nizhi...@apache.org >>> > >: >>> > > > > >>> > > > > Hello, Igniters. >>> > > > > >>> > > > > I’ve prepared IEP-80 [1] to track breaking changes that >>> > > > > should >>> > be done >>> > > > in Ignite 2.x. >>> > > > > >>> > > > > We agreed on the following algorithm to deal with breaking >>> > changes: >>> > > > > >>> > > > > - Ignite 2.[x] - deprecate the API + notification of the >>> users. >>> > > > > - Ignite 2.[x+1] - API removal. >>> > > > > >>> > > > > >>> > > > > I propose to start these improvements with the d >>> (depuration & >>> > > > removal) of the following features: >>> > > > > >>> > > > > - LOCAL caches >>> > > > > - MVCC caches >>> > > > > - legacy service grid implementation >>> > > > > - legacy JMX metrics beans. >>> > > > > >>> > > > >
Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]
I would like to formally announce code freeze for 2.12.0. Only blockers are accepted to be included to the scope. [1] We have one blocker issue [2] that will be fixed soon. [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P3.Stabilization [2] https://issues.apache.org/jira/browse/IGNITE-15966 чт, 2 дек. 2021 г. в 16:01, Nikita Amelchev : > > Hi, Igniters. > > The release is blocked by the auth issue [1] discussed above. The > patch will be prepared at the nearest time. > > I want to include the useful issue that adds the ability to configure > snapshot thread pool size if nobody minds. > > [1] https://issues.apache.org/jira/browse/IGNITE-15966 > [2] https://issues.apache.org/jira/browse/IGNITE-16014 > > пт, 26 нояб. 2021 г. в 11:44, Nikita Amelchev : > > > > Hello, > > > > I want to include the issue [1] to the 2.12 scope. It fixes some > > metrics according to the JSR107. > > > > Any objections? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-16002 The remove > > cache method should update statistics if the method returns true > > > > чт, 25 нояб. 2021 г. в 17:12, Nikita Amelchev : > > > > > > Hello Ivan, > > > > > > +1, the issue can be cherry-picked to the 2.12. > > > > > > чт, 25 нояб. 2021 г. в 17:07, Ivan Bessonov : > > > > > > > > Hello everyone, > > > > > > > > is there a chance to add this issue to the release scope? [1] > > > > Currently, defragmentation of certain types of indexes can corrupt them. > > > > Fix is straightforward and should not cause any problems. > > > > Thank you! > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15968 > > > > > > > > вт, 23 нояб. 2021 г. в 20:44, Nikita Amelchev : > > > > > > > > > Ivan, > > > > > > > > > > I have cherry-picked the issue: > > > > > https://issues.apache.org/jira/browse/IGNITE-15767 > > > > > > > > > > вт, 23 нояб. 2021 г. в 20:31, Nikolay Izhikov : > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15951 > > > > > > > > > > > > Cherry-picked to 2.12 > > > > > > > > > > > > > 23 нояб. 2021 г., в 16:38, Nikita Amelchev > > > > > написал(а): > > > > > > > > > > > > > > Hi, +1 to cherry-pick. > > > > > > > > > > > > > > вт, 23 нояб. 2021 г. в 15:25, Ivan Daschinsky > > > > > > > : > > > > > > >> > > > > > > >> Hi! Lets add one simple bug fix, but very useful > > > > > > >> > > > > > > >> https://issues.apache.org/jira/browse/IGNITE-15767 > > > > > > >> > > > > > > >> пн, 22 нояб. 2021 г. в 15:22, Pavel Tupitsyn > > > > > > >> : > > > > > > >> > > > > > > >>> Yes, let's fix those auth issues, there are so many complaints > > > > > > >>> on > > > > > the user > > > > > > >>> list. > > > > > > >>> > > > > > > >>> On Mon, Nov 22, 2021 at 1:03 PM Mikhail Petrov < > > > > > pmgheap@gmail.com> > > > > > > >>> wrote: > > > > > > >>> > > > > > > Igniters, > > > > > > it seems that issues [1] and [2] that were discovered recently > > > > > > are > > > > > > blockers for the 2.12 release. > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15951 > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15966 > > > > > > > > > > > > On 22.11.2021 11:04, Nikolay Izhikov wrote: > > > > > > > Hello. > > > > > > > > > > > > > > One more tiny fix that will improve java thin client > > > > > > > performance in > > > > > > certain cases [1] > > > > > > > I think it worth to cherry-pick it to 2.12 release. > > > > > > > > > > > > > > Any objections? > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15924 > > > > > > > > > > > > > >> 19 нояб. 2021 г., в 14:56, Nikita Amelchev > > > > > > >> > > > > > > написал(а): > > > > > > >> > > > > > > >> Vladimir, +1. > > > > > > >> > > > > > > >> I have cherry-picked the issue. > > > > > > >> > > > > > > >> пт, 19 нояб. 2021 г. в 14:53, Steshin Vladimir < > > > > > vlads...@gmail.com>: > > > > > > >>> Hi all. > > > > > > >>> > > > > > > >>> > > > > > > >>> Let's add simple and useful thin-client-pool monitoring > > > > > > >>> in > > > > > 2.12: > > > > > > >>> > > > > > > >>> https://issues.apache.org/jira/browse/IGNITE-15183 > > > > > > >>> > > > > > > >>> https://github.com/apache/ignite/pull/9525 > > > > > > >>> > > > > > > >>> > > > > > > >>> 19.11.2021 09:50, Maksim Timonin пишет: > > > > > > Hi, I want to add to 2.12 a fix [1] of a bug [2]. It > > > > > > affects > > > > > users > > > > > > >>> of > > > > > > metrics in case there are too many partitions (> 2), we > > > > > observed > > > > > > extensive heap usage. > > > > > > > > > > > > [1] https://github.com/apache/ignite/pull/9518/files > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15781 > > > > > > > > > > > > On Thu, Nov 18, 2021 at
Real-world use cases: Ignite and High-Performance Computing
Folks, I've just published an article that lists some real-world use cases of Ignite for high-performance computing. Some of you might be interested in how the compute APIs are leveraged in practice: https://www.gridgain.com/resources/blog/how-apache-ignite-empowers-high-performance-computing-real-use-cases That's a short summary of recordings from past conferences and meetup talks. Thanks to everyone who shared their stories! - Denis
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Hello Maxim, > I don't understand why you are using *backwards compatibility* for completely internal things. > Why you are thinking in terms of users usage when are talking about ignite-sys-cache but not thinking when refactoring First of all, we are talking about all plugin developers. It does not matter it is open-source or proprietary plugins. Honestly, I don't have a list of all possible plugins that have already been developed and available under the ASF license, for instance. Do you have such a list? Can you be sure that this change will not affect anyone? > I don't understand why you are using *backwards compatibility* for completely internal things. > Why you are thinking in terms of users usage when are talking about ignite-sys-cache but not thinking when refactoring The system cache was the crucial thing in the architecture of Apache Ignite 1.x and 2.x (at least 2.1 - 2.11?) > All the internals have been reworked and nobody even mentioned that it may affect some of the plugin developers. Yep, perhaps, some internal parts of Apache Ignite were reworked in order to avoid using the system cache. However, it is still a part of Ignite and it works and can be used in plugins. Honestly, the mentioned alternative, I mean the distributed metastorage, is the INTERNAL thing as well. It means that plugin developer depends on INTERNAL entities. (it does not matter system-cache/metastorage) IMHO, such questions should be CAREFULLY discussed with no rush. > I do not propose to rush with the ignite-sys-cache removal. I'd like to collect all the technical stuff that we depend on, fix all of them and after everything will be ready do a final removal. Good! We are on the same page! > 1. Add deprecation for the 2.12 release. I hope it is still possible. If I am not mistaken, the code freeze was October 29. I think it is too late to introduce this change. We can add deprecation for the 2.13 release. > Apache Ignite core still have some dependencies on ignite-sys-cache that should fix for 2.13 Ok, I agree. We need to try to find out all edge cases and add new abilities to the metastorage in order to cover all known issues/requirements. > Remove the system cache in 2.14. It depends on our progress with improving the distributed metastorage. In general, I hope it will be possible. Thanks, S. чт, 2 дек. 2021 г. в 13:36, Maxim Muzafarov : > Pavel, > > > I don't understand why you are using *backwards compatibility* for > completely internal things. Why you are thinking in terms of users > usage when are talking about ignite-sys-cache but not thinking when > refactoring, for instance, all the checkpoint classes? Take a look at > the [1] issue. All the internals have been reworked and nobody even > mentioned that it may affect some of the plugin developers. This is > really strange, so I can't agree with you. > > > I do not propose to rush with the ignite-sys-cache removal. I'd like > to collect all the technical stuff that we depend on, fix all of them > and after everything will be ready do a final removal. Slava already > mentioned some crucial cases, so I hope you and Val also help with the > rest of them. Let's be more precise in terms *what we need to fix*. > > > I've made some investigations related to the ignite-sys-cache and here > is my proposal: > > 1. Add deprecation for the 2.12 release. I hope it is still possible. > > 2. Apache Ignite core still have some dependencies on ignite-sys-cache > that should fix for 2.13: > > 2.1. CLUSTER_NAME property: when it's not set the `deploymentId` of > system cache is used. Let's move it to metastorage. > 2.2. When the Security is enabled each compute task name (hash to be > more precise) is written to the ignite-sys-cache [2]. From my point of > view, we can remove it in 2.13. Can anyone check? > 2.3. Slava mentioned some issues with the distributed metastorage that > might be fixed. I think this is doable. > > 3. Remove the system cache in 2.14. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13143 > [2] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskProcessor.java#L201 > > On Thu, 2 Dec 2021 at 12:56, Pavel Tupitsyn wrote: > > > > Maxim, > > > > > I don't think that we should wait for 3-rd party plugins to be updated > > > this is an awful practice when the open-source product releases depend > > > on some of the proprietary plugins > > > > This makes no sense, sorry. > > > > It is not that we depend on 3rd party plugins. > > It is that *our users depend on us to preserve backwards compatibility*. > > No one likes when their app breaks suddenly because of a library update. > > > > We know about one use case for sys-cache in GridGain, but there may be > > more, no one knows. > > Every breaking change should be carried out carefully and gradually. > > > > > > On Thu, Dec 2, 2021 at 12:34 PM Maxim Muzafarov > wrote: > > > > > Slava, > > > > > > Thank you for the comments. >
Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]
Hi, Igniters. The release is blocked by the auth issue [1] discussed above. The patch will be prepared at the nearest time. I want to include the useful issue that adds the ability to configure snapshot thread pool size if nobody minds. [1] https://issues.apache.org/jira/browse/IGNITE-15966 [2] https://issues.apache.org/jira/browse/IGNITE-16014 пт, 26 нояб. 2021 г. в 11:44, Nikita Amelchev : > > Hello, > > I want to include the issue [1] to the 2.12 scope. It fixes some > metrics according to the JSR107. > > Any objections? > > [1] https://issues.apache.org/jira/browse/IGNITE-16002 The remove > cache method should update statistics if the method returns true > > чт, 25 нояб. 2021 г. в 17:12, Nikita Amelchev : > > > > Hello Ivan, > > > > +1, the issue can be cherry-picked to the 2.12. > > > > чт, 25 нояб. 2021 г. в 17:07, Ivan Bessonov : > > > > > > Hello everyone, > > > > > > is there a chance to add this issue to the release scope? [1] > > > Currently, defragmentation of certain types of indexes can corrupt them. > > > Fix is straightforward and should not cause any problems. > > > Thank you! > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15968 > > > > > > вт, 23 нояб. 2021 г. в 20:44, Nikita Amelchev : > > > > > > > Ivan, > > > > > > > > I have cherry-picked the issue: > > > > https://issues.apache.org/jira/browse/IGNITE-15767 > > > > > > > > вт, 23 нояб. 2021 г. в 20:31, Nikolay Izhikov : > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15951 > > > > > > > > > > Cherry-picked to 2.12 > > > > > > > > > > > 23 нояб. 2021 г., в 16:38, Nikita Amelchev > > > > написал(а): > > > > > > > > > > > > Hi, +1 to cherry-pick. > > > > > > > > > > > > вт, 23 нояб. 2021 г. в 15:25, Ivan Daschinsky : > > > > > >> > > > > > >> Hi! Lets add one simple bug fix, but very useful > > > > > >> > > > > > >> https://issues.apache.org/jira/browse/IGNITE-15767 > > > > > >> > > > > > >> пн, 22 нояб. 2021 г. в 15:22, Pavel Tupitsyn > > > > > >> : > > > > > >> > > > > > >>> Yes, let's fix those auth issues, there are so many complaints on > > > > the user > > > > > >>> list. > > > > > >>> > > > > > >>> On Mon, Nov 22, 2021 at 1:03 PM Mikhail Petrov < > > > > pmgheap@gmail.com> > > > > > >>> wrote: > > > > > >>> > > > > > Igniters, > > > > > it seems that issues [1] and [2] that were discovered recently > > > > > are > > > > > blockers for the 2.12 release. > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15951 > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15966 > > > > > > > > > > On 22.11.2021 11:04, Nikolay Izhikov wrote: > > > > > > Hello. > > > > > > > > > > > > One more tiny fix that will improve java thin client > > > > > > performance in > > > > > certain cases [1] > > > > > > I think it worth to cherry-pick it to 2.12 release. > > > > > > > > > > > > Any objections? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15924 > > > > > > > > > > > >> 19 нояб. 2021 г., в 14:56, Nikita Amelchev > > > > > >> > > > > > написал(а): > > > > > >> > > > > > >> Vladimir, +1. > > > > > >> > > > > > >> I have cherry-picked the issue. > > > > > >> > > > > > >> пт, 19 нояб. 2021 г. в 14:53, Steshin Vladimir < > > > > vlads...@gmail.com>: > > > > > >>> Hi all. > > > > > >>> > > > > > >>> > > > > > >>> Let's add simple and useful thin-client-pool monitoring in > > > > 2.12: > > > > > >>> > > > > > >>> https://issues.apache.org/jira/browse/IGNITE-15183 > > > > > >>> > > > > > >>> https://github.com/apache/ignite/pull/9525 > > > > > >>> > > > > > >>> > > > > > >>> 19.11.2021 09:50, Maksim Timonin пишет: > > > > > Hi, I want to add to 2.12 a fix [1] of a bug [2]. It affects > > > > users > > > > > >>> of > > > > > metrics in case there are too many partitions (> 2), we > > > > observed > > > > > extensive heap usage. > > > > > > > > > > [1] https://github.com/apache/ignite/pull/9518/files > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-15781 > > > > > > > > > > On Thu, Nov 18, 2021 at 12:59 PM Maksim Timonin < > > > > > timonin.ma...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi, guys, we have a blocker [1]. NPE for some SQL queries. I > > > > will > > > > > fix it > > > > > > in 1-2 days. > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-15943 > > > > > > > > > > > > On Mon, Nov 15, 2021 at 2:57 PM Maxim Muzafarov < > > > > mmu...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > >> Folks, > > > > > >> > > > > > >> I've fixed almost all the review comments [1]. Hopefully, > > > > > >> the > > > > > changes > > > > >
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Pavel, I don't understand why you are using *backwards compatibility* for completely internal things. Why you are thinking in terms of users usage when are talking about ignite-sys-cache but not thinking when refactoring, for instance, all the checkpoint classes? Take a look at the [1] issue. All the internals have been reworked and nobody even mentioned that it may affect some of the plugin developers. This is really strange, so I can't agree with you. I do not propose to rush with the ignite-sys-cache removal. I'd like to collect all the technical stuff that we depend on, fix all of them and after everything will be ready do a final removal. Slava already mentioned some crucial cases, so I hope you and Val also help with the rest of them. Let's be more precise in terms *what we need to fix*. I've made some investigations related to the ignite-sys-cache and here is my proposal: 1. Add deprecation for the 2.12 release. I hope it is still possible. 2. Apache Ignite core still have some dependencies on ignite-sys-cache that should fix for 2.13: 2.1. CLUSTER_NAME property: when it's not set the `deploymentId` of system cache is used. Let's move it to metastorage. 2.2. When the Security is enabled each compute task name (hash to be more precise) is written to the ignite-sys-cache [2]. From my point of view, we can remove it in 2.13. Can anyone check? 2.3. Slava mentioned some issues with the distributed metastorage that might be fixed. I think this is doable. 3. Remove the system cache in 2.14. [1] https://issues.apache.org/jira/browse/IGNITE-13143 [2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskProcessor.java#L201 On Thu, 2 Dec 2021 at 12:56, Pavel Tupitsyn wrote: > > Maxim, > > > I don't think that we should wait for 3-rd party plugins to be updated > > this is an awful practice when the open-source product releases depend > > on some of the proprietary plugins > > This makes no sense, sorry. > > It is not that we depend on 3rd party plugins. > It is that *our users depend on us to preserve backwards compatibility*. > No one likes when their app breaks suddenly because of a library update. > > We know about one use case for sys-cache in GridGain, but there may be > more, no one knows. > Every breaking change should be carried out carefully and gradually. > > > On Thu, Dec 2, 2021 at 12:34 PM Maxim Muzafarov wrote: > > > Slava, > > > > Thank you for the comments. > > > > > Maxim, the community must provide a reasonable time interval in order to > > notify all contributors and wait for updating all 3-rd party plugins. > > > > This is not actually true. We must notify about changes as earlier as > > possible and not only users but all the developers also. However, I > > don't think that we should wait for 3-rd party plugins to be updated > > this is an awful practice when the open-source product releases depend > > on some of the proprietary plugins. There is no dependency between > > Apache Ignite releases and proprietary plugin releases. If someone > > desires to upgrade to a new version of Apache Ignite it can update its > > plugins any time he likes. > > > > > We just need to provide a window that is enough to cover all related > > issues. > > > > Can you share all the issues you know, please? > > > > > distributed meta storage does not provide the ability to atomically > > change several properties at the same time (there are no transactions on > > this API). > > > > Can you share an example of what kind of properties we intend to > > change at the same? Will it be enough to change them through a single > > thread (e.g. the discovery thread or the exchange thread)? I agree > > here that distributed metastorage should provide such an ability, > > however, I can't find any real examples for Apache Ignite internal > > needs. Please, share the details and let's fix it. > > > > On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko > > wrote: > > > > > > Agree with Slava. Two months is not enough time, especially considering > > > that the system cache is not functionally equivalent to the metastorage. > > I > > > suggest we do the following: > > > > > > 1. Write down the differences between the system cache and the > > metastorage, > > > and provide a transition guide for plugin developers. > > > 2. Deprecate the system cache in 2.13. > > > 3. Remove the system cache in one of the further releases. I don't think > > > it's reasonable to do this earlier than mid next year (even that is > > > potentially too early). > > > > > > Removing the system cache is the right move, but let's be more > > considerate > > > to the users. There is absolutely no need to rush. > > > > > > -Val > > > > > > On Wed, Dec 1, 2021 at 7:28 AM Вячеслав Коптилин < > > slava.kopti...@gmail.com> > > > wrote: > > > > > > > Hi Maxim, > > > > > > > > > On the other hand, I don't see any valuable reason why the change > > can't > > > > be done and we
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Maxim, > I don't think that we should wait for 3-rd party plugins to be updated > this is an awful practice when the open-source product releases depend > on some of the proprietary plugins This makes no sense, sorry. It is not that we depend on 3rd party plugins. It is that *our users depend on us to preserve backwards compatibility*. No one likes when their app breaks suddenly because of a library update. We know about one use case for sys-cache in GridGain, but there may be more, no one knows. Every breaking change should be carried out carefully and gradually. On Thu, Dec 2, 2021 at 12:34 PM Maxim Muzafarov wrote: > Slava, > > Thank you for the comments. > > > Maxim, the community must provide a reasonable time interval in order to > notify all contributors and wait for updating all 3-rd party plugins. > > This is not actually true. We must notify about changes as earlier as > possible and not only users but all the developers also. However, I > don't think that we should wait for 3-rd party plugins to be updated > this is an awful practice when the open-source product releases depend > on some of the proprietary plugins. There is no dependency between > Apache Ignite releases and proprietary plugin releases. If someone > desires to upgrade to a new version of Apache Ignite it can update its > plugins any time he likes. > > > We just need to provide a window that is enough to cover all related > issues. > > Can you share all the issues you know, please? > > > distributed meta storage does not provide the ability to atomically > change several properties at the same time (there are no transactions on > this API). > > Can you share an example of what kind of properties we intend to > change at the same? Will it be enough to change them through a single > thread (e.g. the discovery thread or the exchange thread)? I agree > here that distributed metastorage should provide such an ability, > however, I can't find any real examples for Apache Ignite internal > needs. Please, share the details and let's fix it. > > On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko > wrote: > > > > Agree with Slava. Two months is not enough time, especially considering > > that the system cache is not functionally equivalent to the metastorage. > I > > suggest we do the following: > > > > 1. Write down the differences between the system cache and the > metastorage, > > and provide a transition guide for plugin developers. > > 2. Deprecate the system cache in 2.13. > > 3. Remove the system cache in one of the further releases. I don't think > > it's reasonable to do this earlier than mid next year (even that is > > potentially too early). > > > > Removing the system cache is the right move, but let's be more > considerate > > to the users. There is absolutely no need to rush. > > > > -Val > > > > On Wed, Dec 1, 2021 at 7:28 AM Вячеслав Коптилин < > slava.kopti...@gmail.com> > > wrote: > > > > > Hi Maxim, > > > > > > > On the other hand, I don't see any valuable reason why the change > can't > > > be done and we should wait for the future that never comes. > > > Maxim, the community must provide a reasonable time interval in order > to > > > notify all contributors and wait for updating all 3-rd party plugins. > > > Honestly, it does not seem to me that two, three months (the current > > > timeline - end of March is the release date, so the end of Feb is code > > > freeze) are quite enough. > > > > > > > I don't see any reasons why we should keep something in the CORE > module > > > that is being used at PLUGINS only. This is a lack of architecture > design > > > that must be fixed for sure; > > > I agree with you. We just need to provide a window that is enough to > cover > > > all related issues. > > > For example, distributed meta storage does not provide the ability to > > > atomically change several properties at the same time (there are no > > > transactions on this API). > > > > > > Perhaps, it would be nice to plan to remove the system cache on 2.14 or > > > even 2.15. What do you think? > > > > > > Thanks, > > > S. > > > > > > > > > вт, 30 нояб. 2021 г. в 13:58, Maxim Muzafarov : > > > > > > > Hello Val, > > > > > > > > Thank you for sharing the details. On the one hand, I agree with you > > > > that there is no need to haste with this change and it must be > > > > prepared carefully. On the other hand, I don't see any valuable > reason > > > > why the change can't be done and we should wait for the future that > > > > never comes. > > > > > > > > Please, consider the following my considerations: > > > > > > > > - The release 2.13 is not started yet. It will take months to be > > > > released (e.g. the end of March as a possible release date). The time > > > > is more than enough; > > > > - The 2.13 release has breaking changes, so it is a good opportunity > > > > to fix some gaps; > > > > - I don't see any reasons why we should keep something in the CORE > > > > module that is being used at PLUGINS only. This
Re: [DISCUSSION] Remove outdated ignite-sys-cache
Slava, Thank you for the comments. > Maxim, the community must provide a reasonable time interval in order to > notify all contributors and wait for updating all 3-rd party plugins. This is not actually true. We must notify about changes as earlier as possible and not only users but all the developers also. However, I don't think that we should wait for 3-rd party plugins to be updated this is an awful practice when the open-source product releases depend on some of the proprietary plugins. There is no dependency between Apache Ignite releases and proprietary plugin releases. If someone desires to upgrade to a new version of Apache Ignite it can update its plugins any time he likes. > We just need to provide a window that is enough to cover all related issues. Can you share all the issues you know, please? > distributed meta storage does not provide the ability to atomically change > several properties at the same time (there are no transactions on this API). Can you share an example of what kind of properties we intend to change at the same? Will it be enough to change them through a single thread (e.g. the discovery thread or the exchange thread)? I agree here that distributed metastorage should provide such an ability, however, I can't find any real examples for Apache Ignite internal needs. Please, share the details and let's fix it. On Wed, 1 Dec 2021 at 23:19, Valentin Kulichenko wrote: > > Agree with Slava. Two months is not enough time, especially considering > that the system cache is not functionally equivalent to the metastorage. I > suggest we do the following: > > 1. Write down the differences between the system cache and the metastorage, > and provide a transition guide for plugin developers. > 2. Deprecate the system cache in 2.13. > 3. Remove the system cache in one of the further releases. I don't think > it's reasonable to do this earlier than mid next year (even that is > potentially too early). > > Removing the system cache is the right move, but let's be more considerate > to the users. There is absolutely no need to rush. > > -Val > > On Wed, Dec 1, 2021 at 7:28 AM Вячеслав Коптилин > wrote: > > > Hi Maxim, > > > > > On the other hand, I don't see any valuable reason why the change can't > > be done and we should wait for the future that never comes. > > Maxim, the community must provide a reasonable time interval in order to > > notify all contributors and wait for updating all 3-rd party plugins. > > Honestly, it does not seem to me that two, three months (the current > > timeline - end of March is the release date, so the end of Feb is code > > freeze) are quite enough. > > > > > I don't see any reasons why we should keep something in the CORE module > > that is being used at PLUGINS only. This is a lack of architecture design > > that must be fixed for sure; > > I agree with you. We just need to provide a window that is enough to cover > > all related issues. > > For example, distributed meta storage does not provide the ability to > > atomically change several properties at the same time (there are no > > transactions on this API). > > > > Perhaps, it would be nice to plan to remove the system cache on 2.14 or > > even 2.15. What do you think? > > > > Thanks, > > S. > > > > > > вт, 30 нояб. 2021 г. в 13:58, Maxim Muzafarov : > > > > > Hello Val, > > > > > > Thank you for sharing the details. On the one hand, I agree with you > > > that there is no need to haste with this change and it must be > > > prepared carefully. On the other hand, I don't see any valuable reason > > > why the change can't be done and we should wait for the future that > > > never comes. > > > > > > Please, consider the following my considerations: > > > > > > - The release 2.13 is not started yet. It will take months to be > > > released (e.g. the end of March as a possible release date). The time > > > is more than enough; > > > - The 2.13 release has breaking changes, so it is a good opportunity > > > to fix some gaps; > > > - I don't see any reasons why we should keep something in the CORE > > > module that is being used at PLUGINS only. This is a lack of > > > architecture design that must be fixed for sure; > > > - The cache affects cluster stability and require additional human > > > resources for the code maintenance; > > > - As a straightforward solution plugins can create their own internal > > > caches and use them ever they like (or use the metastorage as I > > > mentioned earlier). Moving system cache to plugin doesn't look so > > > complicated and harmful; > > > > > > On Mon, 29 Nov 2021 at 23:07, Valentin Kulichenko > > > wrote: > > > > > > > > Maxim, > > > > > > > > You're right that the system cache is still likely to be used by > > plugins. > > > > We at GridGain use it for security features, for example. As far as I > > > know, > > > > that's not the only case. > > > > > > > > I also agree that the metastorage should be the preferred way for this > > > kind > > > > of
Re: NUMA aware allocator, PR review request
>> Our runs show about 7-10 speedup, Sorry, typo 7-10% speedup чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky : > Andrey, thanks! > > This allocator can be tested on every NUMA system. > Our runs show about 7-10 speedup, if we use allocattor with interleaved > strategy + -XX:+UseNUMA. > But unfortunately our yardstick benches doesn't use offheap a lot, usually > above one Gb. > We trying to do more benches with real data and share them, possibly in > meetup. > > AFAIK, GG lab servers are two-sockets machines, aren't they? So it is > worth to run benches with a lot data on them, using > allocator with interleaved strategy (you can skip specifying numa nodes, > by default it will use all available) and use -XX:+UseNUMA jvm > flag. > > > > чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov : > >> Ivan, >> >> Great job. PR looks good. >> >> This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to jvm >> > show promising results on yardstick benches. Technically, G1 is not a >> numa >> > aware collector for java versions less than 14, but allocation of heap >> in >> > interleaved mode shows good results even on java 11. >> >> Can you share benchmark results? >> I'm not sure I'll have an Optane on my notebook in a reasonable time ;) >> >> >> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky >> wrote: >> >> > Semyon D. and Maks T. -- thanks a lot for review. >> > >> > BTW, Igniters, I will appreciate all opinions and feedback. >> > >> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky : >> > >> > > Hi, igniters! >> > > >> > > There is not a big secret that nowadays NUMA is quite common in >> > > multiprocessor systems. >> > > And this memory architecture should be treated in specific ways. >> > > >> > > Support for NUMA is present in many commercial and open-source >> products. >> > > >> > > I've implemented a NUMA aware allocator for Apache Ignite [1] >> > > It is a JNI wrapper around `libnuma` and supports different allocation >> > > options. >> > > I.e. interleaved, local, interleved_mask and so on. For more >> information, >> > > see >> > > [2], [3]. >> > > This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to >> jvm >> > > show promising results on yardstick benches. Technically, G1 is not a >> > numa >> > > aware collector for java versions less than 14, but allocation of >> heap in >> > > interleaved mode shows good results even on java 11. >> > > >> > > Currently, all needed libraries and tools for building this module are >> > > available on TC agents >> > > setup of specific test suite is in progress [4] >> > > >> > > So I am asking for a review of my patch. >> > > >> > > [1] -- https://issues.apache.org/jira/browse/IGNITE-15922 >> > > [2] -- https://man7.org/linux/man-pages/man3/numa.3.html >> > > [3] -- https://man7.org/linux/man-pages/man2/mbind.2.html >> > > [4] -- https://issues.apache.org/jira/browse/IGNITE-15994 >> > > >> > >> > >> > -- >> > Sincerely yours, Ivan Daschinskiy >> > >> >> >> -- >> Best regards, >> Andrey V. Mashenkov >> > > > -- > Sincerely yours, Ivan Daschinskiy > -- Sincerely yours, Ivan Daschinskiy
Re: NUMA aware allocator, PR review request
Andrey, thanks! This allocator can be tested on every NUMA system. Our runs show about 7-10 speedup, if we use allocattor with interleaved strategy + -XX:+UseNUMA. But unfortunately our yardstick benches doesn't use offheap a lot, usually above one Gb. We trying to do more benches with real data and share them, possibly in meetup. AFAIK, GG lab servers are two-sockets machines, aren't they? So it is worth to run benches with a lot data on them, using allocator with interleaved strategy (you can skip specifying numa nodes, by default it will use all available) and use -XX:+UseNUMA jvm flag. чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov : > Ivan, > > Great job. PR looks good. > > This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to jvm > > show promising results on yardstick benches. Technically, G1 is not a > numa > > aware collector for java versions less than 14, but allocation of heap in > > interleaved mode shows good results even on java 11. > > Can you share benchmark results? > I'm not sure I'll have an Optane on my notebook in a reasonable time ;) > > > On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky > wrote: > > > Semyon D. and Maks T. -- thanks a lot for review. > > > > BTW, Igniters, I will appreciate all opinions and feedback. > > > > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky : > > > > > Hi, igniters! > > > > > > There is not a big secret that nowadays NUMA is quite common in > > > multiprocessor systems. > > > And this memory architecture should be treated in specific ways. > > > > > > Support for NUMA is present in many commercial and open-source > products. > > > > > > I've implemented a NUMA aware allocator for Apache Ignite [1] > > > It is a JNI wrapper around `libnuma` and supports different allocation > > > options. > > > I.e. interleaved, local, interleved_mask and so on. For more > information, > > > see > > > [2], [3]. > > > This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to > jvm > > > show promising results on yardstick benches. Technically, G1 is not a > > numa > > > aware collector for java versions less than 14, but allocation of heap > in > > > interleaved mode shows good results even on java 11. > > > > > > Currently, all needed libraries and tools for building this module are > > > available on TC agents > > > setup of specific test suite is in progress [4] > > > > > > So I am asking for a review of my patch. > > > > > > [1] -- https://issues.apache.org/jira/browse/IGNITE-15922 > > > [2] -- https://man7.org/linux/man-pages/man3/numa.3.html > > > [3] -- https://man7.org/linux/man-pages/man2/mbind.2.html > > > [4] -- https://issues.apache.org/jira/browse/IGNITE-15994 > > > > > > > > > -- > > Sincerely yours, Ivan Daschinskiy > > > > > -- > Best regards, > Andrey V. Mashenkov > -- Sincerely yours, Ivan Daschinskiy
Re: NUMA aware allocator, PR review request
Ivan, Great job. PR looks good. This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to jvm > show promising results on yardstick benches. Technically, G1 is not a numa > aware collector for java versions less than 14, but allocation of heap in > interleaved mode shows good results even on java 11. Can you share benchmark results? I'm not sure I'll have an Optane on my notebook in a reasonable time ;) On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky wrote: > Semyon D. and Maks T. -- thanks a lot for review. > > BTW, Igniters, I will appreciate all opinions and feedback. > > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky : > > > Hi, igniters! > > > > There is not a big secret that nowadays NUMA is quite common in > > multiprocessor systems. > > And this memory architecture should be treated in specific ways. > > > > Support for NUMA is present in many commercial and open-source products. > > > > I've implemented a NUMA aware allocator for Apache Ignite [1] > > It is a JNI wrapper around `libnuma` and supports different allocation > > options. > > I.e. interleaved, local, interleved_mask and so on. For more information, > > see > > [2], [3]. > > This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to jvm > > show promising results on yardstick benches. Technically, G1 is not a > numa > > aware collector for java versions less than 14, but allocation of heap in > > interleaved mode shows good results even on java 11. > > > > Currently, all needed libraries and tools for building this module are > > available on TC agents > > setup of specific test suite is in progress [4] > > > > So I am asking for a review of my patch. > > > > [1] -- https://issues.apache.org/jira/browse/IGNITE-15922 > > [2] -- https://man7.org/linux/man-pages/man3/numa.3.html > > [3] -- https://man7.org/linux/man-pages/man2/mbind.2.html > > [4] -- https://issues.apache.org/jira/browse/IGNITE-15994 > > > > > -- > Sincerely yours, Ivan Daschinskiy > -- Best regards, Andrey V. Mashenkov
