Re: [RESULT][VOTE] Ignite Packaging IEP

A wrong vote thread referred? https://lists.apache.org/thread/mrwzck7olzgkt25tzg5co7b6v5so1m93 Best regards, Ivan Pavlukhin пн, 29 авг. 2022 г. в 18:46, Petr Ivanov : > > Hi, Mikhail! > > > Did you mean Apache Ignite 3? > I think we should not forget to add 2 or 3 re

Re: [ANNOUNCE] New PMC member: Taras Ledkov

Congratulations, Taras! Best regards, Ivan Pavlukhin сб, 20 авг. 2022 г. в 00:18, Dmitriy Pavlov : > > Hi Igniters! > > The Project Management Committee (PMC) for Apache Ignite has invited > Taras Ledkov to become a member of the PMC and we are pleased to > announce th

Re: [ANNOUNCE] New PMC member: Vyacheslav Koptilin

Congratulations, Slava! Best regards, Ivan Pavlukhin ср, 17 авг. 2022 г. в 21:11, Roman Puchkovskiy : > > Congratulations, Slava! > > ср, 17 авг. 2022 г. в 22:10, Aleksandr Pakhomov : > > > > Congratulations! Well-deserved. > > > > > > > On 1

Duplicates [jira] [Created] (IGNITE-17403) SQL "select by key" performance 50-60 times slower than key-value get

/IGNITE-17406 Best regards, Ivan Pavlukhin

Re: [VOTE] Add swagger dependency to Ignite 3

+1 Aleksandr, thanks for the explanation. Best regards, Ivan Pavlukhin чт, 26 мая 2022 г. в 21:54, Andrey Gura : > > +1 from me. Open API spec could be useful in the future for > implementing external cluster management tools. > > On Thu, May 26, 2022 at 11:41 AM Aleksandr

Re: [VOTE] Add swagger dependency to Ignite 3

Hi, Are we going to include swagger into production packages? I always thought (I might be mistaken) that swagger should be used during development. Worries are usual: 1. Potential vulnerabilities. 2. Unintentional use of transitive dependencies. Best regards, Ivan Pavlukhin чт, 26 мая 2022 г

Re: Add to the Contributors group in JIRA

Aleksandr, I added you to a contributors list. Now you can assign tickets to yourself. Best regards, Ivan Pavlukhin вт, 5 апр. 2022 г. в 13:56, Aleksandr Pakhomov : > > Hi Ivan, > > My account name is aleksandr.pakhomov > > Best regards, > Aleksandr Pakhomov > > >

Re: Add to the Contributors group in JIRA

Hi Aleksandr, Welcome to the Apache Ignite Community! What is your account name in Apache JIRA [1]? [1] https://issues.apache.org/jira Best regards, Ivan Pavlukhin вт, 5 апр. 2022 г. в 13:40, Aleksandr Pakhomov : > > Hello to the apache dev community, > > I am Pakhomov Aleksandr

IFRA ticket regarding GitHub notifications on dev list

Hi, I observed some GitHub PR notifications on dev list and today and created a ticket https://issues.apache.org/jira/browse/INFRA-23075 Best regards, Ivan Pavlukhin

Re: [ANNOUNCE] Welcome Alexander Lapin as a new committer

ivity. >> >> Please join me in welcoming Alexander, and congratulating him on the new >> role in the Apache Ignite Community. >> >> Cheers, >> Kseniya Romanova > > -- Best regards, Ivan Pavlukhin

Re: CVE-2021-42392

Regards, > Vishwas > -- Best regards, Ivan Pavlukhin

Re: [ANNOUNCE] Welcome Vladislav Pyatkov as a new committer

o the project since >> > there >> > is no need to go via the patch submission process. This should enable >> > better productivity. >> > >> > Please join me in welcoming Vlad, and congratulating him on the new >> > role >> > in the Apache Ignite Community. >> > >> > -Val >> > >> > > > -- > Sincerely yours, Ivan Daschinskiy > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

t > want to think anyway, there is not much we can do :) (Except trying to make > the variable non-nullable, of course) > > -Val > > On Mon, Dec 20, 2021 at 11:40 PM Ivan Pavlukhin > wrote: > >> Val, >> >> > Therefore, it's crucial to bring the attenti

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

s possible. >> >> Same here, I agree with you and it correlates with clear API design in >> general. However, sometimes nullable parameters and return values are >> justified, so how can we formalize that? >> >> On Sat, Dec 18, 2021 at 10:52 AM Ivan Pavlukhin

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

ullAway >> >> On Fri, Dec 17, 2021 at 9:04 AM ткаленко кирилл >> wrote: >> >> > I'm for the second option. >> > >> > > > -- > With regards, > Aleksandr Polovtcev > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Reject join of nodes with different character encodings

Ilya Kasnacheev mentioned that we already >> have a warning "Differing character encodings across cluster may lead >> to erratic behavior"). It will help to avoid "erratic behavior", not >> just warn about it. It is important since the problems related to strin

Re: [DISCUSSION] Reject join of nodes with different character encodings

. >> > >> > Actually, we already has some modes to support this restriction of >> > UTF-8. >> > Please, take a look at BinaryUtils#utf8BytesToStr [3] >> > >> > >> > [1] https://en.wikipedia.org/wiki/UTF-8 >> > [2] https://

Re: [DISCUSSION] Reject join of nodes with different character encodings

different encodings? >> >> >> >> As a result, we will be sure that all cluster nodes have the same >> >> encoding and all related problems will be solved. >> >> >> >> [1] - https://issues.apache.org/jira/browse/IGNITE-16106 >> >> [2] - https://issues.apache.org/jira/browse/IGNITE-16068 >> >> >> >> -- >> >> Mikhail >> >> >> >> >> > >> > -- >> > Sincerely yours, Ivan Daschinskiy >> >> > > -- > Sincerely yours, Ivan Daschinskiy > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Reserve partitions for CacheQueries

(merge of query results) on an > initiator node has its own implementation for IndexQuery (MergeSort), but > it's built into existing ScanQuery processing. > > On Mon, Dec 13, 2021 at 11:00 AM Ivan Pavlukhin > wrote: > >> > Then, if there are no objections, the short-term

Re: [DISCUSSION] Reserve partitions for CacheQueries

rt-term plan is: > 1. Implement partition reservation for IndexQuery. > 2. Add the option for ScanQuery. > 3. Make tests that show that IndexQuery / SQL / ScanQuery is replaceable > for some types of queries in terms of result consistency. > 4. Then discuss again, how we can integrat

Re: [DISCUSSION] Reserve partitions for CacheQueries

>> On Thu, Dec 9, 2021 at 10:39 AM Pavel Tupitsyn >> wrote: >> >> > Agree with Ivan regarding compatibility. >> > Partition reservation should be opt-in if we decide to proceed. >> > >> > > is there a real need/benefit from using >> &

Re: [DISCUSSION] Reserve partitions for CacheQueries

data). > > I don't like the idea of this optimistic approach because in case a user > got some data, we don't have a better solution than to fail a query in case > of cluster instability and reservation failure. > > Igniters, WDYT? > > [1] https://issues.apache.org/jira/browse/IGNITE-12591 > [2] https://issues.apache.org/jira/browse/IGNITE-16031 > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x

gt; > > > >>> +1 >>> > > > >>> >>> > > > >>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev < >>> > namelc...@apache.org> >>> > > > >>> wrote: >>> > > > >>> >>> > > > >>>> +1 for deprecation in the 2.12 release >>> > > > >>>> >>> > > > >>>> пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov < >>> nizhi...@apache.org >>> > >: >>> > > > >>>>> >>> > > > >>>>> Hello, Igniters. >>> > > > >>>>> >>> > > > >>>>> I’ve prepared IEP-80 [1] to track breaking changes that >>> > > > >>>>> should >>> > be done >>> > > > >>>> in Ignite 2.x. >>> > > > >>>>> >>> > > > >>>>> We agreed on the following algorithm to deal with breaking >>> > changes: >>> > > > >>>>> >>> > > > >>>>> - Ignite 2.[x] - deprecate the API + notification of the >>> users. >>> > > > >>>>> - Ignite 2.[x+1] - API removal. >>> > > > >>>>> >>> > > > >>>>> >>> > > > >>>>> I propose to start these improvements with the d >>> (depuration & >>> > > > >>>> removal) of the following features: >>> > > > >>>>> >>> > > > >>>>> - LOCAL caches >>> > > > >>>>> - MVCC caches >>> > > > >>>>> - legacy service grid implementation >>> > > > >>>>> - legacy JMX metrics beans. >>> > > > >>>>> >>> > > > >>>>> Deprecation in 2.12 >>> > > > >>>>> Removal in 2.13 >>> > > > >>>>> >>> > > > >>>>> Please, share your opinion. >>> > > > >>>>> >>> > > > >>>>> [1] >>> > > > >>>> >>> > >>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334475 >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> -- >>> > > > >>>> Best wishes, >>> > > > >>>> Amelchev Nikita >>> > > > >>>> >>> > > > > >>> > > > >>> > >>> >>> >>> -- >>> Best Regards, >>> Vyacheslav D. >>> >> >> >> -- >> Sincerely yours, Ivan Daschinskiy >> > > > -- > Sincerely yours, Ivan Daschinskiy > -- Best regards, Ivan Pavlukhin

