Hi Denis, All the modules except OSGi have been migrated. Alexey is creating a separate ticket for OSGi and we can migrate the same as well.
My thoughts are Apache Ignite 2.9.0 and migrated extensions 1.0.0 to be released together. I am thinking depending on the voting process and testing cycles we can release the extensions 1.0.0 together with Apache Ignite 2.9.0 or right after within days of Apache Ignite 2.9.0 release. Regards, Saikat On Mon, Oct 12, 2020 at 2:58 PM Denis Magda <dma...@apache.org> wrote: > Saikat, Alex, > > Based on your inputs here, it sounds like once Ignite 2.9 gets released, > all the integrations that made their way to the extensions repo [1] will > get stuck in limbo for some time. What I mean here: > > 1. While the users will be bumping up their ignite-core, > ignite-indexing, etc. versions to 2.9, they won't find a 2.9 artifact for > Kafka, Camel and other extensions > 2. Also, the users won't find 1.0 versions of those extensions that > also need to be released > > So, it's unclear how those users are supposed to upgrade to Ignite 2.9 if > they use any of the extensions. Is it safe to use a 2.8 version of an > extension? Or, should we release the 1.0 versions of all the migrated > extensions together with 2.9? > > > [1] https://github.com/apache/ignite-extensions/tree/master/modules > > > - > 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? >> >> >>>>>>>>>>>>>>>>> >> >> >>>>>>>>>>>>>>>> >> >> >>>>>>>>>>>>> >> >> >>>>>>>>>>>> >> >> >>>>>>>>>>> >> >> >>>>>> >> >> >>>>> >> >> >>> >> >> >> >> >> >> >> >> >
