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? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >> > >