Re: Stop sending IGNITE Created e-mails to dev@

to this role >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> пт, 30 апр. 2021 г. в 11:55, Mikhail Petrov : >> >>> Hi, Ilya, could you please add me to "Contributors 1" role? Or can I do >>> it myself somehow? >>> >>> On 29.04.2021 18:59, Ilya Kasnacheev wrote: >>> >>> Hello! >>> >>> Pavel, Yurii, I have added you both to the role. >>> >>> Regards, >>> >>> > -- Best regards, Ivan Pavlukhin

Re: Text Queries Support

t;:"string","validated":false,"case_sensitive":true}, > "animal":{"type":"string","validated":false,"case_sensitive":true}, > "age":{"type":"integer","valida

Re: [VOTE] Create separate Jira project and Confluence space for Ignite 3

ity vote. >> >> Voting ends in 72 hours, at 5pm PDT on October 7: >> https://www.timeanddate.com/counters/fullscreen.html?mode=a=20211007T17=2021=10=7=17=0=0=224 >> >> -Val > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

> development. "Do nothing" is not really an option here. > > Either way, I will put the initial suggestion for the vote. > > -Val > > On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin > wrote: > >> Val, >> >> > Let's discuss this until the end of

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

t;>>>>> (initial suggestion). >>>>>>>> 2. Add a *mandatory* field in Jira to identify whether a ticket >>>>>>>> belongs to >>>>>>>> 2.x or 3.x. >>>>>>>> >>>>>>>> If we go with #2,

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

I mean that Ignite 2.x will continue to use old scheme and Ignite 3 will be e.g. Ignite 21.1 and so on. 2021-09-27 14:57 GMT+03:00, Petr Ivanov : > How will not they clash if version is based only on date? > >> On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: >> >> Today i

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

gt;>>> >>>>>>>>>> Should we accept the fact that thing we calling as "Ignite3" is >>>> just >>>>>>> another project? >>>>>>>>>> Can you, please, share your vision on how Ignite and Ignite3 >>> should >>>>>>> coexists? >>>>>>>>>> >>>>>>>>>> вт, 21 сент. 2021 г. в 17:13, Dmitry Pavlov >>> : >>>>>>>>>>> >>>>>>>>>>> Ok, if nobody minds, I'll create spaces a bit later. >>>>>>>>>>> >>>>>>>>>>> I hope it is not too urgent. >>>>>>>>>>> >>>>>>>>>>> Sincerely, >>>>>>>>>>> Dmitriy Pavlov >>>>>>>>>>> >>>>>>>>>>> On 2021/09/21 10:37:42, Valentin Kulichenko < >>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> According to Infra, this has to be done through >>>>>>> http://selfserve.apache.org/, >>>>>>>>>>>> but only PMC chairs have access. >>>>>>>>>>>> >>>>>>>>>>>> Could you please assist with the creation of the Jira project >>>> and >>>>>>>>>>>> Confluence space? >>>>>>>>>>>> >>>>>>>>>>>> -Val >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko < >>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Infra requests created: >>>>>>>>>>>>> >>>>>>>>>>>>> - https://issues.apache.org/jira/browse/INFRA-22349 >>>>>>>>>>>>> - https://issues.apache.org/jira/browse/INFRA-22350 >>>>>>>>>>>>> >>>>>>>>>>>>> -Val >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov < >>>>>>> mr.wei...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> +1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since we've agreed that there are two projects (that are >>>>>>> Ignite2 and >>>>>>>>>>>>>> Ignite3), separate development environments seem to be >>>> logical >>>>>>> and natural >>>>>>>>>>>>>> course of things. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18 Sep 2021, at 12:42, Alexander Polovtcev < >>>>>>> alexpolovt...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>> This is a welcome proposal, because we already have some >>>>>>> pending Ignite >>>>>>>>>>>>>> 3 >>>>>>>>>>>>>>> specific documents, and it is not clear where to put them >>>> at >>>>>>> the moment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < >>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Igniters, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it's clear to all of us that Ignite 2.x and 3.x >>>>>>> will coexist >>>>>>>>>>>>>> for a >>>>>>>>>>>>>>>> while. They are developed in separate Git repos, but we >>>>>>> still >>>>>>>>>>>>>> accumulate >>>>>>>>>>>>>>>> the tickets for both versions in the same Jira project, >>>>>>> which seems to >>>>>>>>>>>>>>>> complicate the ticket management. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example, we use the "ignite-3" label for 3.x >>> tickets, >>>>>>> but this >>>>>>>>>>>>>> approach >>>>>>>>>>>>>>>> is fragile. If someone forgets to add the label to a new >>>>>>> ticket, it's >>>>>>>>>>>>>>>> likely to be lost. We need a better separation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All the above is true for Wiki as well - we use a single >>>>>>> Confluence >>>>>>>>>>>>>> space. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I suggest creating a new Jira project and a new >>> Confluence >>>>>>> space for >>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>> 3 and moving all the relevant tickets and pages there. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any thoughts or objections? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Val >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> With regards, >>>>>>>>>>>>>>> Aleksandr Polovtcev >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>> >>>> >>> > > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Remove VS project from C++

gt;>> 5. VS projects are not backward compatible. We have to add manually (or >>>> by >>>> sed or patch) some dependencies in order to build current VS projects >>>> on >>>> newer versions of VS. >>>> >>>> So I suggest simpy to remove VS projects because of reasons I've >>>> written >>>> above. >>>> >>>> WDYT? >>>> >>>> >>>> >>>> [1] -- https://issues.apache.org/jira/browse/IGNITE-15511 >>> >>> >>> >>> > > -- Best regards, Ivan Pavlukhin

Re: Ban Java Streams usage in Ignite 3 code

pt >> > 3 >> > >> ≈ 0counts >> > >> >> > >> * StreamVsLoopBenchmark.streamSum >> > >> thrpt >> > 3 >> > >> 1060.244 ± 36.485 ops/ms >> > >> * StreamVsLoopBenchmark.streamSum:·gc.alloc.rate >> > >> thrpt >> > 3 >> > >> 315.819 ± 10.844 MB/sec >> > >> * StreamVsLoopBenchmark.streamSum:·gc.count >> > >> thrpt >> > 3 >> > >> 55.000counts >> > >> >> > >> Loop is several times faster and does not allocate at all. >> > >> >> > >> 1. Performance is one of the most important features of our product. >> > >> 2. Most of our APIs will be on the hot path. >> > >> >> > >> One can argue about performance differences in real-world scenarios, >> > >> but increasing GC pressure just to make the code a little bit nicer >> > >> is >> > >> unacceptable. >> > >> >> > >> I propose to ban streams usage in the codebase (except for the >> > >> tests). >> > >> >> > >> Thoughts, objections? >> > >> >> > >> [1] >> > >> https://gist.github.com/ptupitsyn/5934bbbf8f92ac4937e534af9386da97 >> > >> >> > > >> > > >> > > -- >> > > Sincerely yours, >> > > Ivan Bessonov >> > >> > > -- Best regards, Ivan Pavlukhin

Re: Ban Java Streams usage in Ignite 3 code

Is will be on the hot path. >> >> One can argue about performance differences in real-world scenarios, >> but increasing GC pressure just to make the code a little bit nicer is >> unacceptable. >> >> I propose to ban streams usage in the codebase (except for the tests). >> >> Thoughts, objections? >> >> [1] https://gist.github.com/ptupitsyn/5934bbbf8f92ac4937e534af9386da97 >> > > > -- > Sincerely yours, > Ivan Bessonov > -- Best regards, Ivan Pavlukhin

Re: [ANNOUNCE] Welcome Andrei Aleksandrov as a new committer

d of guidance, >> review >> and then ensuring the code is included. >> >> Regards, >> >> -- >> Ilya Kasnacheev >> > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Send documentation feedback notifications to dev list

tter to have a single dev@ account on this service so > that any community member can log in and handle feedback (we already follow > this practice for other services). > > - > Denis > > > On Monday, August 9, 2021, Ivan Pavlukhin wrote: > >> Igniters, >> >>

Re: [DISCUSSION] Send documentation feedback notifications to dev list

eeping the dev list clean. > > On Mon, Aug 9, 2021 at 11:00 AM Pavel Tupitsyn > wrote: > >> I agree, let's keep the dev list clean. >> Automated notifications of any kind should not be sent to dev@i.a.o. >> >> PS Ivan, links 2 and 3 are the same. >> >> O

Re: Text Queries Support

; Hi Ivan, > > I didn't quite understand. Are you proposing that Ignite should not > have FTS capabilities? > > Atri > > On Tue, Aug 3, 2021 at 2:57 PM Ivan Pavlukhin wrote: >> >> Hi Atri, >> >> My main concern is non-maleficence. Every task has sev

[DISCUSSION] Send documentation feedback notifications to dev list

56f0bb0%40%3Cdev.ignite.apache.org%3E -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Documentation feedback button

ocumentation >> > > > feedback» button) to the web site documentation pages so everyone >> could >> > > > leave a comment to what is already published. >> > > > >> > > > The feedback may refer to the Ignite documentation in general or to >> > > > a >> > > > particular section, paragraph, or even term or value. >> > > > >> > > > I do believe that we would harvest dozens and hundreds of ideas, >> > > > suggestions, and observations. >> > > > >> > > > I would also suggest using bugyard.io as a solid service for >> gathering >> > > > feedback (I’m quite familiar with it, it is easy to implement, use, >> and >> > > > maintain). >> > > > >> > > > So folks, what do you think of this? >> > > > >> > > > With best regards, >> > > > Nikita >> > > > >> > > >> > >> > -- Best regards, Ivan Pavlukhin

