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: [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: 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: 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: 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

; 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] 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: 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: 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: 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: [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: [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] 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

> 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: [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

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] @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] @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: [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: 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: [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: [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] 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] 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

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] 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: [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: CVE-2021-42392

Regards, > Vishwas > -- 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

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

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: [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 г

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: [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

[jira] [Created] (IGNITE-9125) MVCC SQL: Streaming SQL data load operations support

Ivan Pavlukhin created IGNITE-9125: -- Summary: MVCC SQL: Streaming SQL data load operations support Key: IGNITE-9125 URL: https://issues.apache.org/jira/browse/IGNITE-9125 Project: Ignite

[jira] [Created] (IGNITE-9233) MVCC SQL: False write conflicts on fast updates

Ivan Pavlukhin created IGNITE-9233: -- Summary: MVCC SQL: False write conflicts on fast updates Key: IGNITE-9233 URL: https://issues.apache.org/jira/browse/IGNITE-9233 Project: Ignite Issue

[jira] [Created] (IGNITE-9292) MVCC SQL: Race during updating TX log on near backup

Ivan Pavlukhin created IGNITE-9292: -- Summary: MVCC SQL: Race during updating TX log on near backup Key: IGNITE-9292 URL: https://issues.apache.org/jira/browse/IGNITE-9292 Project: Ignite

[jira] [Created] (IGNITE-9300) Removal count metric is calculated improperly for transactional cache

Ivan Pavlukhin created IGNITE-9300: -- Summary: Removal count metric is calculated improperly for transactional cache Key: IGNITE-9300 URL: https://issues.apache.org/jira/browse/IGNITE-9300 Project

[jira] [Created] (IGNITE-9224) MVCC SQL: Cache metrics

Ivan Pavlukhin created IGNITE-9224: -- Summary: MVCC SQL: Cache metrics Key: IGNITE-9224 URL: https://issues.apache.org/jira/browse/IGNITE-9224 Project: Ignite Issue Type: Improvement

[jira] [Created] (IGNITE-9373) MVCC tests fail

Ivan Pavlukhin created IGNITE-9373: -- Summary: MVCC tests fail Key: IGNITE-9373 URL: https://issues.apache.org/jira/browse/IGNITE-9373 Project: Ignite Issue Type: Bug Components

[jira] [Created] (IGNITE-9404) Ignite start hangs infinitely when sync preloading is cancelled

Ivan Pavlukhin created IGNITE-9404: -- Summary: Ignite start hangs infinitely when sync preloading is cancelled Key: IGNITE-9404 URL: https://issues.apache.org/jira/browse/IGNITE-9404 Project: Ignite

[jira] [Created] (IGNITE-9062) MVCC SQL: H2 connection and statement cache reafactoring

Ivan Pavlukhin created IGNITE-9062: -- Summary: MVCC SQL: H2 connection and statement cache reafactoring Key: IGNITE-9062 URL: https://issues.apache.org/jira/browse/IGNITE-9062 Project: Ignite

[jira] [Created] (IGNITE-9506) Timeout object with mutable end time breaks GridTimeoutProcessor behavior

Ivan Pavlukhin created IGNITE-9506: -- Summary: Timeout object with mutable end time breaks GridTimeoutProcessor behavior Key: IGNITE-9506 URL: https://issues.apache.org/jira/browse/IGNITE-9506

[jira] [Created] (IGNITE-9516) Vaccum cannot complete after rebalance

Ivan Pavlukhin created IGNITE-9516: -- Summary: Vaccum cannot complete after rebalance Key: IGNITE-9516 URL: https://issues.apache.org/jira/browse/IGNITE-9516 Project: Ignite Issue Type: Bug

[jira] [Created] (IGNITE-8982) SQL TX: reuse H2 connections

Ivan Pavlukhin created IGNITE-8982: -- Summary: SQL TX: reuse H2 connections Key: IGNITE-8982 URL: https://issues.apache.org/jira/browse/IGNITE-8982 Project: Ignite Issue Type: Improvement

[jira] [Created] (IGNITE-10103) Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation

Ivan Pavlukhin created IGNITE-10103: --- Summary: Fix IgnitePersistentStoreDataStructuresTest.testSequenceAfterAutoactivation Key: IGNITE-10103 URL: https://issues.apache.org/jira/browse/IGNITE-10103

[jira] [Created] (IGNITE-10063) MVCC SQL: Tx SQL commands are not supported in multistatements

Ivan Pavlukhin created IGNITE-10063: --- Summary: MVCC SQL: Tx SQL commands are not supported in multistatements Key: IGNITE-10063 URL: https://issues.apache.org/jira/browse/IGNITE-10063 Project

[jira] [Created] (IGNITE-10167) MVCC-compatible IgniteCache.localEntries

Ivan Pavlukhin created IGNITE-10167: --- Summary: MVCC-compatible IgniteCache.localEntries Key: IGNITE-10167 URL: https://issues.apache.org/jira/browse/IGNITE-10167 Project: Ignite Issue Type

[jira] [Created] (IGNITE-9783) MVCC: Track all nodes participating in transaction

Ivan Pavlukhin created IGNITE-9783: -- Summary: MVCC: Track all nodes participating in transaction Key: IGNITE-9783 URL: https://issues.apache.org/jira/browse/IGNITE-9783 Project: Ignite

[jira] [Created] (IGNITE-9774) CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan hangs

Ivan Pavlukhin created IGNITE-9774: -- Summary: CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan hangs Key: IGNITE-9774 URL: https://issues.apache.org/jira/browse/IGNITE-9774

[jira] [Created] (IGNITE-9750) Prohibit near cache configuration for MVCC caches

Ivan Pavlukhin created IGNITE-9750: -- Summary: Prohibit near cache configuration for MVCC caches Key: IGNITE-9750 URL: https://issues.apache.org/jira/browse/IGNITE-9750 Project: Ignite Issue

[jira] [Created] (IGNITE-9735) Determine partitions during parsing for MVCC DML statements

Ivan Pavlukhin created IGNITE-9735: -- Summary: Determine partitions during parsing for MVCC DML statements Key: IGNITE-9735 URL: https://issues.apache.org/jira/browse/IGNITE-9735 Project: Ignite

[jira] [Created] (IGNITE-9451) Cache API update Cache.size according to SNAPSHOT isolation

Ivan Pavlukhin created IGNITE-9451: -- Summary: Cache API update Cache.size according to SNAPSHOT isolation Key: IGNITE-9451 URL: https://issues.apache.org/jira/browse/IGNITE-9451 Project: Ignite

[jira] [Created] (IGNITE-9459) MVCC Cache.size corner cases

Ivan Pavlukhin created IGNITE-9459: -- Summary: MVCC Cache.size corner cases Key: IGNITE-9459 URL: https://issues.apache.org/jira/browse/IGNITE-9459 Project: Ignite Issue Type: Bug

[jira] [Created] (IGNITE-9647) EVT_CACHE_OBJECT_REMOVED is fired when entry is absent before remove

Ivan Pavlukhin created IGNITE-9647: -- Summary: EVT_CACHE_OBJECT_REMOVED is fired when entry is absent before remove Key: IGNITE-9647 URL: https://issues.apache.org/jira/browse/IGNITE-9647 Project

[jira] [Created] (IGNITE-10999) NOT NULL sql constraint is not checked for data streamer operations

Ivan Pavlukhin created IGNITE-10999: --- Summary: NOT NULL sql constraint is not checked for data streamer operations Key: IGNITE-10999 URL: https://issues.apache.org/jira/browse/IGNITE-10999 Project

[jira] [Created] (IGNITE-11020) Document edge-chasing deadlock detection

Ivan Pavlukhin created IGNITE-11020: --- Summary: Document edge-chasing deadlock detection Key: IGNITE-11020 URL: https://issues.apache.org/jira/browse/IGNITE-11020 Project: Ignite Issue Type

[jira] [Created] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration

Ivan Pavlukhin created IGNITE-11029: --- Summary: Public API for edge-chasing deadlock detection configuration Key: IGNITE-11029 URL: https://issues.apache.org/jira/browse/IGNITE-11029 Project: Ignite

[jira] [Created] (IGNITE-10722) Abbr-plugin: refactoring inside write action error

Ivan Pavlukhin created IGNITE-10722: --- Summary: Abbr-plugin: refactoring inside write action error Key: IGNITE-10722 URL: https://issues.apache.org/jira/browse/IGNITE-10722 Project: Ignite

[jira] [Created] (IGNITE-10757) Refactoring: split MvccProcessor into multiple components

Ivan Pavlukhin created IGNITE-10757: --- Summary: Refactoring: split MvccProcessor into multiple components Key: IGNITE-10757 URL: https://issues.apache.org/jira/browse/IGNITE-10757 Project: Ignite

[jira] [Created] (IGNITE-10685) Support JTA transactions for MVCC

Ivan Pavlukhin created IGNITE-10685: --- Summary: Support JTA transactions for MVCC Key: IGNITE-10685 URL: https://issues.apache.org/jira/browse/IGNITE-10685 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-10807) Support long-running tx rollback on PME

Ivan Pavlukhin created IGNITE-10807: --- Summary: Support long-running tx rollback on PME Key: IGNITE-10807 URL: https://issues.apache.org/jira/browse/IGNITE-10807 Project: Ignite Issue Type

[jira] [Created] (IGNITE-10704) Abbr-plugin: update list of abbreviations

Ivan Pavlukhin created IGNITE-10704: --- Summary: Abbr-plugin: update list of abbreviations Key: IGNITE-10704 URL: https://issues.apache.org/jira/browse/IGNITE-10704 Project: Ignite Issue

[jira] [Created] (IGNITE-10841) Edge-chasing deadlock detection monitoring

Ivan Pavlukhin created IGNITE-10841: --- Summary: Edge-chasing deadlock detection monitoring Key: IGNITE-10841 URL: https://issues.apache.org/jira/browse/IGNITE-10841 Project: Ignite Issue

[jira] [Created] (IGNITE-10917) IgniteCacheQueryNodeRestartSelfTest2.testRestarts stable failure

Ivan Pavlukhin created IGNITE-10917: --- Summary: IgniteCacheQueryNodeRestartSelfTest2.testRestarts stable failure Key: IGNITE-10917 URL: https://issues.apache.org/jira/browse/IGNITE-10917 Project

[jira] [Created] (IGNITE-9605) Implicit mvcc transaction could use completed one instead of starting new

Ivan Pavlukhin created IGNITE-9605: -- Summary: Implicit mvcc transaction could use completed one instead of starting new Key: IGNITE-9605 URL: https://issues.apache.org/jira/browse/IGNITE-9605

[jira] [Created] (IGNITE-9604) Implicit mvcc transaction could use completed one instead of starting new

Ivan Pavlukhin created IGNITE-9604: -- Summary: Implicit mvcc transaction could use completed one instead of starting new Key: IGNITE-9604 URL: https://issues.apache.org/jira/browse/IGNITE-9604

[jira] [Created] (IGNITE-9622) MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions

Ivan Pavlukhin created IGNITE-9622: -- Summary: MVCC Cache API: prohibit non PESSIMISTIC REPEATABLE_READ transactions Key: IGNITE-9622 URL: https://issues.apache.org/jira/browse/IGNITE-9622 Project

[jira] [Created] (IGNITE-9602) Transaction timeout setter could break GridTimeoutProcessor behavior

Ivan Pavlukhin created IGNITE-9602: -- Summary: Transaction timeout setter could break GridTimeoutProcessor behavior Key: IGNITE-9602 URL: https://issues.apache.org/jira/browse/IGNITE-9602 Project

[jira] [Created] (IGNITE-9624) Refine CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT javadoc

Ivan Pavlukhin created IGNITE-9624: -- Summary: Refine CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT javadoc Key: IGNITE-9624 URL: https://issues.apache.org/jira/browse/IGNITE-9624 Project: Ignite

[jira] [Created] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling

Ivan Pavlukhin created IGNITE-11356: --- Summary: Test framework: Remove custom assumption exceptions handling Key: IGNITE-11356 URL: https://issues.apache.org/jira/browse/IGNITE-11356 Project: Ignite

[jira] [Created] (IGNITE-11357) MVCC: SQL tx operations and DDL inside tx block

Ivan Pavlukhin created IGNITE-11357: --- Summary: MVCC: SQL tx operations and DDL inside tx block Key: IGNITE-11357 URL: https://issues.apache.org/jira/browse/IGNITE-11357 Project: Ignite

[jira] [Created] (IGNITE-11398) Remove leftover @RunWith(JUnit4.class)

Ivan Pavlukhin created IGNITE-11398: --- Summary: Remove leftover @RunWith(JUnit4.class) Key: IGNITE-11398 URL: https://issues.apache.org/jira/browse/IGNITE-11398 Project: Ignite Issue Type

[jira] [Created] (IGNITE-11503) MVCC: Handle partition loss policies

Ivan Pavlukhin created IGNITE-11503: --- Summary: MVCC: Handle partition loss policies Key: IGNITE-11503 URL: https://issues.apache.org/jira/browse/IGNITE-11503 Project: Ignite Issue Type

[jira] [Created] (IGNITE-11534) Partition loss policy is not handled properly for implicit single key transactions

Ivan Pavlukhin created IGNITE-11534: --- Summary: Partition loss policy is not handled properly for implicit single key transactions Key: IGNITE-11534 URL: https://issues.apache.org/jira/browse/IGNITE-11534

[jira] [Created] (IGNITE-11301) MVCC: Remove extra MVCC initialization messages from logs

Ivan Pavlukhin created IGNITE-11301: --- Summary: MVCC: Remove extra MVCC initialization messages from logs Key: IGNITE-11301 URL: https://issues.apache.org/jira/browse/IGNITE-11301 Project: Ignite

[jira] [Created] (IGNITE-11300) MVCC: forbid using DataStreamer with allowOverwrite=true

Ivan Pavlukhin created IGNITE-11300: --- Summary: MVCC: forbid using DataStreamer with allowOverwrite=true Key: IGNITE-11300 URL: https://issues.apache.org/jira/browse/IGNITE-11300 Project: Ignite

[jira] [Created] (IGNITE-11246) Do not use pending entries tree in MVCC execution flow

Ivan Pavlukhin created IGNITE-11246: --- Summary: Do not use pending entries tree in MVCC execution flow Key: IGNITE-11246 URL: https://issues.apache.org/jira/browse/IGNITE-11246 Project: Ignite

[jira] [Created] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page

Ivan Pavlukhin created IGNITE-11289: --- Summary: BPlusTree.AbstractForwardCursor can use obsolete page Key: IGNITE-11289 URL: https://issues.apache.org/jira/browse/IGNITE-11289 Project: Ignite

[jira] [Created] (IGNITE-11168) .NET: changing TxTimeoutOnPartitionMapExchange has no effect

Ivan Pavlukhin created IGNITE-11168: --- Summary: .NET: changing TxTimeoutOnPartitionMapExchange has no effect Key: IGNITE-11168 URL: https://issues.apache.org/jira/browse/IGNITE-11168 Project: Ignite

[jira] [Created] (IGNITE-11888) CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC

Ivan Pavlukhin created IGNITE-11888: --- Summary: CacheContinuousQueryAsyncFailoverAtomicSelfTest.testFailoverStartStopBackup fails on GG TC Key: IGNITE-11888 URL: https://issues.apache.org/jira/browse/IGNITE

[jira] [Created] (IGNITE-11901) CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple is flaky

Ivan Pavlukhin created IGNITE-11901: --- Summary: CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple is flaky Key: IGNITE-11901 URL: https://issues.apache.org/jira/browse/IGNITE-11901 Project

[jira] [Created] (IGNITE-11940) MVCC SysPropWalDeltaConsistencyTest.testPutRemoveMultinode fails frequently

Ivan Pavlukhin created IGNITE-11940: --- Summary: MVCC SysPropWalDeltaConsistencyTest.testPutRemoveMultinode fails frequently Key: IGNITE-11940 URL: https://issues.apache.org/jira/browse/IGNITE-11940

[jira] [Created] (IGNITE-11908) OOM in MVCC PDS4

Ivan Pavlukhin created IGNITE-11908: --- Summary: OOM in MVCC PDS4 Key: IGNITE-11908 URL: https://issues.apache.org/jira/browse/IGNITE-11908 Project: Ignite Issue Type: Bug

[jira] [Created] (IGNITE-11933) Build scalar scaladoc only if javadoc profile is active

Ivan Pavlukhin created IGNITE-11933: --- Summary: Build scalar scaladoc only if javadoc profile is active Key: IGNITE-11933 URL: https://issues.apache.org/jira/browse/IGNITE-11933 Project: Ignite

[jira] [Created] (IGNITE-11948) Row count statistics tests fail frequently

Ivan Pavlukhin created IGNITE-11948: --- Summary: Row count statistics tests fail frequently Key: IGNITE-11948 URL: https://issues.apache.org/jira/browse/IGNITE-11948 Project: Ignite Issue

[jira] [Created] (IGNITE-11808) Scale test execution time constant along in IgniteCacheCrossCacheTxFailoverTest

Ivan Pavlukhin created IGNITE-11808: --- Summary: Scale test execution time constant along in IgniteCacheCrossCacheTxFailoverTest Key: IGNITE-11808 URL: https://issues.apache.org/jira/browse/IGNITE-11808

[jira] [Created] (IGNITE-11951) Set ThreadLocal node name only once in JdkMarshaller

Ivan Pavlukhin created IGNITE-11951: --- Summary: Set ThreadLocal node name only once in JdkMarshaller Key: IGNITE-11951 URL: https://issues.apache.org/jira/browse/IGNITE-11951 Project: Ignite

[jira] [Created] (IGNITE-11946) Do not add java.transaction module in Ignite launch scripts

Ivan Pavlukhin created IGNITE-11946: --- Summary: Do not add java.transaction module in Ignite launch scripts Key: IGNITE-11946 URL: https://issues.apache.org/jira/browse/IGNITE-11946 Project: Ignite

[jira] [Created] (IGNITE-12039) CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in MVCC mode

Ivan Pavlukhin created IGNITE-12039: --- Summary: CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails in MVCC mode Key: IGNITE-12039 URL: https://issues.apache.org/jira/browse/IGNITE-12039 Project

<    1   2   3   4   5   6   >