Re: Re[2]: NUMA aware allocator, PR review request

Thanks all for review, merged into master. пн, 6 дек. 2021 г. в 23:26, Ivan Daschinsky : > You are not wrong, it is built from source, every night. And every TC run. > I don't understand why numa allocator cannot be treated the same. Moreover, > it is built using maven, with maven plugin and

Re: Re[2]: NUMA aware allocator, PR review request

You are not wrong, it is built from source, every night. And every TC run. I don't understand why numa allocator cannot be treated the same. Moreover, it is built using maven, with maven plugin and just needs gcc and libnuma-dev. All of theese are already on TC agents and build are ready. I didn't

Re: Re[2]: NUMA aware allocator, PR review request

Hello! Maybe I am wrong, but ODBC installer is built from source and may be improved from release to release. Regards, -- Ilya Kasnacheev пн, 6 дек. 2021 г. в 20:41, Ivan Daschinsky : > Only one reason -- nowadays amost all hardware platforms uses NUMA > > Another reason -- there is no any

Re: Re[2]: NUMA aware allocator, PR review request

Only one reason -- nowadays amost all hardware platforms uses NUMA Another reason -- there is no any release process of extensions. BTW, apache ignite release is shipped with odbc binary installer for windows. And nobody complains about it. But may be listen to others? пн, 6 дек. 2021 г.,

Re: Re[2]: NUMA aware allocator, PR review request

Any reason to release the same cpp sources for each release? Any reason to increase the requirements amount for each new release? Any reason to increase release complexity and duration? All answers are "definitely no" What we should do is to release cpp part once and use it as a dependency.

Re[2]: NUMA aware allocator, PR review request