Re: Apache Ignite 3 Alpha 2 webinar follow up questions

ry little visibility into what it is doing, >> it >> > >> > was >> > >> > just stopped, no logging or anything and then resumed. >> > >> > >> > >> > 2021-07-22 13:40:15.997 INFO [ArcOS,,,] 9 --- [orker-#40%hypi%] >> > >> > o.a.i.i.p.cache.GridCacheProcessor [285] : Finished recovery >> for >> > >> > cache [cache=hypi_01F8ZC3DGT66RNYCDZH3XNVY2E_Hue, grp=hypi, >> > >> > startVer=AffinityTopologyVersion [topVer=79, minorTopVer=0]] >> > >> > >> > >> > One hour later it printed the next cache recovery message and >> started >> > >> > 30 >> > >> > seconds after going through other tables. >> > >> > >> > >> > >> > >> > >> > >> >> >> > >> >> Let's wait if someone will clarify what we could expect in >> Ignite-3. >> > >> >> Guys, can someone chime in and give more light on 3,4,7,8 >> questions? >> > >> >> >> > >> >> >> > >> >> On Thu, Jul 22, 2021 at 4:15 AM Courtney Robinson < >> > >> >> courtney.robin...@hypi.io> >> > >> >> wrote: >> > >> >> >> > >> >> > Hey everyone, >> > >> >> > I attended the Alpha 2 update yesterday and was quite pleased >> > >> >> > to >> > see >> > >> the >> > >> >> > progress on things so far. So first, congratulations to >> > >> >> > everyone >> on >> > >> the >> > >> >> > work being put in and thank you to Val and Kseniya for running >> > >> >> yesterday's >> > >> >> > event. >> > >> >> > >> > >> >> > I asked a few questions after the webinar which Val had some >> > answers >> > >> to >> > >> >> but >> > >> >> > suggested posting here as some of them are not things that have >> > been >> > >> >> > thought about yet or no plans exist around it at this point. >> > >> >> > >> > >> >> > I'll put all of them here and if necessary we can break into >> > >> >> > different >> > >> >> > threads after. >> > >> >> > >> > >> >> >1. Schema change - does that include the ability to change >> > >> >> > the >> > >> types >> > >> >> of >> > >> >> >fields/columns? >> > >> >> > 1. Val's answer was yes with some limitations but those >> > >> >> > are >> > >> >> > not >> > >> >> well >> > >> >> > defined yet. He did mention that something like some kind >> of >> > >> >> > transformer >> > >> >> > could be provided for doing the conversion and I would >> second >> > >> >> this, >> > >> >> > even >> > >> >> > for common types like int to long being able to do a >> > >> >> > custom >> > >> >> > conversion will >> > >> >> > be immensely valuable. >> > >> >> >2. Will the new guaranteed consistency between APIs also >> > >> >> > mean >> > SQL >> > >> >> will >> > >> >> >gain transaction support? >> > >> >> > 1. I believe the answer here was yes but perhaps someone >> else >> > >> may >> > >> >> > want to weigh in to confirm >> > >> >> >3. Has there been any decision about how much of Calcite >> > >> >> > will >> be >> > >> >> exposed >> > >> >> >to the client? When using thick clients, it'll be hugely >> > >> >> > beneficial >> > >> >> to >> > >> >> > be >> > >> >> >able to work with Calcite APIs directly to provide custom >> rules >> > >> >> > and >> > >> >> >optimisations to better suit organisation needs >> > >> >> >1. We currently use Calcite ourselves and have a lot of >> > >> >> > custom >> > >> rules >> > >> >> and >> > >> >> > optimisations and have slowly pushed more of our queries >> > >> >> > to >> > >> >> > Calcite that we >> > >> >> > then push down to Ignite. >> > >> >> > 2. We Index into Solr and use the Solr indices and others >> to >> > >> >> > fulfill over all queries with Ignite just being one of >> > >> >> > the >> > >> >> > possible storage >> > >> >> > targets Calcite pushes down to. If we could get to the >> > calcite >> > >> >> > API from an >> > >> >> > Ignite thick client, it would enable us to remove a layer >> of >> > >> >> > abstraction >> > >> >> > and complexity and make Ignite our primary that we then >> link >> > >> >> > with Solr and >> > >> >> > others to fulfill queries. >> > >> >> >4. Will the unified storage model enable different versions >> > >> >> > of >> > >> >> Ignite to >> > >> >> >be in the cluster when persistence is enabled so that >> > >> >> > rolling >> > >> >> restarts >> > >> >> > can >> > >> >> >be done? >> > >> >> >1. We have to do a strange dance to perform Ignite upgrades >> > >> >> > without >> > >> >> > downtime because pods/nodes will fail to start on version >> > >> mismatch >> > >> >> > and if >> > >> >> > we get that dance wrong, we will corrupt a node's data. >> > >> >> > It >> > >> >> > will >> > >> >> make >> > >> >> > admin/upgrades far less brittle and error prone if this >> > >> >> > was >> > >> >> possible. >> > >> >> >5. Will it be possible to provide a custom cache store still >> and >> > >> will >> > >> >> >these changes enable custom cache stores to be queryable >> > >> >> > from >> > >> >> > SQL? >> > >> >> >1. Our Ignite usage is wide and complex because we use KV, >> > >> >> > SQL >> > >> >> > and >> > >> >> other >> > >> >> > APIs. The inconsistency of what can and can't be used >> > >> >> > from >> > one >> > >> >> API to >> > >> >> > another is a real challenge and has forced us over time >> > >> >> > to >> > >> >> > stick >> > >> >> > to one API >> > >> >> > and write alternative solutions outside of Ignite. It >> > >> >> > will >> > >> >> > drastically >> > >> >> > simplify things if any CacheStore (or some new >> > >> >> > equivalent) >> > >> >> > could >> > >> >> > be plugged >> > >> >> > in and be made accessible to SQL (and in fact all other >> APIs) >> > >> >> without >> > >> >> > having to load all the data from the underlying >> > >> >> > CacheStore >> > >> >> > first >> > >> >> > into memory >> > >> >> >6. This question wasn't mine but I was going to ask it as >> well: >> > >> What >> > >> >> >will happen to the Indexing API since H2 is being removed? >> > >> >> > 1. As I mentioned above, we Index into Solr, in earlier >> > >> >> > versions >> > >> >> of >> > >> >> > our product we used the indexing SPI to index into Lucene >> on >> > >> >> > the >> > >> >> > Ignite >> > >> >> > nodes but this presented so many challenges we ultimately >> > >> >> > abandoned it and >> > >> >> > replaced it with the current Solr solution. >> > >> >> > 2. Lucene indexing was ideal because it meant we didn't >> have >> > >> >> > to >> > >> >> > re-invent Solr or Elasticsearch's sharding capabilities, >> that >> > >> was >> > >> >> > almost >> > >> >> > automatic with Ignite only giving you the data that was >> meant >> > >> for >> > >> >> the >> > >> >> > current node. >> > >> >> > 3. The Lucene API enabled more flexibility and removed a >> > >> >> > network >> > >> >> > round trip from our queries. >> > >> >> > 4. Given Calcite's ability to support custom SQL >> > >> >> > functions, >> > >> >> > I'd >> > >> >> love >> > >> >> > to have the ability to define custom functions that >> > >> >> > Lucene >> > was >> > >> >> > answering >> > >> >> >7. What impact does RAFT now have on conflict resolution, >> > >> >> > off >> > the >> > >> >> top of >> > >> >> >my head there are two cases >> > >> >> > 1. On startup after a split brain Ignite currently takes >> > >> >> > an >> > >> >> "exercise >> > >> >> > for the reader" approach and dumps a log along the lines >> > >> >> > of >> > >> >> > >> > >> >> > >1. BaselineTopology of joining node is not compatible with >> > >> >> > > BaselineTopology in the cluster. >> > >> >> > >1. Branching history of cluster BlT doesn't contain >> branching >> > >> point >> > >> >> > > hash of joining node BlT. Consider cleaning persistent >> > >> >> > > storage >> > >> >> of >> > >> >> > the node >> > >> >> > > and adding it to the cluster again. >> > >> >> > > >> > >> >> >1. This leaves you with no choice except to take one half >> > >> >> > and >> > >> >> manually >> > >> >> > copy, write data back over to the other half then destroy >> the >> > >> bad >> > >> >> > one. >> > >> >> > 2. The second case is conflicts on keys, I >> > >> >> > beleive CacheVersionConflictResolver and manager are used >> > >> >> > by GridCacheMapEntry which just says if use old value do >> this >> > >> >> > otherwise use >> > >> >> > newVal. Ideally this will be exposed in the new API so >> > >> >> > that >> > >> >> > one >> > >> >> can >> > >> >> > override this behaviour. The last writer wins approach >> isn't >> > >> >> always >> > >> >> > ideal >> > >> >> > and the semantics of the domain can mean that what is >> > consider >> > >> >> > "correct" in >> > >> >> > a conflict is not so for a different domain. >> > >> >> >8. This is last on the list but is actually the most >> > >> >> > important >> > >> >> > for >> > >> us >> > >> >> >right now as it is an impending and growing risk. We allow >> > >> customers >> > >> >> to >> > >> >> >create their own tables on demand. We're already using the >> same >> > >> cache >> > >> >> > group >> > >> >> >etc for data structures to be re-used but now that we're >> getting >> > >> >> > to >> > >> >> >thousands of tables/caches our startup times are sometimes >> > >> >> unpredictably >> > >> >> >long - at present it seems to depend on the state of the >> > >> cache/table >> > >> >> > before >> > >> >> >the restart but we're into the order of 5 - 7 mins and >> steadily >> > >> >> > increasing >> > >> >> >with the growth of tables. Are there any provisions in >> > >> >> > Ignite >> 3 >> > >> >> > for >> > >> >> >ensuring startup time isn't proportional to the number of >> > >> >> tables/caches >> > >> >> >available? >> > >> >> > >> > >> >> > >> > >> >> > Those are the key things I can think of at the moment. Val and >> > >> >> > others >> > >> >> I'd >> > >> >> > love to open a conversation around these. >> > >> >> > >> > >> >> > Regards, >> > >> >> > Courtney Robinson >> > >> >> > Founder and CEO, Hypi >> > >> >> > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io> >> > >> >> > >> > >> >> > <https://hypi.io> >> > >> >> > https://hypi.io >> > >> >> > >> > >> >> >> > >> >> >> > >> >> -- >> > >> >> Best regards, >> > >> >> Andrey V. Mashenkov >> > >> >> >> > >> > >> > >> >> > > >> > >> > >> > -- >> > >> > Best regards, >> > Ivan Pavlukhin >> > >> > -- Best regards, Ivan Pavlukhin

Re: Text Queries Support

, Atri Sharma : > Hi Ivan, > > Would you like to propose an alternative to Lucene? > > Atri > > On Mon, 2 Aug 2021, 13:48 Ivan Pavlukhin, wrote: > >> Folks, >> >> Sorry if read the thread not thoroughly enough, but do we consider >> Lucene as ob

Re: Text Queries Support

gt;> > > > > > > > the >> > > > > > > > > > last ticket I'm doing I see some obvious issues with >> > > > > > > > > > them >> > (no >> > > > page >> > > > > > > size >> > > > > > > > > > support, for example). I'm glad that somebody wants to >> > maintain >> > > > > > this >> > > > > > > > > > functionality. Thanks a lot! >> > > > > > > > > > >> > > > > > > > > > For the MergeSort algorithm there is already a patch >> > > > > > > > > > for >> > that >> > > > [1]. >> > > > > > > It's >> > > > > > > > > > currently on review. This patch introduces an abstract >> > reducer >> > > > for >> > > > > > > > > > CacheQueries with 2 implementations (unordered, >> > merge-sort). >> > > > Then >> > > > > > > > TextQuery >> > > > > > > > > > leverages on MergeSort to order results from multiple >> > nodes by >> > > > > > score. >> > > > > > > > This >> > > > > > > > > > patch also fixes the pageSize issue, I've mentioned >> > > > > > > > > > before. >> > > > Could >> > > > > > you >> > > > > > > > > > please check if it fully matches your idea? Any issues >> > > > > > > > > > or >> > > > comments >> > > > > > > are >> > > > > > > > > > welcome. >> > > > > > > > > > >> > > > > > > > > > I've prepared this ticket, because I need the MergeSort >> > > > algorithm >> > > > > > for >> > > > > > > > the >> > > > > > > > > > new type of queries I'm implementing (IndexQuery, it >> > > > > > > > > > should >> > > > also >> > > > > > > > provide >> > > > > > > > > > ordered results over multiple nodes). Currently I'm not >> > > > planning to >> > > > > > > go >> > > > > > > > > > further with TextQuery, so if you're going to support >> > > > > > > > > > this >> > > > it'll >> > > > > > be a >> > > > > > > > great >> > > > > > > > > > contribution, I think. >> > > > > > > > > > >> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14703 >> > > > > > > > > > [2] https://github.com/apache/ignite/pull/9081 >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > On Mon, Jun 21, 2021 at 11:11 AM Atri Sharma < >> > a...@apache.org> >> > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > Hi All, >> > > > > > > > > > > >> > > > > > > > > > > I have been looking into our text queries support and >> > > > > > > > > > > see >> > > > that it >> > > > > > > has >> > > > > > > > > > > limited community support. >> > > > > > > > > > > >> > > > > > > > > > > Therefore, I volunteer to be the maintainer of the >> > module and >> > > > > > work >> > > > > > > on >> > > > > > > > > > > enhancing it further. >> > > > > > > > > > > >> > > > > > > > > > > First goal would be to move to Lucene 8.x, then work >> > > > > > > > > > > on >> > > > sorted >> > > > > > > reduce >> > > > > > > > > > > - merge across nodes. Fundamentally, this is doable >> > > > > > > > > > > since >> > > > Lucene >> > > > > > > > ranks >> > > > > > > > > > > documents according to their score, and documents are >> > > > returned in >> > > > > > > the >> > > > > > > > > > > order of their score. Since the scoring function is >> > > > homogeneous, >> > > > > > > this >> > > > > > > > > > > means that across nodes, we can compare scores and >> > > > > > > > > > > merge >> > > > sort. >> > > > > > > > > > > >> > > > > > > > > > > Please let me know if I can take this up. >> > > > > > > > > > > >> > > > > > > > > > > Atri >> > > > > > > > > > > >> > > > > > > > > > > -- >> > > > > > > > > > > Regards, >> > > > > > > > > > > >> > > > > > > > > > > Atri >> > > > > > > > > > > Apache Concerted >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > -- >> > > > > > > > > >> > > > > > > > > Best regards, >> > > > > > > > > Alexei Scherbakov >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Regards, >> > > > > > > > >> > > > > > > > Atri >> > > > > > > > Apache Concerted >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Best regards, >> > > > > Andrey V. Mashenkov >> > > > >> > > > -- >> > > > Regards, >> > > > >> > > > Atri >> > > > Apache Concerted >> > > > >> > > >> > > >> > > -- >> > > Best regards, >> > > Andrey V. Mashenkov >> > >> > -- >> > Regards, >> > >> > Atri >> > Apache Concerted >> > >> >> >> -- >> Best regards, >> Andrey V. Mashenkov > > -- > Regards, > > Atri > Apache Concerted > -- Best regards, Ivan Pavlukhin

Re: MTCGA site is down

e yesterday), however, this site hosted on GridGain >> > domain [2] is working. >> > Can anyone have a look what's happening? >> > >> > [1] : mtcga.ignite.apache.org >> > [2] : mtcga.gridgain.com >> >> > -- Best regards, Ivan Pavlukhin

