Re: Hello world!
Hi Ilya, Welcome to Apache Ignite Community! As I see you already have a contributor role in JIRA (you can work on tickets). You can find some contribution guidelines in https://github.com/apache/ignite/blob/master/CONTRIBUTING.md Do not hesitate to ask in case of any questions. ср, 18 дек. 2019 г. в 10:09, Shishkov Ilya : > > Hi everyone on Apache Ignite dev list! > > I would like to contribute to Apache Ignite project. > > My ASF JIRA username: shishkovilja > > With best regards, > Shishkov Ilya, > IT Engineer at SberTech JSC > -- Best regards, Ivan Pavlukhin
Hello world!
Hi everyone on Apache Ignite dev list! I would like to contribute to Apache Ignite project. My ASF JIRA username: shishkovilja With best regards, Shishkov Ilya, IT Engineer at SberTech JSC
[jira] [Created] (IGNITE-12465) Extend test coverage [IGNITE-11995] control.sh if experimental command disabled - don't show help for experemental commands
Kirill Tkalenko created IGNITE-12465: Summary: Extend test coverage [IGNITE-11995] control.sh if experimental command disabled - don't show help for experemental commands Key: IGNITE-12465 URL: https://issues.apache.org/jira/browse/IGNITE-12465 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 Extend test coverage for IGNITE-11995 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Ignite meetup at Google Headquarters on Dec 18th
Thanks for prompt response,definitely we would like start in-memory computing group in India. Thanks, Prashant Rahulkar. On Wed, 18 Dec 2019 at 00:00, Denis Magda wrote: > Hello Prashant, > > Unfortunately, this session won't be broadcasted and recorded. However, > community members do webinars regularly and, for instance, Saikat is > presenting tomorrow: https://www.gridgain.com/resources/webinars (GridGain > provides a platform for webinars, soon will add a page with webinars > recordings to Ignite website). > > Also, there are many in-memory computing groups worldwide that present > Ignite talks frequently. If you are interested, in the future, you can > start such a group in India and the community will help you with its growth > and content: https://www.meetup.com/pro/in-memory-computing/ > > > - > Denis > > > On Mon, Dec 16, 2019 at 8:14 PM Prashant Rahulkar < > prashantrahul...@gmail.com> wrote: > > > Hello Denis, > > We are from remote place, we would also like to attend the session. > > Is there any chance for us to connect by conference. > > > > Thanks, > > Prashant Rahulkar. > > > > On Tue, 17 Dec 2019 at 04:46, Denis Magda wrote: > > > > > Just a reminder for those who live/work nearby. > > > > > > We've already got 200 registrations for in-memory computing essentials > > talk > > > across Silicon Valley JUG and in-memory computing groups. We're running > > out > > > of chairs but still have a few left, join! > > > > > > - > > > Denis > > > > > > > > > On Mon, Dec 9, 2019 at 1:52 AM Denis Magda wrote: > > > > > > > Igniters, > > > > > > > > This month we united with Silicon Valley Java User Group and we'll be > > > > repeating In-Memory Computing Essentials for Software Engineers > session > > > at > > > > Google HQ. > > > > > > > > Come over to meet in person, a lot of coding and practical examples. > > RSVP > > > > using our local group below (and attend it to not miss future > > > gatherings): > > > > > https://www.meetup.com/Bay-Area-In-Memory-Computing/events/267050035/ > > > > > > > > - > > > > Denis > > > > > > > > > > > > > -- > > ~ Rahul > > > -- ~ Rahul
Re: Cache 6 suite is broken
Igniters, I run tests several times for my PR [1] and results [2] looks somehow better than in master [3]. But the problematic test seems too flaky. So, I cannot decide between 2 options: 1. Apply PR [1]. 2. Ignore the problematic test. (Unfortunately do not have a chance to investigate and fix) Someone's opinion would be helpful here. [1] https://github.com/apache/ignite/pull/7142 [2] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7142%2Fhead&buildTypeTab=overview [3] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&buildTypeTab=overview пн, 16 дек. 2019 г. в 13:38, Ivan Pavlukhin : > > An update. After increasing NetworkTimeout [1] the test passes rarely [2]. > > [1] https://github.com/apache/ignite/pull/7142/files > [2] > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7142%2Fhead&buildTypeTab=overview > > пн, 16 дек. 2019 г. в 09:07, Ivan Pavlukhin : > > > > Hi, > > > > I noticied that Cache 6 suite finishes badly (exit code 137) almost > > everytime [1] on master. It started recently. A problematic test > > inside is IgniteCache150ClientsTest. I made some attempts to fix the > > test (including reverting recent commits), but had no luck. And a hard > > part here is that I do not know whether the issue was caused by code > > changes or it is infrastructural one. My best attempt was increasing > > NetworkTimeout in test IgniteConfiguration [2]. After that the suite > > was able to finish, but IgniteCache150ClientsTest failed. Also, the > > problematic test seems so flaky, there are many failures in history. > > > > Do not have any really good solution in my mind. I see following options: > > 1. Use workaround in PR [2]. > > 2. Ignore test and dig deeper in scope of a separate ticket. > > > > What do you think? > > > > [1] > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&buildTypeTab=overview > > [2] https://github.com/apache/ignite/pull/7142/files > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
+1 to include PME free switch to 2.8 ср, 18 дек. 2019 г., 8:31 Anton Vinogradov : > Maxim, > https://issues.apache.org/jira/browse/IGNITE-9913 (Pme-free switch) ready > to be merged to master. > How about to include it to the 2.8 too? > > On Tue, Dec 17, 2019 at 3:31 PM Ivan Pavlukhin > wrote: > > > Maxim, > > > > I cherry-picked https://issues.apache.org/jira/browse/IGNITE-12424 to > > 2.8 branch. > > > > вт, 17 дек. 2019 г. в 15:23, Ivan Pavlukhin : > > > > > > Maxim, > > > > > > Regarding blocker tickets: > > > https://issues.apache.org/jira/browse/IGNITE-2176 -- moved to next > > version > > > https://issues.apache.org/jira/browse/IGNITE-8552 -- moved to next > > version > > > https://issues.apache.org/jira/browse/IGNITE-9489 -- fixed in scope of > > > another ticket > > > https://issues.apache.org/jira/browse/IGNITE-2176 -- Anton K. is going > > > to fix it in next few days > > > > > > вт, 17 дек. 2019 г. в 13:30, Maxim Muzafarov : > > > > > > > > Ivan, > > > > > > > > You should cherry-pick this commit to the ignite-2.8 branch also. > > > > > > > > Can you help with the release blocker issue mentioned above? I can > not > > > > found the people who are assigned those issues. We need to clarify > > > > issues status and ask for help if necessary. > > > > > > > > On Tue, 17 Dec 2019 at 11:33, Ivan Pavlukhin > > wrote: > > > > > > > > > > Maxim, > > > > > > > > > > I merged a fix for thin JDBC default query timeout to master under > > > > > [1]. What should be the next steps with regard to 2.8 release > branch? > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12424 > > > > > > > > > > чт, 12 дек. 2019 г. в 13:08, Maxim Muzafarov : > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > Here are the 2.8 release BLOCKER issues with unknown status for > me. > > > > > > If anyone knows details can you share it? > > > > > > > > > > > > IGNITE-2176 [1] - Not valid exceptions in the case when example > > can't > > > > > > works (Java 8) > > > > > > IGNITE-8552 [2] - Unable to use a date as primary key > > > > > > IGNITE-12227 [3] - Default auto-adjust baseline enabled flag > > > > > > calculated incorrectly in some cases > > > > > > IGNITE-9489 [4] - CorruptedTreeException on index create. > > > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-2176 > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-8552 > > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-12227 > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-9489 > > > > > > > > > > > > On Thu, 12 Dec 2019 at 07:05, Saikat Maitra < > > saikat.mai...@gmail.com> wrote: > > > > > > > > > > > > > > Hi Ivan, > > > > > > > > > > > > > > Thank you so much for your help, I really appreciate it. > > > > > > > > > > > > > > I had a quick question and shared in the Jira issue > > > > > > > https://issues.apache.org/jira/browse/IGNITE-12424 > > > > > > > > > > > > > > Please review and share your feedback. > > > > > > > > > > > > > > Regards, > > > > > > > Saikat > > > > > > > > > > > > > > On Wed, Dec 11, 2019 at 3:45 AM Ivan Pavlukhin < > > vololo...@gmail.com> wrote: > > > > > > > > > > > > > > > Saikat, > > > > > > > > > > > > > > > > Please see my comment in ticket [1]. Also you can count on my > > > > > > > > assistance for the subject. Currently I have time to help > with > > it. > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12424 > > > > > > > > > > > > > > > > вт, 10 дек. 2019 г. в 06:15, Saikat Maitra < > > saikat.mai...@gmail.com>: > > > > > > > > > > > > > > > > > > Hi Ilya, Ivan > > > > > > > > > > > > > > > > > > Thank you for looping me in, I was looking into this issue > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-12424 and > > looked into > > > > > > > > > JdbcRequest and JdbcRequestHandler but I do not see the > > timeout field. > > > > > > > > > > > > > > > > > > I was hoping the fix would be something similar to adding > > these 2 lines > > > > > > > > > > > > > > > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/odbc/odbc/OdbcRequestHandler.java#L348-L349 > > > > > > > > > > > > > > > > > > Can you please confirm if the Jdbc client side timeout is > > even passed to > > > > > > > > > server? > > > > > > > > > > > > > > > > > > I am fine to exclude > > https://issues.apache.org/jira/browse/IGNITE-7285 > > > > > > > > and > > > > > > > > > make the release 2.8.0. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Saikat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 9, 2019 at 11:52 AM Вячеслав Коптилин < > > > > > > > > slava.kopti...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hello Ilya, > > > > > > > > > > > > > > > > > > > > Looks like the same
Re: Ignite meetup at Google Headquarters on Dec 18th
Hello Prashant, Unfortunately, this session won't be broadcasted and recorded. However, community members do webinars regularly and, for instance, Saikat is presenting tomorrow: https://www.gridgain.com/resources/webinars (GridGain provides a platform for webinars, soon will add a page with webinars recordings to Ignite website). Also, there are many in-memory computing groups worldwide that present Ignite talks frequently. If you are interested, in the future, you can start such a group in India and the community will help you with its growth and content: https://www.meetup.com/pro/in-memory-computing/ - Denis On Mon, Dec 16, 2019 at 8:14 PM Prashant Rahulkar < prashantrahul...@gmail.com> wrote: > Hello Denis, > We are from remote place, we would also like to attend the session. > Is there any chance for us to connect by conference. > > Thanks, > Prashant Rahulkar. > > On Tue, 17 Dec 2019 at 04:46, Denis Magda wrote: > > > Just a reminder for those who live/work nearby. > > > > We've already got 200 registrations for in-memory computing essentials > talk > > across Silicon Valley JUG and in-memory computing groups. We're running > out > > of chairs but still have a few left, join! > > > > - > > Denis > > > > > > On Mon, Dec 9, 2019 at 1:52 AM Denis Magda wrote: > > > > > Igniters, > > > > > > This month we united with Silicon Valley Java User Group and we'll be > > > repeating In-Memory Computing Essentials for Software Engineers session > > at > > > Google HQ. > > > > > > Come over to meet in person, a lot of coding and practical examples. > RSVP > > > using our local group below (and attend it to not miss future > > gatherings): > > > https://www.meetup.com/Bay-Area-In-Memory-Computing/events/267050035/ > > > > > > - > > > Denis > > > > > > > > -- > ~ Rahul >
[jira] [Created] (IGNITE-12464) Service metrics
Nikolay Izhikov created IGNITE-12464: Summary: Service metrics Key: IGNITE-12464 URL: https://issues.apache.org/jira/browse/IGNITE-12464 Project: Ignite Issue Type: Improvement Affects Versions: 2.7.6 Reporter: Nikolay Izhikov We should provide the following metrics for each deployed service: * Count of executions * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [ANNOUNCE] New committer: Aleksei Scherbakov
Hi folks. Thank you for your trust. вт, 17 дек. 2019 г. в 13:51, Вячеслав Коптилин : > Hello Aleksei, Igniters, > > Congrats, Aleksei! > This is definitely good news! :) > > Thanks, > S. > > пн, 16 дек. 2019 г. в 19:59, Pavel Kovalenko : > > > Aleksei, > > > > Congratulations! You definitely deserve it. > > > > пн, 16 дек. 2019 г. в 14:42, Ivan Pavlukhin : > > > > > Aleksei, my congratulations! > > > > > > сб, 14 дек. 2019 г. в 10:50, Zhenya Stanilovsky > > > > >: > > > > > > > > Big deal and huge responsibility. > > > > > > > > Congrats Aleksei! > > > > > > > > > Hello Ignite Community, > > > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has > invited > > > > > Aleksei Scherbakov to become a committer and we are pleased to > > announce > > > > > that he has accepted. > > > > > > > > > > Aleksei investigated and fixed a lot of critical issues. Seems, > > > > > everybody's > > > > > familiar with "partitions counters" fix > > > > > https://issues.apache.org/jira/browse/IGNITE-10078 solved huge > > > > > data loss issue. On top of that, Aleksei recently finished Data > > > > > Consistency > > > > > wiki: > > > https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > > > > It will definitely help newcomers in better understanding of > product > > > > > internals. > > > > > > > > > > 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. > > > > > > > > > > Aleksei, thank you! > > > > > > > > > > Best Regards, > > > > > Dmitriy Pavlov > > > > > on behalf of Apache Ignite PMC > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12463) Inconsistancy of checkpoint progress future with its state
Anton Kalashnikov created IGNITE-12463: -- Summary: Inconsistancy of checkpoint progress future with its state Key: IGNITE-12463 URL: https://issues.apache.org/jira/browse/IGNITE-12463 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov It needs to reorganize checkpoint futures(start, finish) so they should be matched to states. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12461) Jdbc Thin: Failover connections support for JDBC thin driver.
Andrey Mashenkov created IGNITE-12461: - Summary: Jdbc Thin: Failover connections support for JDBC thin driver. Key: IGNITE-12461 URL: https://issues.apache.org/jira/browse/IGNITE-12461 Project: Ignite Issue Type: Sub-task Components: jdbc Reporter: Andrey Mashenkov We need to to support failover connections for JDBC driver. In case user defined few connection points and server became unavailable during request, driver should try send the same request to another server. Please be aware we can do it only for idempotent requests like a SELECT without transaction context. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12462) JDBC thin: add timeouts as the parameters for connection string
Andrey Mashenkov created IGNITE-12462: - Summary: JDBC thin: add timeouts as the parameters for connection string Key: IGNITE-12462 URL: https://issues.apache.org/jira/browse/IGNITE-12462 Project: Ignite Issue Type: Task Components: thin client Reporter: Andrey Mashenkov We've added two new timeouts ([1], [2]) but they're available from java code only and both should be add as the connection string parameters. 1. https://issues.apache.org/jira/browse/IGNITE-5438 2. https://issues.apache.org/jira/browse/IGNITE-5234 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12460) Cluster fails to find the node by consistent ID
Anton Kalashnikov created IGNITE-12460: -- Summary: Cluster fails to find the node by consistent ID Key: IGNITE-12460 URL: https://issues.apache.org/jira/browse/IGNITE-12460 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Steps to reproduce 1: * Start cluster of three nodes * Navigate to Baseline screen * Start one more node * Include it into baseline * Hit 'Save' btn Expected: * Success alert, node enters baseline Actual: * Exception is thrown and is displayed Steps to reproduce 2: # Start topology with 2 nodes. # Activate cluster. # Start third node. # Stop second node. # Try to add third node to baseline in Web console. Also reproduced with *control.sh --baseline set* command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Adding support for Ignite secondary indexes to Apache Calcite planner
Colleagues, sorry for late reply. @Igor, I wouldn't say that materialized views work like rules. There is no pattern matching there (at least for trivial cases like sorted indexes, for more complex views pattern matching will have place, see VolcanoPlanner#registerMaterializations). Also it couldn't be retriggered several times. The better analogy here is an extra call of VolcanoPlanner#register for index scans and registering them in the same sets as usual scans. See an example below. @Vladimir, I'm not sure that phoenix approach will significantly reduce optimization time, but it looks like materializations might save some efforts. Lets consider an example with Merge join. With drill-like approach initially we have: LogicalJoin(emps.depId=deps.id) LogicalScan(emps) LogicalScan(deps) then we apply converters to convert this tree into the physical representation. Assume that both tables are sorted by 'id' column and there is an index on 'emps.depId' column. Also they are collocated on 'emps.depId=deps.id' columns. You apply MergeJoinRule and demand it's inputs are sorted on 'emps.depId' and 'deps.id' together. After applying this rule, converting scans to the physical nodes and expanding AbstractConverters you'll end up with MergeJoin(emps.depId=deps.id) Sort(emps.depId) PhysicalScan(emps) PhysicalScan(deps) then you apply ScanToIndexScanRule MergeJoin(emps.depId=deps.id) Sort(emps.depId) PhysicalIndexScan(emps.depId) PhysicalScan(deps) and finally after removing redundant sort by SortRemoveRule you'll get MergeJoin(emps.depId=deps.id) PhysicalIndexScan(emps.depId) PhysicalScan(deps) Now, lets take a look to the same optimization process with the phoenix-like approach. Initially we have the same query tree: LogicalJoin(emps.depId=deps.id) LogicalScan(emps) LogicalScan(deps) But then, just before planning, we register materializations (see the beginning of the VolcanoPlanner#findBestExp method). And query tree now looks like LogicalJoin(emps.depId=deps.id) Set 0: [LogicalScan(emps), LogicalIndexScan(collation=emps.depId)] LogicalScan(deps) Note that we have two scans with different collations for 'emps' table in the Set0. And this happened before the actual planning process. After converting scans to the physical nodes we'll have: LogicalJoin(emps.depId=deps.id) Set 0: [PhysicalScan(emps), PhysicalIndexScan(collation=emps.depId)] PhysicalScan(deps) and after applying MergeJoinRule and demanding that 'deps' should be sorted by 'id' column and 'emps' should be sorted by 'depId' column, we will end up with a tree without Sort operator (unlike in drill case), because we have already had a properly sorted subset for 'emps' scan. The tree will look like this: MergeJoin(emps.depId=deps.id) PhysicalIndexScan(collation=emps.depId) PhysicalScan(deps) So, we get to the same point without creating and removing redundant sort, because we have all possible index scans registered before the planning is actually started and we can demand sortedness of table scans directly without applying IndexRules and Abstract converters. -- Kind Regards Roman Kondakov On 13.12.2019 12:38, Seliverstov Igor wrote: > Colleagues, > > As far as I understand, materialization acts like a special rule, that > matches some subtree pattern (a leaf part of a query plan) to a star table, > which may have better cost than the subtree, it replaces. Saying that, in > general, there is no difference between approaches - they do the same almost > in the same way but using different API. > > My opinion is it’s better to do the deal using rules - it makes overall > approach consistent. > > Regards, > Igor > >> 12 дек. 2019 г., в 10:03, Vladimir Ozerov написал(а): >> >> Roman, >> >> What I am trying to understand is what advantage of materialization API you >> see over the normal optimization process? Does it save optimization time, >> or reduce memory footprint, or maybe provide better plans? I am asking >> because I do not see how expressing indexes as materializations fit >> classical optimization process. We discussed Sort <- Scan optimization. >> Let's consider another example: >> >> LogicalSort[a ASC] >> LogicalJoin >> >> Initially, you do not know the implementation of the join, and hence do not >> know it's collation. Then you may execute physical join rules, which >> produce, say, PhysicalMergeJoin[a ASC]. If you execute sort implementation >> rule afterwards, you may easily eliminate the sort, or make it simpler >> (e.g. remove local sorting phase), depending on the distribution. In other >> words, proper implementation of sorting optimization assumes that you have >> a kind of SortRemoveRule anyway, irrespectively of whether you use >> materializations or not, because sorting may be injected on top of any >> operator. With this in mind, the use of materializations doesn't make the >> planner simpler. Neither it improves the outcome of the whole optimization >> process. >>
[jira] [Created] (IGNITE-12459) Searching checkpoint record in WAL doesn't work with segment compaction
Anton Kalashnikov created IGNITE-12459: -- Summary: Searching checkpoint record in WAL doesn't work with segment compaction Key: IGNITE-12459 URL: https://issues.apache.org/jira/browse/IGNITE-12459 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov During iteration over WAL we have two invariants about result(Tuple): * WALPointer equal to WALRecord.position() when segment is uncompacted * WALPointer not equal to WALRecord.position() when the segment is compacted Unfortunately, the second variant is broken in FileWriteAheadLogManager#read(WALPointer ptr) -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [ANNOUNCE] New committer: Aleksei Scherbakov
Hello Aleksei, Igniters, Congrats, Aleksei! This is definitely good news! :) Thanks, S. пн, 16 дек. 2019 г. в 19:59, Pavel Kovalenko : > Aleksei, > > Congratulations! You definitely deserve it. > > пн, 16 дек. 2019 г. в 14:42, Ivan Pavlukhin : > > > Aleksei, my congratulations! > > > > сб, 14 дек. 2019 г. в 10:50, Zhenya Stanilovsky > > >: > > > > > > Big deal and huge responsibility. > > > > > > Congrats Aleksei! > > > > > > > Hello Ignite Community, > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > > Aleksei Scherbakov to become a committer and we are pleased to > announce > > > > that he has accepted. > > > > > > > > Aleksei investigated and fixed a lot of critical issues. Seems, > > > > everybody's > > > > familiar with "partitions counters" fix > > > > https://issues.apache.org/jira/browse/IGNITE-10078 solved huge > > > > data loss issue. On top of that, Aleksei recently finished Data > > > > Consistency > > > > wiki: > > https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > > > It will definitely help newcomers in better understanding of product > > > > internals. > > > > > > > > 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. > > > > > > > > Aleksei, thank you! > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
[jira] [Created] (IGNITE-12458) Rename Affinity Awareness to Partition Awareness
Pavel Tupitsyn created IGNITE-12458: --- Summary: Rename Affinity Awareness to Partition Awareness Key: IGNITE-12458 URL: https://issues.apache.org/jira/browse/IGNITE-12458 Project: Ignite Issue Type: Task Components: platforms Affects Versions: 2.8 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.8 Rename Affinity Awareness to Partition Awareness in all product components -- This message was sent by Atlassian Jira (v8.3.4#803005)
