Re: Read load balancing, read-though, ttl and optimistic serializable transactions
Alexey, >> In short, the root cause of this issue is that there are configurations >> that allow a key to be stored on primary and backup nodes with different >> versions. Faced with the same problem during ReadRepair development. >> I suggest to force reads from a primary >> node inside optimistic serializable transactions. It looks like a proper fix (read-from-backup= ... && !read-through). >> I would suggest to revisit the >> read-through and TTL expiry semantics. Do we really need these features? - we have great full-featured consistent persistence, what's the point to use limited-featured inconsistent persistence via the external database? Can we get rid of this feature at 3.0? - Expiry policy is expensive (slowdown the cluster) and does not guarantee the in-time removal, and always may be replaced by proper design (state machine, query, eviction, in-memory cluster restart, etc). On Thu, Mar 5, 2020 at 12:33 PM Alexey Goncharuk wrote: > Igniters, > > I have recently discovered [1] that Ignite can arrive in a state when an > optimistic serializable transaction can never be successfully committed > from a backup node [2]. > > In short, the root cause of this issue is that there are configurations > that allow a key to be stored on primary and backup nodes with different > versions. This is a fundamental design choice that made a while ago, > however, I am not sure if this is a right way to go. When primary and > backup versions differ and read load balancing is enabled, the read version > will always mismatch with primary version and optimistic serializable > transaction will always fail. > > Here I wanted to discuss both short-term mitigation plan for the issue [2] > as well as a longer-term changes to replication protocol. > > As a short-term solution for [2] I suggest to force reads from a primary > node inside optimistic serializable transactions. The question is whether > to enforce this behavior only if the cache has a 3-rd party persistence > storage or this behavior should be always enforced. Note that the version > mismatch may appear even without a 3-rd party persistence storage when an > expiry policy is used. However, in this case, the version mismatch is > time-bound to the TTL cleanup lag. Personally, I would go with always > enforcing primary-node reads inside an optimistic serializable transaction. > > As a long-term solution which would eliminate the possibility of versions > desync on primary and backup nodes, I would suggest to revisit the > read-through and TTL expiry semantics. It looks like quite a lot of users > are actually struggling with the current implementation of read-through > because a miss does not load the value to all partition nodes [3]. As for > TTL, I remember it clearing up entries locally was a big issue for a proper > MVCC rebalance implementation (we ended up prohibiting TTL for MVCC > caches). > I think it may be better to make read-through and entry expiry a > partition-wide operation with the underlying cache guarantees. For > read-through it is justified because a partition-wide operation penalty is > comparable with the cache store load anyway (otherwise, a 3rd party storage > makes little sense). For entries expiration it should not make any > difference because it happens in background anyways. > > Any thoughts on the subject are very much appreciated. > > --AG > > [1] > > http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-NodeOrder-in-GridCacheVersion-td46108.html > [2] https://issues.apache.org/jira/browse/IGNITE-12739 > [3] > > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Read-through-not-working-as-expected-in-case-of-Replicated-cache-td46083.html >
Re: Read load balancing, read-though, ttl and optimistic serializable transactions
Anton, > >> In short, the root cause of this issue is that there are configurations > >> that allow a key to be stored on primary and backup nodes with different > >> versions. > Faced with the same problem during ReadRepair development. > > >> I suggest to force reads from a primary > >> node inside optimistic serializable transactions. > It looks like a proper fix (read-from-backup= ... && !read-through). > > >> I would suggest to revisit the > >> read-through and TTL expiry semantics. > Do we really need these features? > - we have great full-featured consistent persistence, what's the point to > use limited-featured inconsistent persistence via the external database? > Can we get rid of this feature at 3.0? > - Expiry policy is expensive (slowdown the cluster) and does not guarantee > the in-time removal, and always may be replaced by proper design (state > machine, query, eviction, in-memory cluster restart, etc). > Caching a 3rd-party persistence is one of the most widely used Ignite use-cases, I am sure we cannot drop this. Perhaps, it makes sense to separate the caching scenario in an explicit configuration and cache mode. Probably, even separate cache and database cases. As for expiry policy - I agree that a user can always implement it on application level, but a user can always implement transactions as well. If we already have a feature and we can fix it properly, why not keep it?
Re: Ignite 2.8 announcement plan
Denis, thanks for the feedback! When should I publish the post? Right after official release announcement, or later? > I would use "thick client" as a term instead of the "classic client" Good point, fixed > partition-awareness doesn't handle topology changes automatically (partition map won't be updated on the client-side) This is not true, we keep the partition map up to date by checking AffinityTopologyVersion [1] > Now I can run Ignite.NET easily on my Mac OS machine Just to clarify, you can do that since 2.4 release [2]. In 2.8 we have refined build-related things (jar file handling), and made sure that recent .NET versions are supported. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients [2] https://habr.com/ru/company/gridgain/blog/347374/ (in Russian) On Fri, Mar 6, 2020 at 2:40 AM Denis Magda wrote: > Pavel, thanks, > > I enjoyed reading the blog, crystal clear and straight to the point! Please > consider these several items that might strengthen the article a bit: > >- I would use "thick client" as a term instead of the "classic client" >(and mention that Ignite.NET client is a thick one). The thick client is >already a coined term that based on my observations are used a lot by > dev >and user communities. Also, you might add some differences of thick vs. >thin taking from this page - > > https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients >- Should we mention that presently partition-awareness doesn't handle >topology changes automatically (partition map won't be updated on the >client-side)? This might be a blocker for some users. >- Excited to read about the cross-platform support, that's huge! Now I >can run Ignite.NET easily on my Mac OS machine. I would insert a > reference >to updated documentation pages that explain how to start with > Ignite.NET on >various platforms. > > Hope, you will find this helpful, thanks for helping with project > promotion! > > - > Denis > > > On Thu, Mar 5, 2020 at 7:32 AM Pavel Tupitsyn > wrote: > > > Denis, > > > > The first post is going to be ready soon, probably by tomorrow. > > Here is a draft, feedback welcome: > > > > > https://github.com/ptupitsyn/ptupitsyn.github.io/blob/ignite-2.8/_posts/2020-03-05-Whats-New-In-Ignite-Net-2.8.md > > > > On Wed, Mar 4, 2020 at 5:15 PM Denis Magda wrote: > > > > > Hi Pavel, > > > > > > Excellent! It will be good to publish the first article (what's new in > > > Ignite.NET 2.8) prior to a generic blog on blogs.apache.org so that we > > can > > > link your post in for those who are looking for more details. Do you > have > > > any timeline in mind for this article? > > > > > > @Alexey Zinoviev , how about you preparing > > several > > > paragraphs for the blog highlighting the biggest changes in ML? The > same > > > highlighted content will be elaborated during the webinar. > > > > > > - > > > Denis > > > > > > > > > On Wed, Mar 4, 2020 at 2:29 AM Pavel Tupitsyn > > > wrote: > > > > > > > Denis, I have a few blog posts on Ignite.NET planned: > > > > > > > > * What's new in Ignite.NET 2.8 (Thin Client Partition Awareness, > > logging, > > > > expiry policy, cluster API, .NET Core 3.x, Dockerfile) > > > > * Ignite.NET performance improvements on .NET Core 3.x > > > > * Ignite.NET Partition Awareness performance > > > > * Fixing JNI thread leak in Ignite.NET > > > > > > > > What do you think? Should we have a schedule of some sorts? > > > > > > > > On Tue, Mar 3, 2020 at 9:58 PM Alexey Zinoviev < > zaleslaw@gmail.com > > > > > > > wrote: > > > > > > > > > Sounds ineresting, will help with the post, please share the > > template, > > > > not > > > > > sure about webinar > > > > > > > > > > вт, 3 мар. 2020 г., 20:59 Denis Magda : > > > > > > > > > > > Igniters, > > > > > > > > > > > > Let's discuss approaches for a global announcement/promotion of > the > > > > > > release. I would suggest focusing on a blog post and a community > > > > webinar. > > > > > > > > > > > > The blog post will introduce significant improvements (service > > grid, > > > > thin > > > > > > clients, new metrics system, ML, etc.) sharing references to > > > > > documentation > > > > > > pages with more details. It will be published on > blogs.apache.org > > > in > > > > a > > > > > > format similar to this one - > > > > > > https://blogs.apache.org/ignite/entry/apache-ignite-2-7-deep. I > > can > > > > work > > > > > > on > > > > > > it unless anybody else is willing to share the news on behalf of > > the > > > > > > community. > > > > > > > > > > > > Next, the blog post will be featuring a community webinar that is > > > > > breaking > > > > > > down a subset of the improvements in more detail. Please see an > > > > abstract > > > > > > below with suggested topics for a detailed overview. @Alexey > > Zinoviev > > > > > > , would you be able to present the ML > > part? > > > > > > @Nikolay > > >
Re: Slim binary release and docker image for Apache Ignite
Hello! Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* I have prepared assemblies for Apache Ignite slim packaging: https://github.com/apache/ignite/tree/ignite-slim It is based on ignite-2.8 You can build it with mvn initialize -Prelease,lgpl -Dignite.edition=apache- ignite-slim after a normal release build. Please consider the contents of resulting target/bin/apache-ignite-slim-2.8.0-bin.zip It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 distribution. My suggestion is that we can publish it as a post-release step since it does not affect the release in any way. If we do, we should probably indicate size for every kind of artifact in our download section, so our users can choose based on that information. The following modules are included: libs: core/shmem/jcache ignite-indexing ignite-spring libs/optional: ignite-compress ignite-kubernetes ignite-log4j2 ignite-rest-http ignite-spring-data_2.2 ignite-jta ignite-log4j ignite-opencensus ignite-slf4j ignite-urideploy I have kept examples, but removed benchmarks. sqlline still present, of course. ignite-zookeeper has a lot of dependencies (8M) which we do not update often enough (such as guava, curator, jackson), and which may form an attack surface. Not a pressing problem for 'integrated' ignite-zookeeper users, since they can re-import these dependencies with more recent versions using maven or gradle. But for our users who rely on binary package for all JARs, outdated dependencies may pose a problem. Therefore my opinion is to exclude this dependency and not put our faith on zookeeper dependency version. The same can be put for ignite-compress, and indeed, I'm not sure if we should keep it. We can have an ad-hoc vote here. I would like to hear arguments for both inclusion and exclusion of ignite-zookeeper and ignite-compress into slim package (in any combination). I would also like to know if you want a formal vote on the issue. Regards, -- Ilya Kasnacheev пн, 27 янв. 2020 г. в 21:13, Denis Magda : > Alex, could you please list all the modules that will be excluded? It will > help to confirm we haven't dumped anything essential. > > - > Denis > > > On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > Got it, sounds good! > > Should we consider the list of modules included in the slim package > > finalized? > > > > чт, 16 янв. 2020 г. в 13:13, Igor Sapego : > > > > > Alexey, if I understand correctly, Ilya does not suggest to pre-built > > > binaries, just to ship it with configure script pre-generated, which > > > is a common practice for autotools packages. Building will be still > > > required for the user, but there will be less requirements and > > > possible errors during build. > > > > > > I like the idea. Let's do this. > > > > > > Best Regards, > > > Igor > > > > > > > > > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk < > > > alexey.goncha...@gmail.com> wrote: > > > > > > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I > > would > > > > not name it 'core' because indeed it would be confusing with the core > > > > module name. > > > > > > > > Agree that platforms support is useful, so I would keep them as Ilya > > > > suggested. As for the C++ packages pre-build - let's hear out Igor's > > > > opinion on this. Pre-built binaries certainly add usability, but I am > > not > > > > sure how those binaries should be tested afterwards. > > > > > > > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov >: > > > > > > > > > I'm +1 for "SLIM" it is a common name in Docker world. > > > > > > > > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov > > > wrote: > > > > > > > > > > > +1 for slim binary > > > > > > Plus docker-slim > > > > > > Plus RPM / DEB packages modularisation like PHP distribution — > with > > > > core > > > > > > and lots of integrations / modules. > > > > > > > > > > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > I think we should name it "core" since we already have > > ignite-core > > > > and > > > > > it > > > > > > > will be confusing. Maybe we should go full 00s and call it > > "lite"? > > > > > > > > > > > > > > I also think we should keep both .Net and C++. .Net is runnable > > out > > > > of > > > > > > box > > > > > > > which is awesome, and C++ needs building but it is rather small > > in > > > > > source > > > > > > > form. > > > > > > > > > > > > > > I also suggest a different change to build process. Let's ship > > C++ > > > > with > > > > > > > automake, etc, already run, for all binary packaging options? > > > WDYT? I > > > > > can > > > > > > > assist in build process tuning. > > > > > > > > > > > > > > Regards, > > > > > > > -- > > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda : > > > > > > > >
Re: Slim binary release and docker image for Apache Ignite
Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very few people who use either. > On 6 Mar 2020, at 11:09, Ilya Kasnacheev wrote: > > Hello! > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* > > I have prepared assemblies for Apache Ignite slim packaging: > https://github.com/apache/ignite/tree/ignite-slim > > It is based on ignite-2.8 > > You can build it with mvn initialize -Prelease,lgpl -Dignite.edition=apache- > ignite-slim after a normal release build. > > Please consider the contents of resulting > target/bin/apache-ignite-slim-2.8.0-bin.zip > It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 > distribution. > > My suggestion is that we can publish it as a post-release step since it > does not affect the release in any way. If we do, we should probably > indicate size for every kind of artifact in our download section, so our > users can choose based on that information. > > The following modules are included: > > libs: > core/shmem/jcache > ignite-indexing > ignite-spring > > libs/optional: > ignite-compress ignite-kubernetes ignite-log4j2 ignite-rest-http > ignite-spring-data_2.2 > ignite-jta ignite-log4j ignite-opencensus ignite-slf4j > ignite-urideploy > > I have kept examples, but removed benchmarks. sqlline still present, of > course. > > ignite-zookeeper has a lot of dependencies (8M) which we do not update > often enough (such as guava, curator, jackson), and which may form an > attack surface. > > Not a pressing problem for 'integrated' ignite-zookeeper users, since they > can re-import these dependencies with more recent versions using maven or > gradle. > But for our users who rely on binary package for all JARs, outdated > dependencies may pose a problem. > > Therefore my opinion is to exclude this dependency and not put our faith on > zookeeper dependency version. > > The same can be put for ignite-compress, and indeed, I'm not sure if we > should keep it. > > We can have an ad-hoc vote here. > > I would like to hear arguments for both inclusion and exclusion of > ignite-zookeeper and ignite-compress into slim package (in any combination). > > I would also like to know if you want a formal vote on the issue. > > Regards, > -- > Ilya Kasnacheev > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda : > >> Alex, could you please list all the modules that will be excluded? It will >> help to confirm we haven't dumped anything essential. >> >> - >> Denis >> >> >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < >> alexey.goncha...@gmail.com> wrote: >> >>> Got it, sounds good! >>> Should we consider the list of modules included in the slim package >>> finalized? >>> >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego : >>> Alexey, if I understand correctly, Ilya does not suggest to pre-built binaries, just to ship it with configure script pre-generated, which is a common practice for autotools packages. Building will be still required for the user, but there will be less requirements and possible errors during build. I like the idea. Let's do this. Best Regards, Igor On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > To me it doesn't really matter if it will be 'slim' or 'lite' :) I >>> would > not name it 'core' because indeed it would be confusing with the core > module name. > > Agree that platforms support is useful, so I would keep them as Ilya > suggested. As for the C++ packages pre-build - let's hear out Igor's > opinion on this. Pre-built binaries certainly add usability, but I am >>> not > sure how those binaries should be tested afterwards. > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov >> : > >> I'm +1 for "SLIM" it is a common name in Docker world. >> >> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov wrote: >> >>> +1 for slim binary >>> Plus docker-slim >>> Plus RPM / DEB packages modularisation like PHP distribution — >> with > core >>> and lots of integrations / modules. >>> On 15 Jan 2020, at 17:40, Ilya Kasnacheev < ilya.kasnach...@gmail.com >> >>> wrote: Hello! I think we should name it "core" since we already have >>> ignite-core > and >> it will be confusing. Maybe we should go full 00s and call it >>> "lite"? I also think we should keep both .Net and C++. .Net is runnable >>> out > of >>> box which is awesome, and C++ needs building but it is rather small >>> in >> source form. I also suggest a different change to build process. Let's ship >>> C++ > with automake, etc, already run, for all binary packaging options? WDYT? I >> can assist in build process tuning. Regards,
Re: Slim binary release and docker image for Apache Ignite
Hello! I added these because they are infrastructural to Ignite, as opposed to integrations. They are also both very slim. Regards, -- Ilya Kasnacheev пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < stephen.darling...@gridgain.com>: > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very few > people who use either. > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev > wrote: > > > > Hello! > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* > > > > I have prepared assemblies for Apache Ignite slim packaging: > > https://github.com/apache/ignite/tree/ignite-slim > > > > It is based on ignite-2.8 > > > > You can build it with mvn initialize -Prelease,lgpl > -Dignite.edition=apache- > > ignite-slim after a normal release build. > > > > Please consider the contents of resulting > > target/bin/apache-ignite-slim-2.8.0-bin.zip > > It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 > > distribution. > > > > My suggestion is that we can publish it as a post-release step since it > > does not affect the release in any way. If we do, we should probably > > indicate size for every kind of artifact in our download section, so our > > users can choose based on that information. > > > > The following modules are included: > > > > libs: > > core/shmem/jcache > > ignite-indexing > > ignite-spring > > > > libs/optional: > > ignite-compress ignite-kubernetes ignite-log4j2 ignite-rest-http > > ignite-spring-data_2.2 > > ignite-jta ignite-log4j ignite-opencensus ignite-slf4j > > ignite-urideploy > > > > I have kept examples, but removed benchmarks. sqlline still present, of > > course. > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not update > > often enough (such as guava, curator, jackson), and which may form an > > attack surface. > > > > Not a pressing problem for 'integrated' ignite-zookeeper users, since > they > > can re-import these dependencies with more recent versions using maven or > > gradle. > > But for our users who rely on binary package for all JARs, outdated > > dependencies may pose a problem. > > > > Therefore my opinion is to exclude this dependency and not put our faith > on > > zookeeper dependency version. > > > > The same can be put for ignite-compress, and indeed, I'm not sure if we > > should keep it. > > > > We can have an ad-hoc vote here. > > > > I would like to hear arguments for both inclusion and exclusion of > > ignite-zookeeper and ignite-compress into slim package (in any > combination). > > > > I would also like to know if you want a formal vote on the issue. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda : > > > >> Alex, could you please list all the modules that will be excluded? It > will > >> help to confirm we haven't dumped anything essential. > >> > >> - > >> Denis > >> > >> > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < > >> alexey.goncha...@gmail.com> wrote: > >> > >>> Got it, sounds good! > >>> Should we consider the list of modules included in the slim package > >>> finalized? > >>> > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego : > >>> > Alexey, if I understand correctly, Ilya does not suggest to pre-built > binaries, just to ship it with configure script pre-generated, which > is a common practice for autotools packages. Building will be still > required for the user, but there will be less requirements and > possible errors during build. > > I like the idea. Let's do this. > > Best Regards, > Igor > > > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I > >>> would > > not name it 'core' because indeed it would be confusing with the core > > module name. > > > > Agree that platforms support is useful, so I would keep them as Ilya > > suggested. As for the C++ packages pre-build - let's hear out Igor's > > opinion on this. Pre-built binaries certainly add usability, but I am > >>> not > > sure how those binaries should be tested afterwards. > > > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov >>> : > > > >> I'm +1 for "SLIM" it is a common name in Docker world. > >> > >> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov > wrote: > >> > >>> +1 for slim binary > >>> Plus docker-slim > >>> Plus RPM / DEB packages modularisation like PHP distribution — > >> with > > core > >>> and lots of integrations / modules. > >>> > On 15 Jan 2020, at 17:40, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > >> > >>> wrote: > > Hello! > > I think we should name it "core" since we already have > >>> ignite-core > > and > >> it > will be confusing. Maybe we should go full 00s and call it > >>> "lite"
Re: Ignite 2.8 documentation
Anton, Thanks for the feedback. I updated the page. -Artem On 05.03.2020 16:32, Anton Vinogradov wrote: Artem, great! Some minors: read operations become more costly for caches with backup copies. Since it makes sense only for cache with backups, can we say something like "read operations become at least 2 times costly since backups checked as well" for atomic caches, a consistency violation exception is thrown. ... after N checks, where N is 3 by default and can be set by "IGNITE_NEAR_GET_MAX_REMAPS" system property. Also, need to mention that each found violation triggers event with type == org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes org.apache.ignite.events.CacheConsistencyViolationEvent which should be used for rechecking of repait results. On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov wrote: Anton, Could you please review the page about Read Rapair? https://apacheignite.readme.io/docs/read-repair -Artem On 05.03.2020 12:20, Artem Budnikov wrote: OK, I'll recreate it. Nikolay, please let me know when you are finished with the Metrics and system views documentation. I'm done with the list of docs we identified in this thread and want to publish v. 2.8. -Artem On 05.03.2020 11:55, Maxim Muzafarov wrote: Artem, I've created that. It is not public and can be safely removed since it's a full copy of 2.7.6 (at that moment) On Thu, 5 Mar 2020 at 11:53, Artem Budnikov wrote: Guys, I see that there is already version 2.8 for Ignite docs on readme.io. Who created it and when? I've changed some pages under 2.7.6 version without knowing that there is a newer version. -Artem On 05.03.2020 11:45, Artem Budnikov wrote: I'm confused. Igor, could you please double check? -Artem On 05.03.2020 04:15, Ivan Pavlukhin wrote: That's right, only C++ and .NET clients have partition awareness Are your sure? Was not the feature implemented for java thin client in [1]? [1] https://issues.apache.org/jira/browse/IGNITE-11898 Best regards, Ivan Pavlukhin ср, 4 мар. 2020 г. в 18:18, Denis Magda : Maxim, Yes, it's preferable to have metrics pages fully completed even though the feature is an experimental state. We want to encourage to try it out and switch to the new APIs eventually. Without technical instructions available our users will have a hard time checking the new capabilities. Nikolay, thanks a lot! - Denis On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov I think yes. I will prepare documentation shortly. 4 марта 2020 г., в 17:50, Maxim Muzafarov написал(а): Folks, Do we need a fully complete public documentation for metrics marked with @ExperimentalFeature? The API can significantly be changed. On Wed, 4 Mar 2020 at 17:10, Artem Budnikov wrote: The only feature that is left is "WAL page compression" The three other features are limitations that were present in Ignite 2.7 and now they are removed. Since they were never mentioned in the docs, there is nothing to do. -Artem On 04.03.2020 17:02, Denis Magda wrote: I'll work on the following items today and tomorrow: - JDBC: Support for query cancellation - JDBC: Support for query timeout - suspend/resume for pessimistic transactions - WAL page compression Artem, are these the only tickets left apart from the metrics & monitoring? @Nikolay Izhikov how soon will you be able to finish the metrics documentation pages? - Denis On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov wrote: Hi everyone, I have created the docs for the following items so far: -Default Ignite work dir location https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory - Baseline auto-adjust feature https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment - Cluster (de)activation events documentation https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events - Remove SqlQuery documentation done - Partition awareness for thin clients https://apacheignite-net.readme.io/docs/thin-client-28#section-partition-awareness https://apacheignite-cpp.readme.io/docs/thin-client-28#section-partition-awareness - Transactions support in java thin client https://apacheignite.readme.io/docs/key-value-28#section-client-transactions - KILL QUERY command https://dash.readme.io/project/apacheignite-sql/v2.7.6/docs/kill-query - Move rebalance configuration properties to the IgniteConfiguration level https://apacheignite.readme.io/docs/data-rebalancing-28#section-configuration - Renamed IGNITE schema to SYS done I'll work on the following items today and tomorrow: - JDBC: Support for query cancellation - JDBC: Support for query timeout - suspend/resume for pessimistic transactions -
[jira] [Created] (IGNITE-12756) TcpCommunicationSpi metrics implementation improvements
Andrey N. Gura created IGNITE-12756:
---
Summary: TcpCommunicationSpi metrics implementation improvements
Key: IGNITE-12756
URL: https://issues.apache.org/jira/browse/IGNITE-12756
Project: Ignite
Issue Type: Improvement
Reporter: Andrey N. Gura
Assignee: Andrey N. Gura
Implementation of IGNITE-12682 allows now to create cent/received counters by
message direct type statically during SPI initialization. Data structure for
this counters does have any contention so we can remove thread local HashMap's
for this counters. As result we will also reduce memory footprint (we can use
IntHashMap which is more memory effective and we will have only one map
instance instead of map per thread).
Also there is a couple of problems which could be solved during implementation
this issue:
- SPI uses internal API while we should extend IgniteSpiContext that will
provide access to the {{GridMEtricManager}} functionality.
- {{MetricManagerResource}} annotation is redundant and has only one usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12757) ignitevisorcmd does not connect to the cluster
Nikolai Kulagin created IGNITE-12757: Summary: ignitevisorcmd does not connect to the cluster Key: IGNITE-12757 URL: https://issues.apache.org/jira/browse/IGNITE-12757 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Nikolai Kulagin ignitevisorcmd does not connect to the cluster. The log does not contain any errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Ignite Website: New Look
Hi Igniters, IMO, new design looks good, but please pay attention - every mention of Apache Ignite is better to be followed by (R) mark since it is registered trademark of the ASF in the US and other countries. - download page is not available (as Denis mentioned it should not be an issue). And one more side note: since 1) it is a major change in the site look and 2) our site is still stored in the SVN, could we consider migrating to Git repository first? Git benefits are more or less obvious: - It will allow us to make a PRs for contributions to the site. - Git repository is slightly more convenient. It works faster during clone, commit, and update. - It should help to recognize contributions from Mauricio and Ignacio and all other members, who updates and maintains the site (we don't have contributors listing page and we use git for listing of the project's developers). Sincerely, Dmitriy Pavlov BTW, since this is important topic, I suggest every email with proposal is marked with [DISCUSSION] to help it to be noticed. пт, 6 мар. 2020 г. в 03:21, Nikita Ivanov : > Denis - looks very nice! I do indeed think we need to work on better > content (home page specifically). > Thanks! > -- > Nikita Ivanov > > > > On Thu, Mar 5, 2020 at 3:18 PM Denis Magda wrote: > > > Folks, > > > > As many of you know, these days I mostly contribute by optimizing our > > website, preparing different content including documentation/articles, > and > > presenting the project at various events. One of the continuous website > > activities we undertake together with Mauricio and Ignacio is search > engine > > optimization (SEO). It helps our website to be ranked higher by search > > engines for user searches falling in categories of in-memory caches, > grids, > > databases, etc. (check this simple guide [1] if you'd like to learn the > > internals of SEO). > > > > After checking the results of our recent user questionnaire [2] and > > confirming key capabilities with use cases Ignite is selected for, we > > decided to put more effort into the SEO. And, in addition to the keywords > > optimizations, we invested some time into the structural and UI changes > of > > the website trying to make the experience better and, as a result, be > > ranked higher. > > > > So, today we'd like to share our first results and check your thoughts. > In > > particular, pay attention to: > > > >- The new UI - instead of a dark and bloody theme, we decided to > >experiment with a more lightweight and contemporary design. > >- A new main page structure with the following blocks - banner, use > >cases, features, quicks links + tweeter feed. > >- Updated navigation menu - kept essential or highly-ranked pages. > > > > > > Do NOT pay attention to the following yet (we're ready to carry on with > the > > items below once hear your feedback): > > > >- Text on the front page will be massaged and tweaked going forward to > >get better SEO. Presently, something might sound off to you. > >- Secondary pages are broken from the UI and structure standpoint > >- Some of the pages of the navigation menu, such as Videos, are not > >created yet. > > > > > > Alright, we deployed our branch to this test server. Go and check: > > http://157.245.190.104 (user: ignite, pass: apache2020) > > > > > > > > [1] https://moz.com/beginners-guide-to-seo > > [2] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Evolution-Direction-short-questionary-td44577.html > > > > - > > Denis > > >
Fwd: [NOTICE] Structural changes to Apache downloads
Hi Igniters, I feel it worth sharing with all of you. I don't think there is something private in this notice. JFYI Sincerely, Dmitriy Pavlov -- Forwarded message - От: Daniel Gruno Date: ср, 4 мар. 2020 г. в 18:04 Subject: [NOTICE] Structural changes to Apache downloads To: Hello, Apache PMCs, In order to better provide our millions of users with downloads, the Apache Infrastructure Team has been restructuring the way downloads work for our main distribution channels in the past few weeks. For users, this will largely go unnoticed, and for projects likely the same, but we did want to reach out to projects and inform them of the changes we've made: As of March 2020, we are deprecating www.apache.org/dist/ in favor of https://downloads.apache.org/ for backup downloads as well as signature and checksum verification. The primary driver has been splitting up web site visits and downloads to gain better control and offer a better service for both downloads and web site visits. As stated, this does not impact end-users, and should have a minimal impact on projects, as our download selectors as well as visits to www.apache.org/dist/ have been adjusted to make use of downloads.apache.org instead. We do however ask that projects, in their own time-frame, change references on their own web sites from www.apache.org/dist/ to downloads.apache.org wherever such references may exist, to complete the switch in full. We will NOT be turning off www.apache.org/dist/ in the near future, but would greatly appreciate if projects could help us transition away from the old URLs in their documentation and on their download pages. The standard way of uploading releases[1] will STILL apply, however there may be a short delay (<= 15 minutes) between releasing and releases showing up on downloads.apache.org for technical reasons. If you have any questions about this change, please do not hesitate to reach out to us at us...@infra.apache.org. With regards, Daniel on behalf of ASF Infrastructure. [1] https://www.apache.org/legal/release-policy.html#upload-ci
Re: Slim binary release and docker image for Apache Ignite
Ilya, `ignite-compress` is necessary for `wal page snapshot compression` [1] which in turn shows very good performance results. So, I suppose, it's better to include it to the "slim" binary. [1] https://issues.apache.org/jira/browse/IGNITE-11336 On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev wrote: > > Hello! > > I added these because they are infrastructural to Ignite, as opposed to > integrations. They are also both very slim. > > Regards, > -- > Ilya Kasnacheev > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < > stephen.darling...@gridgain.com>: > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very few > > people who use either. > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev > > wrote: > > > > > > Hello! > > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* > > > > > > I have prepared assemblies for Apache Ignite slim packaging: > > > https://github.com/apache/ignite/tree/ignite-slim > > > > > > It is based on ignite-2.8 > > > > > > You can build it with mvn initialize -Prelease,lgpl > > -Dignite.edition=apache- > > > ignite-slim after a normal release build. > > > > > > Please consider the contents of resulting > > > target/bin/apache-ignite-slim-2.8.0-bin.zip > > > It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 > > > distribution. > > > > > > My suggestion is that we can publish it as a post-release step since it > > > does not affect the release in any way. If we do, we should probably > > > indicate size for every kind of artifact in our download section, so our > > > users can choose based on that information. > > > > > > The following modules are included: > > > > > > libs: > > > core/shmem/jcache > > > ignite-indexing > > > ignite-spring > > > > > > libs/optional: > > > ignite-compress ignite-kubernetes ignite-log4j2 ignite-rest-http > > > ignite-spring-data_2.2 > > > ignite-jta ignite-log4j ignite-opencensus ignite-slf4j > > > ignite-urideploy > > > > > > I have kept examples, but removed benchmarks. sqlline still present, of > > > course. > > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not update > > > often enough (such as guava, curator, jackson), and which may form an > > > attack surface. > > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users, since > > they > > > can re-import these dependencies with more recent versions using maven or > > > gradle. > > > But for our users who rely on binary package for all JARs, outdated > > > dependencies may pose a problem. > > > > > > Therefore my opinion is to exclude this dependency and not put our faith > > on > > > zookeeper dependency version. > > > > > > The same can be put for ignite-compress, and indeed, I'm not sure if we > > > should keep it. > > > > > > We can have an ad-hoc vote here. > > > > > > I would like to hear arguments for both inclusion and exclusion of > > > ignite-zookeeper and ignite-compress into slim package (in any > > combination). > > > > > > I would also like to know if you want a formal vote on the issue. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda : > > > > > >> Alex, could you please list all the modules that will be excluded? It > > will > > >> help to confirm we haven't dumped anything essential. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < > > >> alexey.goncha...@gmail.com> wrote: > > >> > > >>> Got it, sounds good! > > >>> Should we consider the list of modules included in the slim package > > >>> finalized? > > >>> > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego : > > >>> > > Alexey, if I understand correctly, Ilya does not suggest to pre-built > > binaries, just to ship it with configure script pre-generated, which > > is a common practice for autotools packages. Building will be still > > required for the user, but there will be less requirements and > > possible errors during build. > > > > I like the idea. Let's do this. > > > > Best Regards, > > Igor > > > > > > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk < > > alexey.goncha...@gmail.com> wrote: > > > > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I > > >>> would > > > not name it 'core' because indeed it would be confusing with the core > > > module name. > > > > > > Agree that platforms support is useful, so I would keep them as Ilya > > > suggested. As for the C++ packages pre-build - let's hear out Igor's > > > opinion on this. Pre-built binaries certainly add usability, but I am > > >>> not > > > sure how those binaries should be tested afterwards. > > > > > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov > >>> : > > > > > >> I'm +1 for "SLIM" it is a common name in Docker world. > > >> > > >> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivano
Re: Ignite Website: New Look
Dmitry, Agree on the Github repository. Let me look into it. If you have any pointers or came across any instructions earlier please let me know. - Denis On Fri, Mar 6, 2020 at 8:03 AM Dmitriy Pavlov wrote: > Hi Igniters, > > IMO, new design looks good, but please pay attention > - every mention of Apache Ignite is better to be followed by (R) mark since > it is registered trademark of the ASF in the US and other countries. > - download page is not available (as Denis mentioned it should not be an > issue). > > And one more side note: since 1) it is a major change in the site look and > 2) our site is still stored in the SVN, could we consider migrating to Git > repository first? > > Git benefits are more or less obvious: > - It will allow us to make a PRs for contributions to the site. > - Git repository is slightly more convenient. It works faster during clone, > commit, and update. > - It should help to recognize contributions from Mauricio and Ignacio and > all other members, who updates and maintains the site (we don't have > contributors listing page and we use git for listing of the project's > developers). > > Sincerely, > Dmitriy Pavlov > > BTW, since this is important topic, I suggest every email with proposal is > marked with [DISCUSSION] to help it to be noticed. > > пт, 6 мар. 2020 г. в 03:21, Nikita Ivanov : > > > Denis - looks very nice! I do indeed think we need to work on better > > content (home page specifically). > > Thanks! > > -- > > Nikita Ivanov > > > > > > > > On Thu, Mar 5, 2020 at 3:18 PM Denis Magda wrote: > > > > > Folks, > > > > > > As many of you know, these days I mostly contribute by optimizing our > > > website, preparing different content including documentation/articles, > > and > > > presenting the project at various events. One of the continuous website > > > activities we undertake together with Mauricio and Ignacio is search > > engine > > > optimization (SEO). It helps our website to be ranked higher by search > > > engines for user searches falling in categories of in-memory caches, > > grids, > > > databases, etc. (check this simple guide [1] if you'd like to learn the > > > internals of SEO). > > > > > > After checking the results of our recent user questionnaire [2] and > > > confirming key capabilities with use cases Ignite is selected for, we > > > decided to put more effort into the SEO. And, in addition to the > keywords > > > optimizations, we invested some time into the structural and UI changes > > of > > > the website trying to make the experience better and, as a result, be > > > ranked higher. > > > > > > So, today we'd like to share our first results and check your thoughts. > > In > > > particular, pay attention to: > > > > > >- The new UI - instead of a dark and bloody theme, we decided to > > >experiment with a more lightweight and contemporary design. > > >- A new main page structure with the following blocks - banner, use > > >cases, features, quicks links + tweeter feed. > > >- Updated navigation menu - kept essential or highly-ranked pages. > > > > > > > > > Do NOT pay attention to the following yet (we're ready to carry on with > > the > > > items below once hear your feedback): > > > > > >- Text on the front page will be massaged and tweaked going forward > to > > >get better SEO. Presently, something might sound off to you. > > >- Secondary pages are broken from the UI and structure standpoint > > >- Some of the pages of the navigation menu, such as Videos, are not > > >created yet. > > > > > > > > > Alright, we deployed our branch to this test server. Go and check: > > > http://157.245.190.104 (user: ignite, pass: apache2020) > > > > > > > > > > > > [1] https://moz.com/beginners-guide-to-seo > > > [2] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Evolution-Direction-short-questionary-td44577.html > > > > > > - > > > Denis > > > > > >
Re: Read load balancing, read-though, ttl and optimistic serializable transactions
Alex, thanks for monitoring various discussion threads and sharing these problems with the rest of the dev community. >> As a short-term solution for [2] I suggest to force reads from a primary > node inside optimistic serializable transactions. Totally agree on this. Anyway, consistency and predictable behavior matter most. Also, it shouldn't affect performance anyhow dramatically. >> I think it may be better to make read-through and entry expiry a > partition-wide operation with the underlying cache guarantees. That's a pain in the neck! As you properly mentioned, an in-memory data grid sitting on top of an external database is still our dominating use case. So, a partition-wide operation assumes that if a record is read from a CacheStore than its value will be replicated to all the primary and backup copies, right? - Denis On Fri, Mar 6, 2020 at 12:58 AM Alexey Goncharuk wrote: > Anton, > > > > >> In short, the root cause of this issue is that there are > configurations > > >> that allow a key to be stored on primary and backup nodes with > different > > >> versions. > > Faced with the same problem during ReadRepair development. > > > > >> I suggest to force reads from a primary > > >> node inside optimistic serializable transactions. > > It looks like a proper fix (read-from-backup= ... && !read-through). > > > > >> I would suggest to revisit the > > >> read-through and TTL expiry semantics. > > Do we really need these features? > > - we have great full-featured consistent persistence, what's the point to > > use limited-featured inconsistent persistence via the external database? > > Can we get rid of this feature at 3.0? > > - Expiry policy is expensive (slowdown the cluster) and does not > guarantee > > the in-time removal, and always may be replaced by proper design (state > > machine, query, eviction, in-memory cluster restart, etc). > > > > Caching a 3rd-party persistence is one of the most widely used Ignite > use-cases, I am sure we cannot drop this. Perhaps, it makes sense to > separate the caching scenario in an explicit configuration and cache mode. > Probably, even separate cache and database cases. > > As for expiry policy - I agree that a user can always implement it on > application level, but a user can always implement transactions as well. If > we already have a feature and we can fix it properly, why not keep it? >
Re: Ignite 2.8 announcement plan
Pavel, Thanks for clarifying the way partition-awareness handles topology changes. Please publish your article as soon as you're ready. I plan to finish mine on Monday-Tuesday and will refer to yours. - Denis On Fri, Mar 6, 2020 at 1:36 AM Pavel Tupitsyn wrote: > Denis, thanks for the feedback! > When should I publish the post? Right after official release announcement, > or later? > > > I would use "thick client" as a term instead of the "classic client" > Good point, fixed > > > partition-awareness doesn't handle topology changes automatically > (partition map won't be updated on the client-side) > This is not true, we keep the partition map up to date by checking > AffinityTopologyVersion [1] > > > Now I can run Ignite.NET easily on my Mac OS machine > Just to clarify, you can do that since 2.4 release [2]. > In 2.8 we have refined build-related things (jar file handling), and made > sure that recent .NET versions are supported. > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > [2] https://habr.com/ru/company/gridgain/blog/347374/ (in Russian) > > On Fri, Mar 6, 2020 at 2:40 AM Denis Magda wrote: > > > Pavel, thanks, > > > > I enjoyed reading the blog, crystal clear and straight to the point! > Please > > consider these several items that might strengthen the article a bit: > > > >- I would use "thick client" as a term instead of the "classic client" > >(and mention that Ignite.NET client is a thick one). The thick client > is > >already a coined term that based on my observations are used a lot by > > dev > >and user communities. Also, you might add some differences of thick > vs. > >thin taking from this page - > > > > > https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients > >- Should we mention that presently partition-awareness doesn't handle > >topology changes automatically (partition map won't be updated on the > >client-side)? This might be a blocker for some users. > >- Excited to read about the cross-platform support, that's huge! Now I > >can run Ignite.NET easily on my Mac OS machine. I would insert a > > reference > >to updated documentation pages that explain how to start with > > Ignite.NET on > >various platforms. > > > > Hope, you will find this helpful, thanks for helping with project > > promotion! > > > > - > > Denis > > > > > > On Thu, Mar 5, 2020 at 7:32 AM Pavel Tupitsyn > > wrote: > > > > > Denis, > > > > > > The first post is going to be ready soon, probably by tomorrow. > > > Here is a draft, feedback welcome: > > > > > > > > > https://github.com/ptupitsyn/ptupitsyn.github.io/blob/ignite-2.8/_posts/2020-03-05-Whats-New-In-Ignite-Net-2.8.md > > > > > > On Wed, Mar 4, 2020 at 5:15 PM Denis Magda wrote: > > > > > > > Hi Pavel, > > > > > > > > Excellent! It will be good to publish the first article (what's new > in > > > > Ignite.NET 2.8) prior to a generic blog on blogs.apache.org so that > we > > > can > > > > link your post in for those who are looking for more details. Do you > > have > > > > any timeline in mind for this article? > > > > > > > > @Alexey Zinoviev , how about you preparing > > > several > > > > paragraphs for the blog highlighting the biggest changes in ML? The > > same > > > > highlighted content will be elaborated during the webinar. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Mar 4, 2020 at 2:29 AM Pavel Tupitsyn > > > > wrote: > > > > > > > > > Denis, I have a few blog posts on Ignite.NET planned: > > > > > > > > > > * What's new in Ignite.NET 2.8 (Thin Client Partition Awareness, > > > logging, > > > > > expiry policy, cluster API, .NET Core 3.x, Dockerfile) > > > > > * Ignite.NET performance improvements on .NET Core 3.x > > > > > * Ignite.NET Partition Awareness performance > > > > > * Fixing JNI thread leak in Ignite.NET > > > > > > > > > > What do you think? Should we have a schedule of some sorts? > > > > > > > > > > On Tue, Mar 3, 2020 at 9:58 PM Alexey Zinoviev < > > zaleslaw@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > Sounds ineresting, will help with the post, please share the > > > template, > > > > > not > > > > > > sure about webinar > > > > > > > > > > > > вт, 3 мар. 2020 г., 20:59 Denis Magda : > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > Let's discuss approaches for a global announcement/promotion of > > the > > > > > > > release. I would suggest focusing on a blog post and a > community > > > > > webinar. > > > > > > > > > > > > > > The blog post will introduce significant improvements (service > > > grid, > > > > > thin > > > > > > > clients, new metrics system, ML, etc.) sharing references to > > > > > > documentation > > > > > > > pages with more details. It will be published on > > blogs.apache.org > > > > in > > > > > a > > > > > > > format similar to this one - > > > > > > > https://blogs.apache.org/ignite/entry/apache
Re: Ignite 2.8 announcement plan
Denis, ok, I'll publish on Monday afternoon then (UTC), weekend is not the best time. Thanks, Pavel On Sat, Mar 7, 2020 at 1:25 AM Denis Magda wrote: > Pavel, > > Thanks for clarifying the way partition-awareness handles topology changes. > > Please publish your article as soon as you're ready. I plan to finish mine > on Monday-Tuesday and will refer to yours. > > - > Denis > > > On Fri, Mar 6, 2020 at 1:36 AM Pavel Tupitsyn > wrote: > > > Denis, thanks for the feedback! > > When should I publish the post? Right after official release > announcement, > > or later? > > > > > I would use "thick client" as a term instead of the "classic client" > > Good point, fixed > > > > > partition-awareness doesn't handle topology changes automatically > > (partition map won't be updated on the client-side) > > This is not true, we keep the partition map up to date by checking > > AffinityTopologyVersion [1] > > > > > Now I can run Ignite.NET easily on my Mac OS machine > > Just to clarify, you can do that since 2.4 release [2]. > > In 2.8 we have refined build-related things (jar file handling), and made > > sure that recent .NET versions are supported. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > [2] https://habr.com/ru/company/gridgain/blog/347374/ (in Russian) > > > > On Fri, Mar 6, 2020 at 2:40 AM Denis Magda wrote: > > > > > Pavel, thanks, > > > > > > I enjoyed reading the blog, crystal clear and straight to the point! > > Please > > > consider these several items that might strengthen the article a bit: > > > > > >- I would use "thick client" as a term instead of the "classic > client" > > >(and mention that Ignite.NET client is a thick one). The thick > client > > is > > >already a coined term that based on my observations are used a lot > by > > > dev > > >and user communities. Also, you might add some differences of thick > > vs. > > >thin taking from this page - > > > > > > > > > https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients > > >- Should we mention that presently partition-awareness doesn't > handle > > >topology changes automatically (partition map won't be updated on > the > > >client-side)? This might be a blocker for some users. > > >- Excited to read about the cross-platform support, that's huge! > Now I > > >can run Ignite.NET easily on my Mac OS machine. I would insert a > > > reference > > >to updated documentation pages that explain how to start with > > > Ignite.NET on > > >various platforms. > > > > > > Hope, you will find this helpful, thanks for helping with project > > > promotion! > > > > > > - > > > Denis > > > > > > > > > On Thu, Mar 5, 2020 at 7:32 AM Pavel Tupitsyn > > > wrote: > > > > > > > Denis, > > > > > > > > The first post is going to be ready soon, probably by tomorrow. > > > > Here is a draft, feedback welcome: > > > > > > > > > > > > > > https://github.com/ptupitsyn/ptupitsyn.github.io/blob/ignite-2.8/_posts/2020-03-05-Whats-New-In-Ignite-Net-2.8.md > > > > > > > > On Wed, Mar 4, 2020 at 5:15 PM Denis Magda > wrote: > > > > > > > > > Hi Pavel, > > > > > > > > > > Excellent! It will be good to publish the first article (what's new > > in > > > > > Ignite.NET 2.8) prior to a generic blog on blogs.apache.org so > that > > we > > > > can > > > > > link your post in for those who are looking for more details. Do > you > > > have > > > > > any timeline in mind for this article? > > > > > > > > > > @Alexey Zinoviev , how about you preparing > > > > several > > > > > paragraphs for the blog highlighting the biggest changes in ML? The > > > same > > > > > highlighted content will be elaborated during the webinar. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Wed, Mar 4, 2020 at 2:29 AM Pavel Tupitsyn < > ptupit...@apache.org> > > > > > wrote: > > > > > > > > > > > Denis, I have a few blog posts on Ignite.NET planned: > > > > > > > > > > > > * What's new in Ignite.NET 2.8 (Thin Client Partition Awareness, > > > > logging, > > > > > > expiry policy, cluster API, .NET Core 3.x, Dockerfile) > > > > > > * Ignite.NET performance improvements on .NET Core 3.x > > > > > > * Ignite.NET Partition Awareness performance > > > > > > * Fixing JNI thread leak in Ignite.NET > > > > > > > > > > > > What do you think? Should we have a schedule of some sorts? > > > > > > > > > > > > On Tue, Mar 3, 2020 at 9:58 PM Alexey Zinoviev < > > > zaleslaw@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Sounds ineresting, will help with the post, please share the > > > > template, > > > > > > not > > > > > > > sure about webinar > > > > > > > > > > > > > > вт, 3 мар. 2020 г., 20:59 Denis Magda : > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > Let's discuss approaches for a global announcement/promotion > of > > > the > > > > > > > > release. I would suggest focusing on