Re: Apache Ignite 3 Alpha 2 webinar follow up questions

t; > API from an >> >> > Ignite thick client, it would enable us to remove a layer of >> >> > abstraction >> >> > and complexity and make Ignite our primary that we then link >> >> > with Solr and >> >> > others to fulfill queries. >> >> >4. Will the unified storage model enable different versions of >> >> Ignite to >> >> >be in the cluster when persistence is enabled so that rolling >> >> restarts >> >> > can >> >> >be done? >> >> >1. We have to do a strange dance to perform Ignite upgrades >> >> > without >> >> > downtime because pods/nodes will fail to start on version >> mismatch >> >> > and if >> >> > we get that dance wrong, we will corrupt a node's data. It >> >> > will >> >> make >> >> > admin/upgrades far less brittle and error prone if this was >> >> possible. >> >> >5. Will it be possible to provide a custom cache store still and >> will >> >> >these changes enable custom cache stores to be queryable from >> >> > SQL? >> >> >1. Our Ignite usage is wide and complex because we use KV, SQL >> >> > and >> >> other >> >> > APIs. The inconsistency of what can and can't be used from one >> >> API to >> >> > another is a real challenge and has forced us over time to >> >> > stick >> >> > to one API >> >> > and write alternative solutions outside of Ignite. It will >> >> > drastically >> >> > simplify things if any CacheStore (or some new equivalent) >> >> > could >> >> > be plugged >> >> > in and be made accessible to SQL (and in fact all other APIs) >> >> without >> >> > having to load all the data from the underlying CacheStore >> >> > first >> >> > into memory >> >> >6. This question wasn't mine but I was going to ask it as well: >> What >> >> >will happen to the Indexing API since H2 is being removed? >> >> > 1. As I mentioned above, we Index into Solr, in earlier >> >> > versions >> >> of >> >> > our product we used the indexing SPI to index into Lucene on >> >> > the >> >> > Ignite >> >> > nodes but this presented so many challenges we ultimately >> >> > abandoned it and >> >> > replaced it with the current Solr solution. >> >> > 2. Lucene indexing was ideal because it meant we didn't have >> >> > to >> >> > re-invent Solr or Elasticsearch's sharding capabilities, that >> was >> >> > almost >> >> > automatic with Ignite only giving you the data that was meant >> for >> >> the >> >> > current node. >> >> > 3. The Lucene API enabled more flexibility and removed a >> >> > network >> >> > round trip from our queries. >> >> > 4. Given Calcite's ability to support custom SQL functions, >> >> > I'd >> >> love >> >> > to have the ability to define custom functions that Lucene was >> >> > answering >> >> >7. What impact does RAFT now have on conflict resolution, off the >> >> top of >> >> >my head there are two cases >> >> > 1. On startup after a split brain Ignite currently takes an >> >> "exercise >> >> > for the reader" approach and dumps a log along the lines of >> >> > >> >> > >1. BaselineTopology of joining node is not compatible with >> >> > > BaselineTopology in the cluster. >> >> > >1. Branching history of cluster BlT doesn't contain branching >> point >> >> > > hash of joining node BlT. Consider cleaning persistent >> >> > > storage >> >> of >> >> > the node >> >> > > and adding it to the cluster again. >> >> > > >> >> >1. This leaves you with no choice except to take one half and >> >> manually >> >> > copy, write data back over to the other half then destroy the >> bad >> >> > one. >> >> > 2. The second case is conflicts on keys, I >> >> > beleive CacheVersionConflictResolver and manager are used >> >> > by GridCacheMapEntry which just says if use old value do this >> >> > otherwise use >> >> > newVal. Ideally this will be exposed in the new API so that >> >> > one >> >> can >> >> > override this behaviour. The last writer wins approach isn't >> >> always >> >> > ideal >> >> > and the semantics of the domain can mean that what is consider >> >> > "correct" in >> >> > a conflict is not so for a different domain. >> >> >8. This is last on the list but is actually the most important >> >> > for >> us >> >> >right now as it is an impending and growing risk. We allow >> customers >> >> to >> >> >create their own tables on demand. We're already using the same >> cache >> >> > group >> >> >etc for data structures to be re-used but now that we're getting >> >> > to >> >> >thousands of tables/caches our startup times are sometimes >> >> unpredictably >> >> >long - at present it seems to depend on the state of the >> cache/table >> >> > before >> >> >the restart but we're into the order of 5 - 7 mins and steadily >> >> > increasing >> >> >with the growth of tables. Are there any provisions in Ignite 3 >> >> > for >> >> >ensuring startup time isn't proportional to the number of >> >> tables/caches >> >> >available? >> >> > >> >> > >> >> > Those are the key things I can think of at the moment. Val and >> >> > others >> >> I'd >> >> > love to open a conversation around these. >> >> > >> >> > Regards, >> >> > Courtney Robinson >> >> > Founder and CEO, Hypi >> >> > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io> >> >> > >> >> > <https://hypi.io> >> >> > https://hypi.io >> >> > >> >> >> >> >> >> -- >> >> Best regards, >> >> Andrey V. Mashenkov >> >> >> > >> > -- Best regards, Ivan Pavlukhin