+1 with Ivan, let`s store it in core product just because it looks like  inalienable functionality and release cycle of extensions a little bit different.   >Anton, I disagree. > >1. This should be released with main distro. >2. This should not be abandoned. >3. There is not any release

Re: NUMA aware allocator, PR review request

Anton, I disagree. 1. This should be released with main distro. 2. This should not be abandoned. 3. There is not any release process in ignite-extensions. 4. Everything is working now and working good. So lets do not do this :) пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov : > Let's move all

Re: NUMA aware allocator, PR review request

Let's move all GCC-related parts to ignite-extensions, release, and use them as a maven dependency. On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky wrote: > Ok, TC suite is ready [1]. > If there is no objections, I will merge it soon. > > Possible concerns -- now it is required to install

Re: NUMA aware allocator, PR review request

Ok, TC suite is ready [1]. If there is no objections, I will merge it soon. Possible concerns -- now it is required to install build-essentials and libnuma-dev in order to build ignite on 64 bit linux. I suppose that this is not a big deal, but maybe someone will contradict? [1] --

Re: NUMA aware allocator, PR review request

>> Our runs show about 7-10 speedup, Sorry, typo 7-10% speedup чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky : > Andrey, thanks! > > This allocator can be tested on every NUMA system. > Our runs show about 7-10 speedup, if we use allocattor with interleaved > strategy + -XX:+UseNUMA. > But

Re: NUMA aware allocator, PR review request

Andrey, thanks! This allocator can be tested on every NUMA system. Our runs show about 7-10 speedup, if we use allocattor with interleaved strategy + -XX:+UseNUMA. But unfortunately our yardstick benches doesn't use offheap a lot, usually above one Gb. We trying to do more benches with real data

Re: NUMA aware allocator, PR review request

Ivan, Great job. PR looks good. This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to jvm > show promising results on yardstick benches. Technically, G1 is not a numa > aware collector for java versions less than 14, but allocation of heap in > interleaved mode shows good results

Re: NUMA aware allocator, PR review request

Semyon D. and Maks T. -- thanks a lot for review. BTW, Igniters, I will appreciate all opinions and feedback. пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky : > Hi, igniters! > > There is not a big secret that nowadays NUMA is quite common in > multiprocessor systems. > And this memory

NUMA aware allocator, PR review request

Hi, igniters! There is not a big secret that nowadays NUMA is quite common in multiprocessor systems. And this memory architecture should be treated in specific ways. Support for NUMA is present in many commercial and open-source products. I've implemented a NUMA aware allocator for Apache

Review request - allocated RAM is always 0 for non-persistent regions

Hello! Guys, can you please review https://issues.apache.org/jira/browse/IGNITE-13878 ? I could not find a reviewer for this ticket. Regards, -- Ilya Kasnacheev

Re: Review Request: IGNITE-8635: Add a Method to Inspect BinaryObject Size

Gentle ping On Thu, 11 Mar 2021 at 2:56 PM, Atri Sharma wrote: > Hi All, > > I have raised a PR for the above mentioned issue. Please see and help > review: > > https://github.com/apache/ignite/pull/8868 > > Regards, > > Atri > > -- > Regards, > > Atri > Apache Concerted > -- Regards, Atri

Review Request: IGNITE-8635: Add a Method to Inspect BinaryObject Size

Hi All, I have raised a PR for the above mentioned issue. Please see and help review: https://github.com/apache/ignite/pull/8868 Regards, Atri -- Regards, Atri Apache Concerted

Re: Review Request

Atri, I've added my comments in the PR. -Val On Wed, Mar 3, 2021 at 7:29 AM Denis Magda wrote: > @Valentin Kulichenko , @Nikolay Izhikov > , @samvi...@yandex.ru , > > I saw you reviewing the ticket. Could you please double-check the changes? > "IGNITE-2399: Implement acquireAndExecute In

Re: Review Request

@Valentin Kulichenko , @Nikolay Izhikov , @samvi...@yandex.ru , I saw you reviewing the ticket. Could you please double-check the changes? "IGNITE-2399: Implement acquireAndExecute In IgniteSemaphore" Atri, please put a ticket number and name in the title of an email, so that community member

Review Request

Hi, Please help in reviewing: https://github.com/apache/ignite/pull/8820 Atri

Re: [REVIEW REQUEST] IEP-47 Native Persistence Defragmentation, core logic

But maybe I just don't know the date. To be short - right now defragmentation is my first priority. вт, 17 нояб. 2020 г. в 15:18, Ivan Bessonov : > Denis, > > chances that feature will be fully complete is a bit low. We still make > adjustments to the API > and we need a few optimizations so

Re: [REVIEW REQUEST] IEP-47 Native Persistence Defragmentation, core logic

Denis, chances that feature will be fully complete is a bit low. We still make adjustments to the API and we need a few optimizations so that it would work faster. чт, 12 нояб. 2020 г. в 19:11, Denis Magda : > Ivan, > > Nice! Is the plan to get it added to Ignite 2.10? > > - > Denis > > > On

Re: [REVIEW REQUEST] IEP-47 Native Persistence Defragmentation, core logic

Ivan, Nice! Is the plan to get it added to Ignite 2.10? - Denis On Thu, Nov 12, 2020 at 7:11 AM Ivan Bessonov wrote: > Hi Igniters, > > Core functionality of defragmentation is finally implemented in [1]. > There's no public API in it > for now, patch is already very big and had to be split

[REVIEW REQUEST] IEP-47 Native Persistence Defragmentation, core logic

Hi Igniters, Core functionality of defragmentation is finally implemented in [1]. There's no public API in it for now, patch is already very big and had to be split into smaller tasks (that consist mostly of refactoring). Code is a little rough right now, I'm gonna go through all the remaining

Re: [REVIEW REQUEST] IGNITE-12630 Remove developers sections from parent pom.xml

Merged to master. Best regards, Ivan Pavlukhin чт, 6 февр. 2020 г. в 11:57, Anton Vinogradov : > > Looks good to me. > > On Thu, Feb 6, 2020 at 11:45 AM Ivan Pavlukhin wrote: > > > Igniters, > > > > I raised a PR for a ticket [1] removing section from > > parent pom.xml. I described the

Re: [REVIEW REQUEST] IGNITE-12630 Remove developers sections from parent pom.xml

Looks good to me. On Thu, Feb 6, 2020 at 11:45 AM Ivan Pavlukhin wrote: > Igniters, > > I raised a PR for a ticket [1] removing section from > parent pom.xml. I described the motivation in the ticket. Shortly, > this section has a little meaning today and even worse is misleading. > > Please

[REVIEW REQUEST] IGNITE-12630 Remove developers sections from parent pom.xml

Igniters, I raised a PR for a ticket [1] removing section from parent pom.xml. I described the motivation in the ticket. Shortly, this section has a little meaning today and even worse is misleading. Please review. [1] https://issues.apache.org/jira/browse/IGNITE-12630 Best regards, Ivan

Re: Read Repair (ex. Consistency Check) - review request #2

> > > > > > > > > > >> Anyway, I left some comments in your pull-request at > > github. > > > > > > Please > > > > > > > > take > > > > > > > > > a

Re: Read Repair (ex. Consistency Check) - review request #2

to propose you to provide fixes as a PR since you > have a > > > > > > vision > > > > > > > of > > > > > > > > how it should be made. I'll review them and merge shortly. &g

Re: Read Repair (ex. Consistency Check) - review request #2

t; > > > > > modifications > > > > > > > and restarts [1]. > > > > > > > > > > > > > > >> I just checked, the IEP page and I still cannot find Jira > > > tickets > > > >

Re: Read Repair (ex. Consistency Check) - review request #2

- not sure near support really required, > > > > > > - metrics are better for monitoring, but the Event is enough for > my > > > > wish > > > > > to > > > > > > cover AI with consistency check, > > > > > > - do we really need Platforms an

Re: Read Repair (ex. Consistency Check) - review request #2

proxy creation method and they definitely > > are > > > > not > > > > > showstoppers and may be fixed later if someone interested. > > > > > Сoming back to AI 3.0 discussion, we have A LOT of features and > it's > > > > almost &

Re: Read Repair (ex. Consistency Check) - review request #2

the recovery too > > > > Do you mean per partition check and recovery? > > > > That's a good idea, but I found it's not easy to imagine API to for > > such > > > > tool. > > > > In case you ready to assist with proper API/design this will > def

Re: Read Repair (ex. Consistency Check) - review request #2

ine API to for > such > > > tool. > > > In case you ready to assist with proper API/design this will definitely > > > help. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11973 > > > > > > On Wed, Jul 10, 2019 at 3:43 PM

Re: Read Repair (ex. Consistency Check) - review request #2

s, it would be a good idea to think about the recovery tool/ > > > control-utility command that will allow achieving the same goal. > > > If I am not mistaken it was already proposed in the email thread. > > > > > > Thanks, > > > S. > > > > > &

Re: Read Repair (ex. Consistency Check) - review request #2

mistaken it was already proposed in the email thread. > > > > Thanks, > > S. > > > > ср, 10 июл. 2019 г. в 15:33, Вячеслав Коптилин >: > > > > > Hi Anton, > > > > > > Well, the ReadRepair feature is finally merged and that is good news :) >

Re: [REVIEW REQUEST] IGNITE-11951 Improvements in JdkMarshaller

Merged the patch to master [1]. Thank Alex Plekhanov for a review. [1] https://issues.apache.org/jira/browse/IGNITE-11951 ср, 10 июл. 2019 г. в 08:42, Павлухин Иван : > > Hi, > > I made some small improvements in JdkMarshaller [1]. I will be happy > if someone reviews it. Changes are quite

Re: Read Repair (ex. Consistency Check) - review request #2

ommand that will allow achieving the same goal. > > > If I am not mistaken it was already proposed in the email thread. > > > > > > Thanks, > > > S. > > > > > > ср, 10 июл. 2019 г. в 15:33, Вячеслав Коптилин < > slava.kopti...@gmail.com>

Re: Read Repair (ex. Consistency Check) - review request #2

goal. > > If I am not mistaken it was already proposed in the email thread. > > > > Thanks, > > S. > > > > ср, 10 июл. 2019 г. в 15:33, Вячеслав Коптилин : > > > > > Hi Anton, > > > > > > Well, the ReadRepair feature is fina

Re: Read Repair (ex. Consistency Check) - review request #2

; Unfortunately, I cannot find a consensus about the whole functionality in > > any of these topics: > > - > > > http://apache-ignite-developers.2346864.n4.nabble.com/Consistency-check-and-fix-review-request-td41629.html > > - > > > http://apache-ignite-developers.2346864.n4.n

Re: Read Repair (ex. Consistency Check) - review request #2

eadRepair feature is finally merged and that is good news :) > > Unfortunately, I cannot find a consensus about the whole functionality in > any of these topics: > - > http://apache-ignite-developers.2346864.n4.nabble.com/Consistency-check-and-fix-review-request-td41629.html >

Re: Read Repair (ex. Consistency Check) - review request #2

Hi Anton, Well, the ReadRepair feature is finally merged and that is good news :) Unfortunately, I cannot find a consensus about the whole functionality in any of these topics: - http://apache-ignite-developers.2346864.n4.nabble.com/Consistency-check-and-fix-review-request-td41629.html - http

Re: Read Repair (ex. Consistency Check) - review request #2

Folks, Thanks to everyone for tips and reviews. Yardstick checked, no performance drop found. Additional measurement: RR get() is just up to 7% slower than regular get on real benchmarks (8 clients, 4 servers, 3 backups) Code merged to the master. "Must have" tasks created and attached to the

[REVIEW REQUEST] IGNITE-11951 Improvements in JdkMarshaller

Hi, I made some small improvements in JdkMarshaller [1]. I will be happy if someone reviews it. Changes are quite simple. [1] https://issues.apache.org/jira/browse/IGNITE-11951 -- Best regards, Ivan Pavlukhin

Re: Read Repair (ex. Consistency Check) - review request #2

Folks, Just a minor update. RunAll [1] with enabled ReadRepair proxy is almost green now (~10 tests left, started with 6k :)). During the analisys, I've found some tests with - unexpected repairs at tx caches - inconsistent state after the test finished (different entries across the topology)

Re: Read Repair (ex. Consistency Check) - review request #2

Slava, >> I will take a look at your pull request if you don't mind. Great news! >> In any way, could you please update the IEP page with the list of >> constraints/limitations of the proposed approach, TODOs, etc? Not sure we should keep this at IEP until list (#4 from original letter) is not

Re: Read Repair (ex. Consistency Check) - review request #2

Hi Anton, I will take a look at your pull request if you don't mind. In any way, could you please update the IEP page with the list of constraints/limitations of the proposed approach, TODOs, etc? For instance, I would like to see all these limitations on the IEP page as JIRA tickets. Perhaps,

Re: Read Repair (ex. Consistency Check) - review request #2

Nikolay, >> Should we consider it's removal in Ignite 3 Don't think so. My initial ReadRepair implementation uses version to detect inconsistency. Strategy can be changed later (most likely it will) or even provided ability to use own strategy. Data streamer's and cache.load's cases can be

Re: Read Repair (ex. Consistency Check) - review request #2

Anton. I worried about this limitation: > Entries streamed using data streamer (using not a "cache.put" based updater) > and loaded by cache.load. As we discussed privately in this modes *ALL ENTRIES ON ALL OWNERS WILL HAVE DIFFERENT VERSIONS* Why we need this modes, in the first place?

Read Repair (ex. Consistency Check) - review request #2

Igniters, I'm glad to introduce Read Repair feature [0] provides additional consistency guarantee for Ignite. 1) Why we need it? The detailed explanation can be found at IEP-31 [1]. In short, because of bugs, it's possible to gain an inconsistent state. We need additional features to handle this

Re: Consistency check and fix (review request)

Ivan, 1) Currently, we have idle_verify [1] feature allows us to check consistency guarantee is still respected. But, idle_verify has a big constraint, the cluster should be at idle mode (no load). This feature, actually, will do almost the same but allows you to have any load. 2) Why we need

Re: Consistency check and fix (review request)

Hi Anton, Meanwhile can we extend a feature description from a user point of view? It would be good to provide some use cases when it can used. The thing that is yet understood by me is a conflict resolving. E.g. in systems inspired by Dynamo (sorry that no references, writing from phone)

Re: Consistency check and fix (review request)

Folks, Just an update. According to all your tips I decided to refactor API, logic, and approach (mostly everything :)), so, currently refactoring is in progress and you may see inconsistent PR state. Thanks to everyone involved for your tips, review and etc. I'll provide a proper presentation

Re: Consistency check and fix (review request)

Nikolay, that was the first approach >> I think we should allow to the administrator to enable/disable Consistency check. In that case, we have to introduce cluster-wide change-strategy operation, since every client node should be aware of the change. Also, we have to specify caches list, and for

Re: Consistency check and fix (review request)

Hello, Anton. > Customer should be able to change strategy on the fly according to time> > periods or load. I think we should allow to administrator to enable/disable Consistency check. This option shouldn't be related to application code because "Consistency check" is some kind of maintance

Re: Consistency check and fix (review request)

Andrey, thanks for tips >> You can perform consistency check using idle verify utility. Could you please point to utility's page? According to its name, it requires to stop the cluster to perform the check? That's impossible at real production when you should have downtime less that some minutes

Re: Consistency check and fix (review request)

Anton, Thank you for your effort for improving consistency guarantees provided by Ignite. The subject sounds really vital. Could you please elaborate why it comes as an on-demand enabled proxy but not as a mode enabled by some configuration property (or even as a default behavior)? How do you

Re: Consistency check and fix (review request)

Anton, I'm trying tell you that this proxy can produce false positive result, incorrect result and just hide bugs. What will the next solution? withNoBugs proxy? You can perform consistency check using idle verify utility. Recovery tool is good idea but user should trigger this process, not some

Re: Consistency check and fix (review request)

Seems, we already fixed all bugs caused this feature, but there is no warranty we will not create new :) This proxy is just checker that consistency is ok. >> reaching bugless implementation Not sure it's possible. Once you have software it contains bugs. This proxy will tell you whether these

Re: Consistency check and fix (review request)

Method name is minor problem. I still believe that there is no need for this proxy because there are no any guarantees about bugless implementation this functionality. Better way is reaching bugless implementation of current functionality. On Mon, Apr 15, 2019 at 4:51 PM Anton Vinogradov wrote:

Re: Consistency check and fix (review request)

Andrey, >> It means also that at least method name is bad. Agreed, already discussed with Aleksey Plekhanov. Decided that ".withConsistencyCheck()" is a proper name. >> What is the profit? This proxy allows to check (and fix) is there any consistency violation across the topology. The proxy will

Re: Consistency check and fix (review request)

Anton, what does expression "withConsistency" mean? From user's standpoint it means that all operations performed without this proxy are not consistent. It means also that at least method name is bad. Are there any guarantees that withConsistency proxy will not contain bugs that will lead to

Re: Consistency check and fix (review request)

Folks, I've checked the tx benchmarks and found no performance drop. Also, see no issues at TC results. So, seems, code ready to be merged. Everyone interested, please share any objections about - public API - test coverage - implementation approach On Wed, Apr 3, 2019 at 5:46 PM Anton

Re: Consistency check and fix (review request)

Hello, Anton. Thanks for the PoC. > finds correct values according to LWW strategy Can you, please, clarify what is LWW strategy? В Ср, 03/04/2019 в 17:19 +0300, Anton Vinogradov пишет: > Ilya, > > This is impossible due to a conflict between some isolation levels and > get-with-consistency

Re: Consistency check and fix (review request)

Ilya, This is impossible due to a conflict between some isolation levels and get-with-consistency expectations. Basically, it's impossible to perform get-with-consistency after the other get at !READ_COMMITTED transaction. The problem here is that value should be cached according to the isolation

Re: Consistency check and fix (review request)

Hello! Sounds useful especially for new feature development. Can you do a run of all tests with cache.forConsistency(), see if there are cases that fail? Regards, -- Ilya Kasnacheev ср, 3 апр. 2019 г. в 16:17, Anton Vinogradov : > Igniters, > > Sometimes, at real deployment, we're faced

Consistency check and fix (review request)

Igniters, Sometimes, at real deployment, we're faced with inconsistent state across the topology. This means that somehow we have different values for the same key at different nodes. This is an extremely rare situation, but, when you have thousands of terabytes of data, this can be a real

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Dmitry, Thanks for pointing this out. Fixed in master and 2.6. -Val On Sat, Jun 23, 2018 at 10:49 AM Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Valentin, > > Seems that these changes have classes without license head. TC link >

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Valentin, Seems that these changes have classes without license head. TC link

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Great, thanks! As always, happy to contribute! Thanks, Amir On Fri, Jun 22, 2018 at 7:32 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Amir, > > I merged you change to master and 2.6. Thanks! > > -Val > > On Fri, Jun 22, 2018 at 4:21 PM Amir Akhmedov > wrote: > >> Val, >> I

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Amir, I merged you change to master and 2.6. Thanks! -Val On Fri, Jun 22, 2018 at 4:21 PM Amir Akhmedov wrote: > Val, > I replied to it already :) > > Thanks, > Amir > > > On Fri, Jun 22, 2018 at 7:20 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Amir, >> >> Thanks for

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Val, I replied to it already :) Thanks, Amir On Fri, Jun 22, 2018 at 7:20 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Amir, > > Thanks for quick reaction. I added a follow up question in the ticket. > > -Val > > On Fri, Jun 22, 2018 at 3:48 PM Amir Akhmedov > wrote: > >>

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Amir, Thanks for quick reaction. I added a follow up question in the ticket. -Val On Fri, Jun 22, 2018 at 3:48 PM Amir Akhmedov wrote: > Hi Val, > Thanks for your comments. I replied in the ticket with my vision of the > issue and how I tried to solve it. Please check it and let me know. > >

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Hi Val, Thanks for your comments. I replied in the ticket with my vision of the issue and how I tried to solve it. Please check it and let me know. Thanks, Amir On Fri, Jun 22, 2018 at 5:42 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Amir, > > I reviewed the changes and

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Hi Amir, I reviewed the changes and I'm not sure I understood how they fix they issue. I left more detailed comment in the ticket, can you please clarify? -Val On Fri, Jun 22, 2018 at 9:53 AM Dmitry Pavlov wrote: > Hi Amir, > > let me say sincere thank you for continuing to contribute. > >

Re: Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Hi Amir, let me say sincere thank you for continuing to contribute. Bumping up this thread. Igniters, who has an expertise here? вс, 17 июн. 2018 г. в 17:59, Amir Akhmedov : > Hi All, > Can you please review my changes for IGNITE-8740. > > PR: https://github.com/apache/ignite/pull/4208 > TC:

Review request for IGNITE-8740: Support reuse of already initialized Ignite in IgniteSpringBean

Hi All, Can you please review my changes for IGNITE-8740. PR: https://github.com/apache/ignite/pull/4208 TC: https://ci.ignite.apache.org/viewLog.html?buildId=1397283=buildResultsDiv=IgniteTests24Java8_RunAll Thanks, Amir

Re: IGNITE-8685 review request

Thanks, Dmitriy, I'll take a look. вт, 5 июн. 2018 г. в 15:24, Dmitriy Govorukhin : > Igniters, > > I prepared a rather important patch [1] related to WAL. > In the current implementation, we calculation incorrect size for > SEGMENT_SWITCH record, it leads to stopping the iteration at the end of

IGNITE-8685 review request

Igniters, I prepared a rather important patch [1] related to WAL. In the current implementation, we calculation incorrect size for SEGMENT_SWITCH record, it leads to stopping the iteration at the end of a segment and iterator do not advance to the next segment. [1]

Re: Review request for IGNITE-8534 Upgrade Ignite Spark Module's Spark version to 2.3.

Before spark 2.3, spark is compiled using scala 2.11 and 2.10 separately. Spark-2.10 module in Ignite exists to accommodate this, it's not used anywhere else in project. Now spark 2.3 decided to remove support for scala 2.10, so we can safely remove spark-2.10 module in Ignite. It won't affect

Re: Review request for IGNITE-8534 Upgrade Ignite Spark Module's Spark version to 2.3.

Ray, could you share details of your investigation regarding spark-2.10 module removal? Is it not used anywhere that it can be safely removed? And what about visor-console-2.10 and scala-2.10 modules? > On 30 May 2018, at 08:41, Ray wrote: > > Hi Dmitriy, > > Thanks for the reply. > > I

Re: Review request for IGNITE-8534 Upgrade Ignite Spark Module's Spark version to 2.3.

Hi Ray, Could you also please resolve conflicts in PR? Conflicting files modules/spark-2.10/pom.xml вт, 29 мая 2018 г. в 18:19, Dmitry Pavlov : > Hi Ray, > > Status of this ticket is In Progress, so it is not displayed in filters. > > Could you please set status to Patch Available if PR is

Re: Review request for IGNITE-8534 Upgrade Ignite Spark Module's Spark version to 2.3.

Hi Ray, Status of this ticket is In Progress, so it is not displayed in filters. Could you please set status to Patch Available if PR is ready for review? Sincerely, Dmitriy Pavlov пн, 28 мая 2018 г. в 8:40, Ray : > Valentin Kulichenko and Nikolay Izhikov can you please take a look at PR >

Review request for IGNITE-8534 Upgrade Ignite Spark Module's Spark version to 2.3.

Valentin Kulichenko and Nikolay Izhikov can you please take a look at PR and provide comments? Other reviewers are welcome as well. https://github.com/apache/ignite/pull/4033 I modified Ignite Spark module to fit Spark 2.3 APIs and removed spark-2.10 module because Spark 2.3 stooped support for

Re: Review request

As per cache - I hardly understand affected logic, so my review wouldn't help much here. As per the rest changes - looks good for me. I also see garbage from NIO and "force keys" as huge memory hotspots. The only problem is GridCompoundFuture: if (futs == null) futs = new ArrayList<>();

Re: Review request

On Wed, Feb 3, 2016 at 7:02 AM, Vladimir Ozerov wrote: > As per cache - I hardly understand affected logic, so my review wouldn't > help much here. > > As per the rest changes - looks good for me. I also see garbage from NIO > and "force keys" as huge memory hotspots. The

Re: Review request

I think we should not allocate list at all! We can just add listener to added futures!:) and the semantics will be preserved! However this will not work if we want to iterate over the added ones. Number of unfinished futures will be still available through listener calls count. Let me review. If

Re: Review request

On Mon, Feb 1, 2016 at 10:08 AM, Yakov Zhdanov wrote: > No visible changes to throughput and latency on our common configuration, > but allocation pressure reduced up to 20% in put-get benchmarks. > Nice! > > --Yakov > > 2016-02-01 20:02 GMT+03:00 Dmitriy Setrakyan

Re: Review request

Any preliminary performance numbers? On Mon, Feb 1, 2016 at 8:52 AM, Yakov Zhdanov wrote: > Vladimir Ozerov and Alex Goncharuk, can you please take a look at PR and > provide comments? Other reviewers are welcome, too! =) > > https://github.com/apache/ignite/pull/422 > > I

Review request

Vladimir Ozerov and Alex Goncharuk, can you please take a look at PR and provide comments? Other reviewers are welcome, too! =) https://github.com/apache/ignite/pull/422 I did some changes to decrease allocation pressure and fixed force keys request not to be sent if rebalancing has already been

Re: Review request

No visible changes to throughput and latency on our common configuration, but allocation pressure reduced up to 20% in put-get benchmarks. --Yakov 2016-02-01 20:02 GMT+03:00 Dmitriy Setrakyan : > Any preliminary performance numbers? > > On Mon, Feb 1, 2016 at 8:52 AM,