Alexey, For me, all three look quite critical as they: address a memory leak, address a usability/performance issue with no workaround, and address a regression in 2.8. If we want to limit the scope, I would still include the memory leak fix, though.
Thoughts? пн, 12 окт. 2020 г. в 13:07, Alex Plehanov <plehanov.a...@gmail.com>: > Guys, > > I've found 3 more tickets which were targeted to 2.9 but merged only to the > master branch ([1], [2], [3]). > Do we need these tickets in 2.9? Are they critical? > > [1]: https://issues.apache.org/jira/browse/IGNITE-12350 > [2]: https://issues.apache.org/jira/browse/IGNITE-13376 > [3]: https://issues.apache.org/jira/browse/IGNITE-13280 > > вс, 11 окт. 2020 г. в 16:11, Nikolay Izhikov <nizhi...@apache.org>: > > > Igniters, > > > > IGNITE-13553 fixed and cherry-picked to 2.9. > > We can continue with the release. > > > > > 10 окт. 2020 г., в 00:00, Denis Magda <dma...@apache.org> написал(а): > > > > > > Nikolay, > > > > > > re: the minor improvements. I'm not against of including those if we > can > > > prepare the docs before the vote starts. Presently, the docs are > "frozen" > > > for the 2.9 release, but I can scratch some time and take part in the > > docs > > > review the next week. > > > > > > - > > > Denis > > > > > > > > > On Fri, Oct 9, 2020 at 12:40 AM Nikolay Izhikov <nizhi...@apache.org> > > wrote: > > > > > >> Hello, Igniters. > > >> > > >> I prepared a patch [1] for blocker ticket [2] - «Server node fail and > > >> stops in case wrong datatype put in indexed field» > > >> Can someone, please, help me with the review? > > >> > > >> [1] https://github.com/apache/ignite/pull/8330 > > >> [2] https://issues.apache.org/jira/browse/IGNITE-13553 > > >> > > >> ================== > > >> > > >> I propose to include several minor tickets to the scope of the 2.9 > that > > >> increase Ignite User Experience > > >> > > >> CMD tools improvements: > > >> > > >> IGNITE-13488 - Command to print metric value > > >> IGNITE-13426 - Command to print system view content > > >> IGNITE-13422 - Parameter to explicitly enable experimental commands > > >> > > >> IGNITE-13380 - Output IgniteSystemProperties via ignite.sh > > >> > > >> New system views: > > >> > > >> IGNITE-13409 Metastorage and DistributedMetastorage viewы. > > >> IGNITE-13408 BinaryMetadata view. > > >> > > >>> 9 окт. 2020 г., в 04:04, Denis Magda <dma...@apache.org> написал(а): > > >>> > > >>> @Alex Plehanov <plehanov.a...@gmail.com>, > > >>> > > >>> If it still makes sense and not too late, you can cherry-pick the > > commit > > >>> with the new docs into the 2.9 branch: > > >>> > > >> > > > https://github.com/apache/ignite/commit/073488ac97517bbaad9f6b94b781fc404646f191 > > >>> > > >>> Anyway, it's not crucial as long as we agreed to make an exception > for > > >> this > > >>> release. The docs were already published to the website and assembled > > >> from > > >>> the master. Once the vote passes, I'll make them visible and > traceable > > >> from > > >>> the website menus. > > >>> > > >>> - > > >>> Denis > > >>> > > >>> > > >>> On Tue, Oct 6, 2020 at 7:20 AM Alexey Goncharuk < > > >> alexey.goncha...@gmail.com> > > >>> wrote: > > >>> > > >>>> Saikat, > > >>>> > > >>>> The plan sounds good to me! Do you have an idea for the timeline of > > the > > >>>> module releases? Let me know if I can help in any way. > > >>>> > > >>>> Also, I was looking into the modularization IEP and noticed that > OSGI > > >>>> module is discussed to be moved to the extensions, but there is no > > >>>> corresponding ticket. Should I create one? I will be happy to help > > with > > >>>> moving this module to extensions. > > >>>> > > >>>> вт, 29 сент. 2020 г. в 03:03, Saikat Maitra < > saikat.mai...@gmail.com > > >: > > >>>> > > >>>>> Hi Alexey, > > >>>>> > > >>>>> All the modules as planned in IEP-36 > > >>>>> > > >>>> > > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36:+Modularization > > >>>>> are migrated to ignite-extensions repository. > > >>>>> > > >>>>> We can definitely plan to release ignite-extensions modules. > > >>>>> > > >>>>> I have a pending PR related to the kafka module and the PR is in > > review > > >>>>> https://github.com/apache/ignite/pull/8222 but its corresponding > PR > > >> has > > >>>>> been merged in ignite-extensions repository. > > >>>>> > > >>>>> My thoughts / action items for the migration efforts and releases > > were > > >>>>> as follows: > > >>>>> > > >>>>> 1. Merge the changes for > https://github.com/apache/ignite/pull/8222 > > >>>>> 2. Fix the upload nightly packages task for ignite-core to help fix > > the > > >>>>> travis build failure in ignite-extensions repository. > > >>>>> 3. Review and update the README.md files for the ignite-extensions > > >>>> modules > > >>>>> as required. > > >>>>> 4. Update the docs for ignite-extensions modules in ignite-website. > > >>>>> 5. Release each module separately and share updates. > > >>>>> > > >>>>> Please let me know if you have feedback. > > >>>>> > > >>>>> Regards, > > >>>>> Saikat > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mon, Sep 28, 2020 at 7:36 AM Petr Ivanov <mr.wei...@gmail.com> > > >> wrote: > > >>>>> > > >>>>>> It seems that gitbox.apache.org is not available on CI/CD. > > >>>>>> > > >>>>>> I will try to update VCS to GitHub. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> On 28 Sep 2020, at 14:07, Alex Plehanov <plehanov.a...@gmail.com > > > > >>>>>> wrote: > > >>>>>>> > > >>>>>>> Guys, > > >>>>>>> > > >>>>>>> I've tried to build release candidate using TC [1]. But: > > >>>>>>> 1. I can't choose a branch in this TC task (there is no such > > field). > > >>>>>>> 2. On the "default" branch I got an error: Failed to collect > > changes, > > >>>>>>> error: List remote refs failed: > > >>>>>>> org.apache.http.conn.ConnectTimeoutException: Connect to > > >>>>>>> gitbox.apache.org:443 [gitbox.apache.org/52.202.80.70] failed: > > >>>> connect > > >>>>>>> timed out, VCS root: "GitBox [asf/ignite]" {instance id=300, > parent > > >>>>>>> internal id=74, parent id=GitBoxAsfIgnite, description: " > > >>>>>>> https://gitbox.apache.org/repos/asf/ignite.git#refs/heads/master > "} > > >>>>>>> > > >>>>>>> Is there some problem with this TC task? What am I doing wrong? > > >>>>>>> > > >>>>>>> [1] : > > >>>>>>> > > >>>>>> > > >>>> > > >> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild > > >>>>>>> > > >>>>>>> пн, 28 сент. 2020 г. в 13:15, Alexey Goncharuk < > > >>>>>> alexey.goncha...@gmail.com>: > > >>>>>>> > > >>>>>>>> Saikat, Nikolay, > > >>>>>>>> > > >>>>>>>> We have migrated a bunch of modules to ignite-extensions > recently. > > >>>>>> Given > > >>>>>>>> that these modules will not be available in Ignite 2.9 anymore > > (will > > >>>>>>>> they?), should we also plan to release the extensions? > > >>>>>>>> > > >>>>>>>> ср, 23 сент. 2020 г. в 21:49, Alex Plehanov < > > >> plehanov.a...@gmail.com > > >>>>> : > > >>>>>>>> > > >>>>>>>>> Igniters, > > >>>>>>>>> > > >>>>>>>>> I've prepared release notes for the 2.9 release [1]. Can anyone > > >>>> review > > >>>>>>>> it, > > >>>>>>>>> please? > > >>>>>>>>> > > >>>>>>>>> [1]: https://github.com/apache/ignite/pull/8273 > > >>>>>>>>> > > >>>>>>>>> вт, 22 сент. 2020 г. в 09:39, Alex Plehanov < > > >>>> plehanov.a...@gmail.com > > >>>>>>> : > > >>>>>>>>> > > >>>>>>>>>> Guys, > > >>>>>>>>>> > > >>>>>>>>>> I've filled the ticket with reproducer [1] for the discovery > > bug. > > >>>>>> This > > >>>>>>>>> bug > > >>>>>>>>>> caused by [2] ticket. We discussed with Vladimir Steshin > > privately > > >>>>>> and > > >>>>>>>>>> decided to revert this ticket. I will do it today (after TC > bot > > >>>> visa) > > >>>>>>>> if > > >>>>>>>>>> there are no objections. > > >>>>>>>>>> > > >>>>>>>>>> [1]: https://issues.apache.org/jira/browse/IGNITE-13465 > > >>>>>>>>>> [2]: https://issues.apache.org/jira/browse/IGNITE-13134 > > >>>>>>>>>> > > >>>>>>>>>> пн, 21 сент. 2020 г. в 11:08, Alex Plehanov < > > >>>> plehanov.a...@gmail.com > > >>>>>>> : > > >>>>>>>>>> > > >>>>>>>>>>> Guys, > > >>>>>>>>>>> > > >>>>>>>>>>> During internal testing, we've found a critical bug with > > >>>>>>>>>>> discovery (cluster falls apart if two nodes segmented > > >>>> sequentially). > > >>>>>>>>> This > > >>>>>>>>>>> problem is not reproduced in 2.8.1. I think we should fix it > > >>>>>>>>>>> before release. Under investigation now. I'll let you know > when > > >> we > > >>>>>> get > > >>>>>>>>>>> something. > > >>>>>>>>>>> > > >>>>>>>>>>> чт, 17 сент. 2020 г. в 00:51, Andrey Gura <ag...@apache.org > >: > > >>>>>>>>>>> > > >>>>>>>>>>>>> So what do you think? Should we proceed with a 'hacked' > > version > > >>>> of > > >>>>>>>>> the > > >>>>>>>>>>>> message factory in 2.9 and go for the runtime message > > generation > > >>>> in > > >>>>>>>>> later > > >>>>>>>>>>>> release, or keep the code clean and fix the regression in > the > > >>>> next > > >>>>>>>>> releases? > > >>>>>>>>>>>>> Andrey, can you take a look at my change? I think it is > > fairly > > >>>>>>>>>>>> straightforward and does not change the semantics, just > skips > > >> the > > >>>>>>>>> factory > > >>>>>>>>>>>> closures for certain messages. > > >>>>>>>>>>>> > > >>>>>>>>>>>> IMHO 2.5% isn't too much especially because it isn't actual > > for > > >>>> all > > >>>>>>>>>>>> workloads (I didn't get any significant drops during > > >>>> benchmarking). > > >>>>>>>> So > > >>>>>>>>>>>> I prefer the runtime generation in later releases. > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Mon, Sep 14, 2020 at 12:41 PM Alexey Goncharuk > > >>>>>>>>>>>> <alexey.goncha...@gmail.com> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Alexey, Andrey, Igniters, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> So what do you think? Should we proceed with a 'hacked' > > version > > >>>> of > > >>>>>>>>> the > > >>>>>>>>>>>> message factory in 2.9 and go for the runtime message > > generation > > >>>> in > > >>>>>>>>> later > > >>>>>>>>>>>> release, or keep the code clean and fix the regression in > the > > >>>> next > > >>>>>>>>> releases? > > >>>>>>>>>>>>> Andrey, can you take a look at my change? I think it is > > fairly > > >>>>>>>>>>>> straightforward and does not change the semantics, just > skips > > >> the > > >>>>>>>>> factory > > >>>>>>>>>>>> closures for certain messages. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Personally, I would prefer fixing the regression given that > > we > > >>>>>> also > > >>>>>>>>>>>> introduced tracing in this release. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> пт, 11 сент. 2020 г. в 12:09, Alex Plehanov < > > >>>>>>>> plehanov.a...@gmail.com > > >>>>>>>>>> : > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Alexey, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> We've benchmarked by yardstick commits 130376741bf vs > > >>>> ed52559eb95 > > >>>>>>>>> and > > >>>>>>>>>>>> the performance of ed52559eb95 is better for about 2.5% on > > >>>> average > > >>>>>> on > > >>>>>>>>> our > > >>>>>>>>>>>> environment (about the same results we got benchmarking > > 65c30ec6 > > >>>> vs > > >>>>>>>>>>>> 0606f03d). We've made 24 runs for each commit of > > >>>>>>>>>>>> IgnitePutTxImplicitBenchmark (we got maximum drop for 2.9 on > > >> this > > >>>>>>>>>>>> benchmark), 200 seconds warmup, 300 seconds benchmark, 6 > > >>>> servers, 5 > > >>>>>>>>> clients > > >>>>>>>>>>>> 50 threads each. Yardstick results for this configuration: > > >>>>>>>>>>>>>> Commit 130376741bf: avg TPS=164096, avg latency=9173464 ns > > >>>>>>>>>>>>>> Commit ed52559eb95: avg TPS=168283, avg latency=8945908 ns > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> пт, 11 сент. 2020 г. в 09:51, Artem Budnikov < > > >>>>>>>>>>>> a.budnikov.ign...@gmail.com>: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Hi Everyone, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I posted an instruction on how to publish the docs on > > >>>>>>>>>>>> ignite.apache.org/docs [1]. When you finish with Ignite > 2.9, > > >> you > > >>>>>> can > > >>>>>>>>>>>> update the docs by following the instruction. > Unfortunately, I > > >>>>>> won't > > >>>>>>>> be > > >>>>>>>>>>>> able to spend any time on this project any longer. You can > > send > > >>>>>> your > > >>>>>>>>> pull > > >>>>>>>>>>>> requests and questions about the documentation to Denis > Magda. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> -Artem > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> [1] : > > >>>>>>>>>>>> > > >>>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk < > > >>>>>>>>>>>> alexey.goncha...@gmail.com> wrote: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Alexey, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> I've tried to play with message factories locally, but > > >>>>>>>>>>>> unfortunately, I > > >>>>>>>>>>>>>>>> cannot spot the difference between old and new > > >> implementation > > >>>>>> in > > >>>>>>>>>>>>>>>> distributed benchmarks. I pushed an implementation of > > >>>>>>>>>>>> MessageFactoryImpl > > >>>>>>>>>>>>>>>> with the old switch statement to the > > ignite-2.9-revert-12568 > > >>>>>>>>> branch > > >>>>>>>>>>>>>>>> (discussed this with Andrey Gura, the change should be > > >>>>>>>> compatible > > >>>>>>>>>>>> with the > > >>>>>>>>>>>>>>>> new metrics as we still use the register() mechanics). > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Can you check if this change makes any difference > > >>>>>>>> performance-wise > > >>>>>>>>>>>> in your > > >>>>>>>>>>>>>>>> environment? If yes, we can go with runtime code > > generation > > >>>> in > > >>>>>>>> the > > >>>>>>>>>>>> long > > >>>>>>>>>>>>>>>> term: register classes and generate a dynamic message > > >> factory > > >>>>>>>> with > > >>>>>>>>>>>> a switch > > >>>>>>>>>>>>>>>> statement once all messages are registered (not in 2.9 > > >>>> though, > > >>>>>>>>>>>> obviously). > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> ср, 9 сент. 2020 г. в 14:53, Alex Plehanov < > > >>>>>>>>> plehanov.a...@gmail.com > > >>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Hello guys, > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> I've tried to optimize tracing implementation (ticket > > [1]), > > >>>> it > > >>>>>>>>>>>> reduced the > > >>>>>>>>>>>>>>>>> drop, but not completely removed it. > > >>>>>>>>>>>>>>>>> Ivan Rakov, Alexander Lapin, can you please review the > > >>>> patch? > > >>>>>>>>>>>>>>>>> Ivan Artiukhov, can you please benchmark the patch [2] > > >>>> against > > >>>>>>>>>>>> 2.8.1 > > >>>>>>>>>>>>>>>>> release on your environment? > > >>>>>>>>>>>>>>>>> With this patch on our environment, it's about a 3% > drop > > >>>> left, > > >>>>>>>>>>>> it's close > > >>>>>>>>>>>>>>>>> to measurement error and I think such a drop is not a > > >>>>>>>>>>>> showstopper. Guys, > > >>>>>>>>>>>>>>>>> WDYT? > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Also, I found that compatibility is broken for JDBC > thin > > >>>>>>>> driver > > >>>>>>>>>>>> between 2.8 > > >>>>>>>>>>>>>>>>> and 2.9 versions (ticket [3]). I think it's a blocker > and > > >>>>>>>> should > > >>>>>>>>>>>> be > > >>>>>>>>>>>>>>>>> fixed in 2.9. I've prepared the patch. > > >>>>>>>>>>>>>>>>> Taras Ledkov, can you please review this patch? > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> And one more ticket I propose to include into 2.9 [4] > > (NIO > > >>>>>>>>> message > > >>>>>>>>>>>>>>>>> send problem in some circumstances). I will cherry-pick > > it > > >>>> if > > >>>>>>>>>>>> there is no > > >>>>>>>>>>>>>>>>> objection. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-13411 > > >>>>>>>>>>>>>>>>> [2] https://github.com/apache/ignite/pull/8223 > > >>>>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/IGNITE-13414 > > >>>>>>>>>>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-13361 > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> пн, 7 сент. 2020 г. в 14:14, Maxim Muzafarov < > > >>>>>>>> mmu...@apache.org > > >>>>>>>>>> : > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Alexey, > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> I propose to include [1] issue to the 2.9 release. > Since > > >>>>>>>> this > > >>>>>>>>>>>> issue is > > >>>>>>>>>>>>>>>>>> related to the new master key change functionality > which > > >>>>>>>>>>>> haven't been > > >>>>>>>>>>>>>>>>>> released yet I think it will be safe to cherry-pick > > commit > > >>>>>>>> to > > >>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>> release branch. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> [1] > https://issues.apache.org/jira/browse/IGNITE-13390 > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> On Tue, 1 Sep 2020 at 12:13, Nikolay Izhikov < > > >>>>>>>>>>>> nizhi...@apache.org> > > >>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Hello, Igniters. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Alexey, please, include one more Python thin client > fix > > >>>>>>>> [1] > > >>>>>>>>>>>> into the > > >>>>>>>>>>>>>>>>> 2.9 > > >>>>>>>>>>>>>>>>>> release > > >>>>>>>>>>>>>>>>>>> It fixes kinda major issue - "Python client returns > > >> fields > > >>>>>>>>> in > > >>>>>>>>>>>> wrong > > >>>>>>>>>>>>>>>>>> order since the 2 row when fields_count>10" > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> [1] > https://issues.apache.org/jira/browse/IGNITE-12809 > > >>>>>>>>>>>>>>>>>>> [2] > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> 31 авг. 2020 г., в 19:23, Alexey Goncharuk < > > >>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com> > > >>>>>>>>>>>>>>>>>> написал(а): > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Alexey, thanks, got it. I am not sure we can > optimize > > >>>>>>>>>>>> anything out of > > >>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>> message factory with suppliers (at least I have no > > ideas > > >>>>>>>>>>>> right now), > > >>>>>>>>>>>>>>>>> so > > >>>>>>>>>>>>>>>>>>>> most likely the only move here is to switch back to > > the > > >>>>>>>>>>>> switch > > >>>>>>>>>>>>>>>>> approach > > >>>>>>>>>>>>>>>>>>>> somehow preserving the metrics part. Probably, > > inlining > > >>>>>>>>> the > > >>>>>>>>>>>> Ignite > > >>>>>>>>>>>>>>>>>> messages > > >>>>>>>>>>>>>>>>>>>> to the IgniteMessageFactoryImpl should do the trick. > > Let > > >>>>>>>>> me > > >>>>>>>>>>>> explore > > >>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>> code a bit. > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> P.S. I am surprised by the impact this part makes > for > > >>>>>>>> the > > >>>>>>>>>>>>>>>>> performance. > > >>>>>>>>>>>>>>>>>>>> Message creation is indeed on the hot path, but a > > single > > >>>>>>>>>>>> virtual call > > >>>>>>>>>>>>>>>>>>>> should not make that much of a difference given the > > >>>>>>>> amount > > >>>>>>>>>>>> of other > > >>>>>>>>>>>>>>>>>> work > > >>>>>>>>>>>>>>>>>>>> happening during the message processing. > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> пн, 31 авг. 2020 г. в 18:33, Alex Plehanov < > > >>>>>>>>>>>> plehanov.a...@gmail.com > > >>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Alexey, sorry, I wrongly interpreted our benchmark > > >>>>>>>>> results. > > >>>>>>>>>>>>>>>>> Actually, > > >>>>>>>>>>>>>>>>>> we > > >>>>>>>>>>>>>>>>>>>>> were looking for a drop using bi-sect in the range > > >>>>>>>>> between > > >>>>>>>>>>>> e6a7f93 > > >>>>>>>>>>>>>>>>>> (first > > >>>>>>>>>>>>>>>>>>>>> commit in the 2.9 branch after 2.8 branch cut) and > > >>>>>>>>>>>> 6592dfa5 (last > > >>>>>>>>>>>>>>>>>> commit in > > >>>>>>>>>>>>>>>>>>>>> the 2.9 branch). And we found these two problematic > > >>>>>>>>>>>> commits. > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Perhaps only IGNITE-13060 (Tracing) is responsible > > for > > >>>>>>>> a > > >>>>>>>>>>>> drop > > >>>>>>>>>>>>>>>>> between > > >>>>>>>>>>>>>>>>>>>>> 2.8.1 and 2.9 (we have benchmarked 2.8.1 vs 2.9 > with > > >>>>>>>>>>>> reverted > > >>>>>>>>>>>>>>>>>> IGNITE-13060 > > >>>>>>>>>>>>>>>>>>>>> now and performance looks the same) > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Ticket IGNITE-12568 (MessageFactory refactoring) is > > not > > >>>>>>>>>>>> related to > > >>>>>>>>>>>>>>>>>> drop > > >>>>>>>>>>>>>>>>>>>>> between 2.8.1 and 2.9, but still has some > performance > > >>>>>>>>>>>> problem, and > > >>>>>>>>>>>>>>>>> we > > >>>>>>>>>>>>>>>>>> can > > >>>>>>>>>>>>>>>>>>>>> win back IGNITE-13060 drop by this ticket. > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Do we need more investigation on IGNITE-13060 or we > > >>>>>>>> leave > > >>>>>>>>>>>> it as is? > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> What should we do with IGNITE-12568 (MessageFactory > > >>>>>>>>>>>> refactoring)? > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk < > > >>>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Alexey, > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> While investigating, I found that IGNITE-12568 has > > an > > >>>>>>>>>>>> incorrect fix > > >>>>>>>>>>>>>>>>>>>>>> version and is actually present in ignite-2.8.1 > > branch > > >>>>>>>>>>>> [1], so it > > >>>>>>>>>>>>>>>>>> cannot be > > >>>>>>>>>>>>>>>>>>>>>> the source of the drop against 2.8.1. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> P.S. Looks like we need to enforce a more accurate > > >>>>>>>> work > > >>>>>>>>>>>> with fix > > >>>>>>>>>>>>>>>>>> versions > > >>>>>>>>>>>>>>>>>>>>>> or develop some sort of tooling to verify the fix > > >>>>>>>>>>>> versions. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> --AG > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> [1] > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34 > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk < > > >>>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov < > > >>>>>>>>>>>>>>>>> plehanov.a...@gmail.com > > >>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> Guys, > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> We have benchmarked 2.9 without IGNITE-13060 and > > >>>>>>>>>>>> IGNITE-12568 > > >>>>>>>>>>>>>>>>>> (reverted > > >>>>>>>>>>>>>>>>>>>>>>>> it > > >>>>>>>>>>>>>>>>>>>>>>>> locally) and got the same performance as on > 2.8.1 > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> IGNITE-13060 (Tracing) - some code was added to > > hot > > >>>>>>>>>>>> paths, to > > >>>>>>>>>>>>>>>>> trace > > >>>>>>>>>>>>>>>>>>>>>>>> these > > >>>>>>>>>>>>>>>>>>>>>>>> hot paths, it's clear why we have performance > drop > > >>>>>>>>> here. > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> IGNITE-12568 (MessageFactory refactoring) - > > >>>>>>>>> switch/case > > >>>>>>>>>>>> block was > > >>>>>>>>>>>>>>>>>>>>>>>> refactored to an array of message suppliers. The > > >>>>>>>>>>>> message factory > > >>>>>>>>>>>>>>>>>> is on > > >>>>>>>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>>>>>> hot path, which explains why this commit has an > > >>>>>>>> impact > > >>>>>>>>>>>> on total > > >>>>>>>>>>>>>>>>>>>>>>>> performance. > > >>>>>>>>>>>>>>>>>>>>>>>> I've checked JIT assembly output, done some JMH > > >>>>>>>>>>>> microbenchmarks, > > >>>>>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>>>>>>>>> found > > >>>>>>>>>>>>>>>>>>>>>>>> that old implementation of > MessageFactory.create() > > >>>>>>>>>>>> about 30-35% > > >>>>>>>>>>>>>>>>>> faster > > >>>>>>>>>>>>>>>>>>>>>>>> than > > >>>>>>>>>>>>>>>>>>>>>>>> the new one. The reason - approach with > > switch/case > > >>>>>>>>> can > > >>>>>>>>>>>>>>>>> effectively > > >>>>>>>>>>>>>>>>>>>>>>>> inline > > >>>>>>>>>>>>>>>>>>>>>>>> message creation code, but with an array of > > >>>>>>>> suppliers > > >>>>>>>>>>>> relatively > > >>>>>>>>>>>>>>>>>> heavy > > >>>>>>>>>>>>>>>>>>>>>>>> "invokeinterface" cannot be skipped. I've tried > to > > >>>>>>>>>>>> rewrite the > > >>>>>>>>>>>>>>>>> code > > >>>>>>>>>>>>>>>>>>>>>>>> using > > >>>>>>>>>>>>>>>>>>>>>>>> an abstract class for suppliers instead of an > > >>>>>>>>> interface > > >>>>>>>>>>>> (to > > >>>>>>>>>>>>>>>>>>>>>>>> replace "invokeinterface" with the > > "invokevirtual"), > > >>>>>>>>>>>> but it gives > > >>>>>>>>>>>>>>>>>> back > > >>>>>>>>>>>>>>>>>>>>>>>> only > > >>>>>>>>>>>>>>>>>>>>>>>> 10% of method performance and in this case, code > > >>>>>>>> looks > > >>>>>>>>>>>> ugly > > >>>>>>>>>>>>>>>>>> (lambdas > > >>>>>>>>>>>>>>>>>>>>>>>> can't > > >>>>>>>>>>>>>>>>>>>>>>>> be used). Currently, I can't find any more ways > to > > >>>>>>>>>>>> optimize the > > >>>>>>>>>>>>>>>>>> current > > >>>>>>>>>>>>>>>>>>>>>>>> approach (except return to the switch/case > block). > > >>>>>>>>>>>> Andrey Gura, > > >>>>>>>>>>>>>>>>> as > > >>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>>>>>> author of IGNITE-12568, maybe you have some > ideas > > >>>>>>>>> about > > >>>>>>>>>>>>>>>>>> optimization? > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> Perhaps we should revert IGNITE-12568, but there > > are > > >>>>>>>>>>>> some metrics > > >>>>>>>>>>>>>>>>>>>>>>>> already > > >>>>>>>>>>>>>>>>>>>>>>>> created, which can't be rewritten using old > > message > > >>>>>>>>>>>> factory > > >>>>>>>>>>>>>>>>>>>>>>>> implementation > > >>>>>>>>>>>>>>>>>>>>>>>> (IGNITE-12756). Guys, WDYT? > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> Alexey, > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> I see that IGNITE-12756 (metrics improvements) is > > >>>>>>>>>>>> already released > > >>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>>> Ignite 2.8.1 while IGNITE-12568 (message factory) > > is > > >>>>>>>>>>>> only present > > >>>>>>>>>>>>>>>>>> in Ignite > > >>>>>>>>>>>>>>>>>>>>>>> 2.9. Let's revert both IGNITE-12568 and whichever > > new > > >>>>>>>>>>>> metrics > > >>>>>>>>>>>>>>>>>> created for > > >>>>>>>>>>>>>>>>>>>>>>> 2.9 that depend on the new message factory to > > unblock > > >>>>>>>>>>>> the release > > >>>>>>>>>>>>>>>>>> and deal > > >>>>>>>>>>>>>>>>>>>>>>> with the optimizations in 2.10? > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>> > > >> > > >> > > > > >