Re: [DISCUSS] Confuse default inspections.

t want to link additional discussion about pos. 2 i think that harm >> is obvious. >> I suggest to get rid of them. >> >> what do you think ? >> >> >> > > > > -- > Sincerely yours, Ivan Daschinskiy > -- Best regards, Ivan Pavlukhin

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

; > > >> > > > > > > > > > separate facades for sync, async >> > > > > > > > > >> > > > > > > > > Strongly disagree with this idea. It hurts API >

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

e a good candidate for this. >> > > > > > > >> > > > > > > Ignition#start should eventually be removed from the public >> API. >> > It >> > > > is >> > > > > > > currently there only because we don't have the thin client >> > > > > > > yet. >> > > > > > > >> > > > > > > -Val >> > > > > > > >> > > > > > >> On Wed, Jul 7, 2021 at 5:47 AM Pavel Tupitsyn < >> > > ptupit...@apache.org >> > > > > >> > > > > > wrote: >> > > > > > >> >> > > > > > >> Igniters, >> > > > > > >> >> > > > > > >> I have a few questions regarding server node startup and >> > > > > > >> thin >> > > > clients. >> > > > > > >> >> > > > > > >> State of things: >> > > > > > >> - Server nodes will be started with 'ignite run' from CLI >> > > > > > >> [1] >> > > > > > >> - ignite-api module represents our public API >> > > > > > >> - ignite-api has Ignition interface to start server nodes >> > > > > > >> >> > > > > > >> Questions: >> > > > > > >> - What's the idea behind Ignition interface in the public >> > > > > > >> API? >> > Are >> > > > we >> > > > > > going >> > > > > > >> to have an "embedded mode" where servers can be started from >> > > code? I >> > > > > > >> thought this was not planned. >> > > > > > >> - How are users supposed to retrieve an instance of the >> Ignition >> > > > > > interface? >> > > > > > >> - Are there any plans to start thin clients from Ignition >> > > interface, >> > > > > or >> > > > > > >> should we have a separate way of doing this? >> > > > > > >> >> > > > > > >> >> > > > > > >> [1] >> > > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958 >> > > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >> > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] Code style. Variable abbrevations

gt; about constant's namings. >> > > >> > > I suppose that we should define strict and clear rules about >> > > constants >> > > naming. >> > > >> > > [1] -- >> > https://cwiki.apache.org/confluence/display/IGNI

Re: [DISCUSSION] Code style. Variable abbrevations

le to enforce usage of abbreviations. > Internal/public code differs by package. > > PoC of rule [1] > > [1] https://github.com/apache/ignite/pull/9153 > >> 17 июня 2021 г., в 07:01, Ivan Pavlukhin >> написал(а): >> >> Nikita, >> >> Do you have a

Re: [DISCUSSION] Code style. Variable abbrevations

>> > > >>>>>>>> Abbrevation should be used for CACHE_NAME_LOCAL_TX! Please, >> > > >>>>>>>> use >> > > >>> loc, >> > > >>>>>>>> instead of LOCAL [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:264: >> > > >>>>>>>> Abbrevation should be used for checkpointManager! Please, use >> > > >>>>>>>> mgr, >> > > >>>>> instead >> > > >>>>>>>> of Manager [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsPartitionPreloadTest.java:63: >> > > >>>>>>>> Abbrevation should be used for DEFAULT_REGION! Please, use >> > > >>>>>>>> dflt, >> > > >>>>> instead of >> > > >>>>>>>> DEFAULT [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWholeClusterRestartTest.java:47: >> > > >>>>>>>> Abbrevation should be used for ENTRIES_COUNT! Please, use >> > > >>>>>>>> cnt, >> > > >>>> instead >> > > >>>>> of >> > > >>>>>>>> COUNT [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsRebalancingOnNotStableTopologyTest.java:49: >> > > >>>>>>>> Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, >> > > >>>>>>>> use >> > > >>>> freq, >> > > >>>>>>>> instead of FREQUENCY [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:75: >> > > >>>>>>>> Abbrevation should be used for MAX_KEY_COUNT! Please, use >> > > >>>>>>>> cnt, >> > > >>>> instead >> > > >>>>> of >> > > >>>>>>>> COUNT [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:78: >> > > >>>>>>>> Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, >> > > >>>>>>>> use >> > > >>>> freq, >> > > >>>>>>>> instead of FREQUENCY [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/SlowHistoricalRebalanceSmallHistoryTest.java:57: >> > > >>>>>>>> Abbrevation should be used for SUPPLY_MESSAGE_LATCH! Please, >> > > >>>>>>>> use >> > > >>> msg, >> > > >>>>>>>> instead of MESSAGE [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:74: >> > > >>>>>>>> Abbrevation should be used for SHARED_GROUP_NAME! Please, use >> > > >>>>>>>> grp, >> > > >>>>> instead >> > > >>>>>>>> of GROUP [IgniteAbbrevationsRule] >> > > >>>>>>>> [ERROR] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:200: >> > > >>>>>>>> Abbrevation should be used for cacheLoader! Please, use ldr, >> > > >>> instead >> > > >>>> of >> > > >>>>>>>> Loader [IgniteAbbrevationsRule] >> > > >>>>>>>> ``` >> > > >>>>>>>> >> > > >>>>>>>> [1] >> > > >>>>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation >> > > >>>>>>>> [2] https://github.com/apache/ignite/pull/9153 >> > > >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>> >> > > >>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > >> >> > > >> >> > > >> -- >> > > >> >> > > >> Best regards, >> > > >> Alexei Scherbakov >> > > > >> > > >> > > > -- Best regards, Ivan Pavlukhin

Re: Obsolete classnames.properties

t up-to-date in the repository. Also > it's impossible to tell right now if it is or it is not up-to-date (without > executing ClassesGenerator). > > Kind regards, Semyon. > -- Best regards, Ivan Pavlukhin

Re: Greetings

ername*Korol*. > > Thanks! > > -- Best regards, Ivan Pavlukhin

Re: Issue building Ignite 2.10 branch

aded to >> > Maven >> > 3.8.0 with no change to the result. >> > >> > Is there an easy work around for this? >> > >> > Thanks, >> > Raymond. >> > >> > >> > -- >> > <http://www.trimble.com/> >> > Raymond Wilson >> > Trimble Distinguished Engineer, Civil Construction Software (CCS) >> > 11 Birmingham Drive | Christchurch, New Zealand >> > raymond_wil...@trimble.com >> > >> > < >> > >> https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch >> > > >> > >> > > > -- > <http://www.trimble.com/> > Raymond Wilson > Trimble Distinguished Engineer, Civil Construction Software (CCS) > 11 Birmingham Drive | Christchurch, New Zealand > raymond_wil...@trimble.com > > <https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch> > -- Best regards, Ivan Pavlukhin

Re: Re[2]: [DISCUSSION] MaxLineLength checkstyle rule

gt;> > >> > >> > Regards, >> > >> > -- >> > >> > Ilya Kasnacheev >> > >> > >> > >> > >> > >> > чт, 15 апр. 2021 г. в 11:30, Nikolay Izhikov < nizhi...@apache.org >> > >> > >: >> > >> > Hello, Igniters. >> > >> > >> > >> > Right now, we have a code style rule [1] - the line should fit in >> > >> > 120 >> > >> characters. >> > >> > But, this rule violated in many and many places through code. >> > >> > I have a plan to add a check style rule to force maximum line >> > >> > length. >> > >> > >> > >> > For me, personally, 120 characters a bit old-fashioned >> > >> > restriction. >> > >> > Should we increase the maximum line length to 150 or even 180 >> > characters? >> > >> > >> > >> > [1] >> > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines >> > >> > >> > >> >> > >> >> > >-- >> > >Sincerely yours, Ivan Daschinskiy >> > >> > >> > >> > >> >> >> >> -- >> Sincerely yours, Ivan Daschinskiy > -- Best regards, Ivan Pavlukhin

Re: Stop sending IGNITE Created e-mails to dev@

21 г. в 11:39, Dmitriy Pavlov : >> >> > I guess so. It was always not clear for me why do we have 'contributors >> > 1' >> > role. >> > >> > It might worth to rename role itself to contibutors with notifications. >> > >> > Sincerel

Re: Stop sending IGNITE Created e-mails to dev@

-26 12:28 GMT+03:00, Ilya Kasnacheev : > Hello! > > I have added you to "Contributors 1" role. Everybody in this role will > still get those "issue created" e-mail. > > Feel free in asking me to enlist. > > Regards, > -- > Ilya Kasnacheev > > &

Re: Stop sending IGNITE Created e-mails to dev@

tter I siggest improving analysis to avoid odd > emails and leave only relevant > > чт, 22 апр. 2021 г., 18:16 Ivan Pavlukhin : > >> > All issues notifications are also sent to iss...@ignite.apache.org so >> one can subscribe to this list in order to track the crea

Re: Stop sending IGNITE Created e-mails to dev@

>> > > > > > lot >> > of >> > > > > screen >> > > > > > space, it's hard to spot genuine discussions in >> > > > > > https://lists.apache.org/list.html?dev@ignite.apache.org for >> > > example.

Re: [DISCUSSION] Javadoc style requirements and checks in Ignite-3.

ll, which looks > like not a good idea, > or have different configs with different policies for source and test code. > > Any thoughts? > > [1] https://issues.apache.org/jira/browse/IGNITE-14591 > [2] https://github.com/apache/ignite-3/pull/98 > [3] http://openjdk.java.net/jeps/8068562 > > -- > Best regards, > Andrey V. Mashenkov > -- Best regards, Ivan Pavlukhin

Re: Stop sending IGNITE Created e-mails to dev@

ribe to these messages in their JIRA account settings. I imagine >> > most >> > > of you already filter these messages out, so you may need to adjust >> > > your >> > > filters slightly. >> > > >> > > A distant second is MTCGA messages, which are also autogenerated and >> > > not >> > > informative for most readers of the channel, since they are at best >> > > targeted at a single committer and at worst flaky. >> > > >> > > Where could we move those? What is your opinion here, on both issues? >> > > >> > > Regards, >> > >> > -- >> > Regards, >> > >> > Atri >> > Apache Concerted >> > > -- Best regards, Ivan Pavlukhin

Re: [ANNOUNCE] Welcome Ivan Daschinsky as a new committer

ctive community member. >>> >>> Being a committer enables easier contribution to the project since there >>> is >>> no need to go via the patch submission process. This should enable >>> better >>> productivity. >>> >>> Please join me in welcoming Ivan, and congratulating him on the new role >>> in >>> the Apache Ignite Community. >>> >>> Best Regards, >>> Igor >> >> >> >> > > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

; examples for the table, transaction, compute APIs? > WDYT? > > [1] > https://stackoverflow.com/questions/43389894/recursively-cancel-an-allof-completablefuture > > On Sat, Apr 3, 2021 at 1:40 AM Ivan Pavlukhin wrote: > >> Andrey, >> >> As you might kn

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

ase/api/reactor/core/publisher/Mono.html#fromFuture-java.util.concurrent.CompletableFuture- > [2] > https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/internal/jdk8/CompletableFromCompletionStage.java > > On Thu, Apr 1, 2021 at 1:29 PM Ivan Pavlukhin wrote

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

active abstractions look more suitable for Queries rather than > cache/table async operations and don't offer the power of chaining like > CompletableStage. > AFAIK, guys who involved in SQL engine development based on Calcite already > use reactive patterns. > > > On Thu, Apr

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

; > > > > вт, 30 мар. 2021 г. в 13:14, Andrey Mashenkov < >> > > > > > andrey.mashen...@gmail.com >> > > > > > > >: >> > > > > > > >> > > > > > > > Guys, >> > > > &g

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

> CompletableFuture is surely wrong in my view. > > At the same time, if we take a fundamentally different route with the async > APIs, this whole discussion might become irrelevant. For example, can you > elaborate on your thinking around the reactive API? Do you have any > specif

Re: Significant Items to Tackle

; >> Now that I have worked on some issues, I would like to get my hands >> deeper >> and with larger issues in the core. Also, some more intermediate tickets >> to >> tackle, my queue has gotten empty :) >> >> Please help and advice. >> >> Regards, >> >> Atri > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] IgniteFuture class future in Ignite-3.0.

gt;>>>>> Thus, this look like an applicable solution, but we should be >> > >> careful >> > >>>>>> exposing internal future to the outside. >> > >>>>>> >> > >>>>>> 2. The second approach is to implement our own interface like >> > >>>>>> the >> > >>> next >> > >>>>> one: >> > >>>>>> >> > >>>>>> interface IgniteFuture extends CompletableStage, Future >> > >>>>>> { >> > >>>>>> } >> > >>>>>> >> > >>>>>> Pros and cons are >> > >>>>>> + Our interfaces/classes contracts will expose an interface >> > >>>>>> rather >> > >>> than >> > >>>>>> concrete implementation. >> > >>>>>> + All methods are safe. >> > >>>>>> - Some implementation is required. >> > >>>>>> - CompletableStage has a method toCompletableFuture() and can be >> > >>>>> converted >> > >>>>>> to CompletableFuture. This should be supported. >> > >>>>>> >> > >>>>>> However, we still could wrap CompletableFuture and don't bother >> > >> about >> > >>>>>> creating a defensive copy. >> > >>>>>> >> > >>>>>> >> > >>>>>> Other project experience: >> > >>>>>> * Spotify uses CompletableFuture directly [1]. >> > >>>>>> * Redis goes the second approach [2] >> > >>>>>> * Vertx explicitly extends CompletableFuture [3]. However, they >> > >> have >> > >>>>> custom >> > >>>>>> future classes and a number of helpers that could be replaced >> > >>>>>> with >> > >>>>>> CompletableStage. Maybe it is just a legacy.' >> > >>>>>> >> > >>>>>> Any thoughts? >> > >>>>>> >> > >>>>>> [1] >> > >>>>>> >> > >>>>>> >> > >>>>> >> > >>>> >> > >>> >> > >> >> > >> https://spotify.github.io/completable-futures/apidocs/com/spotify/futures/ConcurrencyReducer.html >> > >>>>>> [2] >> > >>>>>> >> > >>>>>> >> > >>>>> >> > >>>> >> > >>> >> > >> >> > >> https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html >> > >>>>>> [3] >> > >>>>>> >> > >>>>>> >> > >>>>> >> > >>>> >> > >>> >> > >> >> > >> https://javadoc.io/static/org.jspare.vertx/vertx-jspare/1.1.0-M03/org/jspare/vertx/concurrent/VertxCompletableFuture.html >> > >>>>>> -- >> > >>>>>> Best regards, >> > >>>>>> Andrey V. Mashenkov >> > >>>>>> >> > >>>>> >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> >> > >>>> Best regards, >> > >>>> Alexei Scherbakov >> > >>>> >> > >>> >> > >> >> > >> >> > >> -- >> > >> Best regards, >> > >> Alexey >> > >> >> > >> > >> >> -- >> Best regards, >> Andrey V. Mashenkov >> > -- Best regards, Ivan Pavlukhin

Re: How to Contribute 2021

the IDE). >> > >> > > >> > >> > I would be glad if somebody contributes to it, or we may just >> > >> > provide >> > a >> > >> > link to coding guidelines and mention it there. >> > >> > >> > >> > >> > >> > >> > >> > > > GIT workflow >> > >> > > >> > >> > > Do we need it? >> > >> > > >> > >> > I think we do, this workflow is non-trivial and I don't think it >> > >> > is >> > >> > documented anywhere. We can get rid of ASCII art section, though. >> > >> > >> > >> > WDYT? >> > >> > >> > >> > Regards, >> > >> > >> > >> > >> > >> > > >> > >> > > >> > >> > > On Mon, 15 Mar 2021 at 17:25, Ilya Kasnacheev < >> > >> ilya.kasnach...@gmail.com >> > >> > > >> > >> > > wrote: >> > >> > > > >> > >> > > > Hello! >> > >> > > > >> > >> > > > When adding new users to the Contributor role, we usually give >> > them >> > >> a >> > >> > > link >> > >> > > > to "How to Contribute" wiki page. >> > >> > > > >> > >> > > > However, I was feeling that it was in many ways outdated, >> > referring >> > >> to >> > >> > > > outdated development practices and not emphasising TC tests >> > >> > > > and >> > >> MTCGA >> > >> > > bot. >> > >> > > > >> > >> > > > So we took liberty to rewrite this page, meet >> > >> > > > >> > >> > > >> > >> > >> > >> >> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021 >> > >> > > > >> > >> > > > We tried to streamline it, make it more friendly to newcomers >> > >> > > > and >> > >> just >> > >> > > > shorter. >> > >> > > > >> > >> > > > Please check it out, share your feelings. >> > >> > > > >> > >> > > > I plan to replace the legacy >> > >> > > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> > >> > > with >> > >> > > > this page based on your feedback.. >> > >> > > > >> > >> > > > Regards, >> > >> > > > -- >> > >> > > > Ilya Kasnacheev >> > >> > > >> > >> > >> > >> >> > > >> > > -- Best regards, Ivan Pavlukhin

Re: How to Contribute 2021

t;> ilya.kasnach...@gmail.com >> > > >> > > wrote: >> > > > >> > > > Hello! >> > > > >> > > > When adding new users to the Contributor role, we usually give them >> > > > a >> > > link >> > > > to "How to Contribute" wiki page. >> > > > >> > > > However, I was feeling that it was in many ways outdated, referring >> to >> > > > outdated development practices and not emphasising TC tests and >> > > > MTCGA >> > > bot. >> > > > >> > > > So we took liberty to rewrite this page, meet >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021 >> > > > >> > > > We tried to streamline it, make it more friendly to newcomers and >> just >> > > > shorter. >> > > > >> > > > Please check it out, share your feelings. >> > > > >> > > > I plan to replace the legacy >> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> > > with >> > > > this page based on your feedback.. >> > > > >> > > > Regards, >> > > > -- >> > > > Ilya Kasnacheev >> > > >> > >> > -- Best regards, Ivan Pavlukhin

Re: [MTCGA]: new failures in builds [5882649] needs to be handled

gt; https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> - Should you have any questions please contact >> dev@ignite.apache.org >> >> Best Regards, >> Apache Ignite TeamCity Bot >> https://github.com/apache/ignite-teamcity-bot >> Notification generated at 06:06:54 20-02-2021 > > -- > Regards, > > Atri > Apache Concerted > -- Best regards, Ivan Pavlukhin

Re: Disable MVCC test suites

gt; > On Mon, 7 Dec 2020 at 09:38, Ivan Pavlukhin wrote: >> >> Hi Igniters, >> >> > The feature is not production-ready, and I don't think it is used at >> > all. >> >> Unfortunately, we cannot be sure that the feature is not used at all. >> I re

Re: [Discussion] Kanban board for quick start issues to join the community

> > >> > I have seen few Apache Project like Beam, Flink already uses Kanban >> > board >> > >> > >> https://issues.apache.org/jira/secure/RapidBoard.jspa?projectKey=BEAM=325 >> > >> > >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=356=FLINK >> > >> > Please review and let me know your thoughts. >> > >> > Regards >> > Saikat >> > >> > -- Best regards, Ivan Pavlukhin

Re: SHA-512 for Maven deployment

w? >> >2. Is there a painless way to include SHA512 in addition to >> > MD5/SHA1? >> > >> > Can anyone shed some light on this? >> > >> > [1] https://infra.apache.org/release-signing.html#basic-facts >> > [2] >> > >> > >> https://repository.apache.org/content/repositories/orgapacheignite-1490/org/apache/ignite/ignite-core/2.9.1/ >> > [3] >> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html >> > >> > -Val >> > >> >> >> -- >> Sincerely yours, >> Ivan Bessonov >> > -- Best regards, Ivan Pavlukhin

Re: [DISCUSSION] 3.0.0 Alpha release

gt; > > >> >> > > > >> On Sun, Dec 27, 2020 at 2:18 AM Valentin Kulichenko < >> > > > >> valentin.kuliche...@gmail.com> wrote: >> > > > >> >> > > > >> > Folks, >> > > > >> >

Re: [ANNOUNCE] Welcome Ivan Bessonov as a new committer

committer enables easier contribution to the project since there >> is >> no need to go via the patch submission process. This should enable better >> productivity. >> >> Please join me in welcoming Ivan, and congratulating him on the new role >> in >> the Apache Ignite Community. >> >> Best Regards, >> Andrey Gura >> > -- Best regards, Ivan Pavlukhin

Re: [COMMUNITY] Recognizing those who contribute to user support and project awareness

Year gifts. >> >> >> In 2021, we want to track this type of contribution and ensure that the >> contributors are recognized within the community. The Alfa version of our >> tracking system is already functioning inside GridGain, so the next step >> is >> to upgrade the current system and start a discussion with PMC members. >> Those who help to attract and retain users are definitely worthy of >> praise >> and promotion, as the value of their contribution matches the value that >> is >> provided through code and documentation. >> >> >> Keep being awesome and have a Happy New Year! >> >> >> Kseniya >> >> DevRel at GridGain >> > -- Best regards, Ivan Pavlukhin

Re: [DISCUSS] Notifications for ignite-3 repository

n's PR was merged >> >> ср, 23 дек. 2020 г. в 21:55, Pavel Tupitsyn : >> >>> Ivan, thank you for fixing this! >>> >>> On Wed, Dec 23, 2020 at 11:13 AM Ivan Pavlukhin >>> wrote: >>> >>> > Actually a first attempt was not su

Re: [DISCUSS] Notifications for ignite-3 repository

anymore. 2020-12-22 13:05 GMT+03:00, Ivan Pavlukhin : > Ticket was merged. Thanks to all participants. > > 2020-12-21 10:12 GMT+03:00, Ivan Pavlukhin : >> Folks, >> >> I will merge the PR tomorrow if there is no objections. >> >> 2020-12-19 0:56 GMT+03:00, V

Re: [DISCUSS] Ignite 3.0 development approach

rticle/github-to-replace-master-with-main-starting-next-month/ > > On Tue, Dec 22, 2020 at 1:12 PM Ivan Pavlukhin wrote: > >> Also I noticed that ignite-3 repository has "main" but not "master" >> branch. Who can shed light on this? Did not find an explana

Re: [DISCUSS] Ignite 3.0 development approach

Also I noticed that ignite-3 repository has "main" but not "master" branch. Who can shed light on this? Did not find an explanation in this thread. 2020-12-22 13:09 GMT+03:00, Ivan Pavlukhin : > I noticed some free-from commit messages in ignite-3 repository. I > think

Re: [DISCUSS] Ignite 3.0 development approach

e feel free to share your thoughts on >> this. >> >> -Val >> >> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin >> wrote: >> >>> Hi Igniters, >>> >>> Forgive me that I am not reading dev list carefully these days. Was it >>

Re: [DISCUSS] Notifications for ignite-3 repository

Ticket was merged. Thanks to all participants. 2020-12-21 10:12 GMT+03:00, Ivan Pavlukhin : > Folks, > > I will merge the PR tomorrow if there is no objections. > > 2020-12-19 0:56 GMT+03:00, Valentin Kulichenko > : >> Folks, >> >> Can someone take

Re: [DISCUSSION] 3.0.0 Alpha release

pgraded, how the user will interact with it, etc. I >> would >> > > like to use this to gather feedback from the community in the early >> > stages. >> > > >> > > To make sure the experience is as close to real life as possible, I >> want >> > to >> > > deliver what we have as an alpha release, meaning that all the >> > > required >> > > binaries will be deployed on the website and in Maven. There will >> > > also >> be >> > > some basic documentation describing how to install and use the >> > > product. >> > > This way, anyone will be able to download the product and try it out. >> > > >> > > My main question here -- do we need a formal vote for such a build? >> > > Or >> it >> > > can be treated as a release candidate? >> > > >> > > Any other thoughts? >> > > >> > > [1] https://github.com/apache/ignite-3 >> > > >> > > -Val >> > > >> > >> > -- Best regards, Ivan Pavlukhin

Re: [DISCUSS] Notifications for ignite-3 repository

Dec 17, 2020 at 11:16 PM Ivan Pavlukhin > wrote: > >> Igniters, >> >> I noticed notifications about PRs in ignite-3 repository sent to >> dev-list. I suppose we should configure notifications similar to main >> ignite repository. I prepared a ticket [1] and PR for

[DISCUSS] Notifications for ignite-3 repository

, Ivan Pavlukhin

[jira] [Created] (IGNITE-13875) Configure notifications for ignite-3 git repository

Ivan Pavlukhin created IGNITE-13875: --- Summary: Configure notifications for ignite-3 git repository Key: IGNITE-13875 URL: https://issues.apache.org/jira/browse/IGNITE-13875 Project: Ignite

Re: [DISCUSS] Ignite 3.0 development approach

gt; heard >> > > > any >> > > > > > clear alternatives or reasons why we shouldn't do this. >> > > > > > >> > > > > > That said, I'm inclined to proceed with this in the >> > next >> > few >> > > days - I >> > > > > will >> > > > > > create a repo and describe the process (which we, of >> > course, can >> > > > discuss >> > > > > > and modify going forward). Let's, at the very least, >> > try >> > and see >> > > where >> > > > it >> > > > > > leads us. >> > > > > > >> > > > > > If someone has any concrete alternative options on how >> > to >> > we can >> > > > maintain >> > > > > > two major versions in parallel, let's have another >> > voice >> > > discussion >> > > > this >> > > > > > Friday. If we do the meeting, we should set it up with >> > a >> > clear >> > > goal to >> > > > > make >> > > > > > a decision. Please let me know if there is interest in >> > this. >> > > > > > >> > > > > > -Val >> > > > > > >> > > > > > On Mon, Nov 16, 2020 at 6:31 AM Alexey Goncharuk < >> > > > > > alexey.goncha...@gmail.com> wrote: >> > > > > > >> > > > > >> Good, >> > > > > >> >> > > > > >> I think we have an intermediate agreement on the scope >> and >> > > > significance >> > > > > of >> > > > > >> the changes we want to make. I suggest creating >> > separate >> > > discussion >> > > > > >> streams >> > > > > >> and calls for each of the suggested topics so that: >> > > > > >> >> > > > > >>- It is clear for the community what is the >> motivation >> > of the >> > > > stream >> > > > > >>(this includes both functional targets and >> > technical >> > debt >> > > issues >> > > > > >> pointed >> > > > > >>out by Sergey) >> > > > > >>- Who is planning to take an active part in each of >> the >> > > streams >> > > > (i.e. >> > > > > >>the 'design committee', as Sergey suggested) >> > > > > >>- What are the intermediate and final goals for >> > each >> > of the >> > > streams >> > > > > >>- What are the cross-stream interactions and how we >> > > integrate them >> > > > > >>- How each of the streams will be integrated with >> > the >> > current >> > > > > codebase >> > > > > >>based on the above (here is where we will see >> > whether >> > > drop-in or >> > > > > >>incremental approaches make more sense) >> > > > > >> >> > > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > Best regards, >> > > > Andrey V. Mashenkov >> > > > >> > > >> > > >> > >> > >> > -- Best regards, Ivan Pavlukhin

Re: Disable MVCC test suites

or complete MVCC removal. >> >>>>>>> It has already been discussed here [1] and, unfortunately, I have >> >> not >> >>>>>> seen >> >>>>>>> an agreement on that. >> >>>>>>> >> >>>>>>> [1] >> >>>>>>> >> >>>>>> >> >>>> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html >> >>>>>>> >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> S. >> >>>>>>> >> >>>>>>> ср, 2 дек. 2020 г. в 13:05, Nikolay Izhikov >> >>>>>>> : >> >>>>>>> >> >>>>>>>> +1 to vote for complete MVCC removal. >> >>>>>>>> >> >>>>>>>> MVCC is a great feature but we should implement it as a >> >> first-class >> >>>>>>>> feature and not «something that pretends to be working» >> >>>>>>>> >> >>>>>>>>> 2 дек. 2020 г., в 12:53, Maxim Muzafarov >> >>>>>> написал(а): >> >>>>>>>>> >> >>>>>>>>> Hello Slava, >> >>>>>>>>> >> >>>>>>>>> I think we should vote for MVCC termination of support. If the >> >> vote >> >>>>>>>>> will be successful than remove it from the source code and >> >> disable >> >>>>>>>>> MVCC suites. >> >>>>>>>>> >> >>>>>>>>> Only disabling tests from MVCC sounds not good. >> >>>>>>>>> >> >>>>>>>>> On Wed, 2 Dec 2020 at 12:32, Вячеслав Коптилин < >> >>>>>> slava.kopti...@gmail.com> >> >>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> Hello Igniters, >> >>>>>>>>>> >> >>>>>>>>>> It looks like there is no activity related to maintaining or >> >>>>>> developing >> >>>>>>>> the >> >>>>>>>>>> MVCC feature. >> >>>>>>>>>> So, I see no reason to waste TeamCity resources. I propose to >> >>>> disable >> >>>>>>>> the >> >>>>>>>>>> corresponding test suites. >> >>>>>>>>>> This has already been discussed here as well [1]. >> >>>>>>>>>> >> >>>>>>>>>> [1] >> >>>>>>>>>> >> >>>>>>>> >> >>>>>> >> >>>> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html >> >>>>>>>>>> >> >>>>>>>>>> Thanks, >> >>>>>>>>>> S. >> >>>>>>>> >> >>>>>>>> >> >>>>>> >> >>>>>> >> >>>> >> >>>> >> >> >> >> > -- Best regards, Ivan Pavlukhin

Re: [VOTE] Define Apache Ignite as a Distributed Database

e >> > > > website. There is nothing wrong if a distributed database is used >> > > > as >> a >> > > > cache or high-performance compute cluster; it's up to an >> > > > application >> > > > developer to decide. >> > > > >> > > > Overall, please cast your vote for defining Ignite as a >> > > > "distributed >> > > > database": >> > > > +1 - support the change >> > > > -1 - disagree with the change, explain why >> > > > 0 - neutral >> > > > >> > > > This is a majority vote that is open for the next 7 days and to be >> > closed >> > > > on Monday, Nov 30th: >> > > > https://www.timeanddate.com/countdown/to?year=2020=11=30 >> > > > >> > > > - >> > > > Denis >> > > > >> > > >> > >> > -- Best regards, Ivan Pavlukhin

Re: Alex Plehanov joins Ignite Project Management Committee

>>>> < >>>> https://issues.apache.org/jira/browse/IGNITE-13595?jql=project%20%3D%20Ignite%20and%20assignee%20%3D%20alex_pl%20and%20status%20in%20(Closed%2C%20Resolved) >>>>> >>>> since >>>> then, was driving Ignite 2.9 as a release manager, regularly >>>> participates >>>> in the dev lists discussions pertaining to the future and evolution of >>>> Ignite. >>>> >>>> Join me in congratulating Alex! >>>> >>>> >>>> - >>>> Denis >>>> >> >> >> >> -- >> Best wishes, >> Amelchev Nikita > > -- Best regards, Ivan Pavlukhin

Re: [DISCUSS] Missed (non-suited) tests

also created verification check for not >> included test and found a few tests, that have never been included in any >> testsuites. >> >> Also, I suppose, that even if we cannot run some tests, these tests >> should >> be ignored using anno

Re: [DISCUSS] Missed (non-suited) tests

lOnheapExpiryPolicyTest > GridCacheReplicatedOnheapFullApiSelfTest > GridCacheBinaryObjectsLocalOnheapSelfTest > > oignate...@users.noreply.github.com: > GridCacheTtlManagerEvictionSelfTest > > ira...@apache.org: > CommonPoolStarvationCheckpointTest > > alievmi...@gmail.com: > RemoveAllDeadlockTest > > schugu...@gridgain.com: > FullyConnectedComponentSearcherTest > > sboi...@gridgain.com: > IgniteDataStructuresNoClassOnServerTest > > timonin.ma...@gmail.com: > ReliableChannelTest > ThinClientPartitionAwarenessDiscoveryTest > -- Best regards, Ivan Pavlukhin

Re: Continuous query not transactional ?

a. > > > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > -- Best regards, Ivan Pavlukhin

Re: [DISCUSS] Remove a Patch-file contribution approach from guides

t; вс, 11 окт. 2020 г. в 04:43, Saikat Maitra : > >> +1 >> >> Regards, >> Saikat >> >> On Sat, Oct 10, 2020 at 8:22 AM Alexey Zinoviev >> wrote: >> >> > Agree, need to update >> > >> > сб, 10 окт. 2020 г., 15:35 Ivan Pa

Re: New Committer: Sergey Stronchinskiy

ould enable better > productivity. > > Sergey, congratulations and welcome on board! > > Best Regards, > Pavel Tupitsyn > on behalf of Apache Ignite PMC > -- Best regards, Ivan Pavlukhin

[DISCUSS] Remove a Patch-file contribution approach from guides

] http://apache-ignite-developers.2346864.n4.nabble.com/Disabling-patch-validation-mechanism-on-TC-td5400.html -- Best regards, Ivan Pavlukhin

Re: Introduction

on is outdated, I would happily open a pull request on > github instead. > > BRs, > Bojidar > > On Fri, Oct 9, 2020 at 6:20 PM Ivan Pavlukhin wrote: > >> Bojidar, >> >> While my knowledge can be outdated, but in my time it was required to >> create a

Re: Introduction

I would like to contribute to it starting with issue > IGNITE-13563, my JIRA username being bojidar-bg. > I have already submitted a patch, and reviews would be welcome. > > BRs, > Bojidar > -- Best regards, Ivan Pavlukhin

Re: [MTCGA]: new failures in builds [5643882] needs to be handled

stem-functions.adoc >> > docs/_docs/sql-reference/aggregate-functions.adoc >> > docs/_docs/sql-reference/data-types.adoc >> > docs/_docs/sql-reference/dml.adoc >> > docs/_docs/sql-reference/date-time-functions.adoc >> > docs/_doc

  1   2   3   4   5   6   >