[jira] [Created] (IGNITE-14206) 2.8.1 inlines POJO but ignores it since 2.9.0
Maksim Timonin created IGNITE-14206: --- Summary: 2.8.1 inlines POJO but ignores it since 2.9.0 Key: IGNITE-14206 URL: https://issues.apache.org/jira/browse/IGNITE-14206 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin Reproducer https://github.com/apache/ignite/pull/8811/files -- This message was sent by Atlassian Jira (v8.3.4#803005)
JIRA Permissions
Hi, Please grant me JIRA permissions. My user id is atri -- Regards, Atri Apache Concerted
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Hello! There was a ticket filed about the new feature, transactions in C++ thin client, making this feature unusable if there's more than one connection endpoint: https://issues.apache.org/jira/browse/IGNITE-14204 I don't think this is a genuine blocker for 2.10, since there is a workaround (use just one endpoint), nevertheless it is a critical crasher bug, so I wonder if Igor could take a look at it promptly, include the fix in 2.10. Regards, -- Ilya Kasnacheev чт, 18 февр. 2021 г. в 09:03, Zhenya Stanilovsky : > > > I fill the ticket with drop problem, plz take a look [1] > > [1] https://issues.apache.org/jira/browse/IGNITE-14205 > > >Ilya, > > > >Thanks! > >I've added this step to the Release Process wiki page also [1]. > > > >[1] > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P1.2ImplementationandScopeFinalization > > > >On Wed, 17 Feb 2021 at 18:05, Ilya Kasnacheev < ilya.kasnach...@gmail.com > > wrote: > >> > >> Hello! > >> > >> I have added ignite-2.10 to Nightly build triggering. I hope we will > have a > >> 2.10 nightly tomorrow. Shame that I didn't do it earlier. > >> > https://ci.ignite.apache.org/buildConfiguration/Releases_NightlyRelease_RunApacheIgniteNightlyRelease?branch=ignite-2.10&buildTypeTab=overview&mode=builds > >> > >> Regards, > >> -- > >> Ilya Kasnacheev > >> > >> > >> ср, 17 февр. 2021 г. в 17:37, Maxim Muzafarov < mmu...@apache.org >: > >> > >> > Folks, > >> > > >> > There is a possible issue with the performance for 2.9.1 vs 2.10. I'm > >> > trying to reproduce on a stress-testing environment. > >> > [1] > >> > > https://cwiki.apache.org/confluence/download/attachments/165224767/atomicPutRandomValueFullSync.jpg?api=v2 > >> > > >> > On Fri, 12 Feb 2021 at 20:46, Maxim Muzafarov < mmu...@apache.org > > wrote: > >> > > > >> > > Folks, > >> > > > >> > > I'm going to cherry-pick these issues to the release branch, any > >> > objections? > >> > > > >> > > > >> > > Checkpointer thread holds write lock too long > >> > > https://issues.apache.org/jira/browse/IGNITE-14140 > >> > > > >> > > Incorrect initialize checkpoint-runner-cpu thread pool > >> > > https://issues.apache.org/jira/browse/IGNITE-14139 > >> > > > >> > > On Wed, 10 Feb 2021 at 21:59, Maxim Muzafarov < mmu...@apache.org > > wrote: > >> > > > > >> > > > Folks, > >> > > > > >> > > > Do we need any other critical issues from the master branch that > need > >> > > > to be cherry-picked picked from the master branch? I've marked the > >> > > > latest select issues with patching version 2.10. > >> > > > > >> > > > - benchmarks completed (I'll do another one prior to preparing rc) > >> > > > - the release notes merged > >> > > > - cherry-picked issue (IGNITE-14073 Fixed transactions failover) > >> > > > - most of the documentation pages also merged > >> > > > > >> > > > Hopefully, by Friday the 12th everything will be ready for the > >> > > > preparation of a release candidate. > >> > > > > >> > > > On Tue, 9 Feb 2021 at 05:09, Никита Сафонов < > vlasovpavel2...@gmail.com > > >> > wrote: > >> > > > > > >> > > > > Hi everyone, > >> > > > > > >> > > > > Below are two lists of items representing all the remaining (and > >> > completed) > >> > > > > documentation tasks for the Ignite 2.10 release. > >> > > > > > >> > > > > The "*Improvements*" part includes PRs on reworked > documentation. > >> > > > > The "*Finished*" part includes PRs on newly added documentation. > >> > > > > > >> > > > > *Improvements:* > >> > > > > > >> > > > > Documentation for .NET thin client service invocation > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14129 > >> > > > > [2] https://github.com/apache/ignite/pull/8756 > >> > > > > > >> > > > > Documentation for cache warm-up strategy > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13385 > >> > > > > [2] https://github.com/apache/ignite/pull/8703 > >> > > > > > >> > > > > *Finished:* > >> > > > > > >> > > > > Document control.(sh|bin) command to get an arbitrary SystemView > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14142 > >> > > > > [2] https://github.com/apache/ignite/pull/8775 > >> > > > > > >> > > > > Document metric for processed keys when rebuilding indexes > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14143 > >> > > > > [2] https://github.com/apache/ignite/pull/8776 > >> > > > > > >> > > > > Document C++ thin client transactions > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14144 > >> > > > > [2] https://github.com/apache/ignite/pull/8777 > >> > > > > > >> > > > > Please don't hesitate to ask me if you have any questions or > >> > concerns. > >> > > > > > >> > > > > With best regards, > >> > > > > Nikita > >> > > > > > >> > > > > сб, 6 февр. 2021 г. в 02:14, Никита Сафонов < > >> > vlasovpavel2...@gmail.com >: > >> > > > > > >> > > > > > Maxim, > >> > > > > > > >> > > > > > Thank you for being ready to help! > >> > > > > > > >> > > > > > As I mentioned before, I'm
Re: JIRA Permissions
Hello! I have already granted permissions to this account, now you should be able to assign issues to yourself. Mind the https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute Regards, -- Ilya Kasnacheev чт, 18 февр. 2021 г. в 13:12, Atri Sharma : > Hi, > > Please grant me JIRA permissions. My user id is atri > > -- > Regards, > > Atri > Apache Concerted >
Re: Adding metrics of using WAL archive
Hi, Nikolay! Have we reached a consensus? 16.02.2021, 17:09, "ткаленко кирилл" : > Hi, Zhenya! > > Users can also use it, I see nothing wrong with the presence of two metrics. > > 16.02.2021, 16:50, "Zhenya Stanilovsky" : >> Kirill, is it good practice to have a metrics for internal use? Don`t think >> so. >> +1 witk Nikolay size is more readable than abstract segments count. >> >>> Hi, Nikolay! >>> >>> For internal use, leave the metric that I propose and also add the metric: >>> Count of bytes logged in WAL. Why not "written" because for the mmap we >>> cannot track when the physical writting will occur. >>> >>> 16.02.2021, 15:42, "Nikolay Izhikov" < nizhi...@apache.org >: Kirill. «Count of segments» is a very internal thing for a regular user. Regular user don’t want to know about such things. You suggest to calculate the number (space required to store WAL) with some kind of rough calculation, and with the «Count of bytes written in WAL» we can have exact number without any suggestions or calculations. Moreover, «Count of bytes written in WAL» is independent on internal WAL implementation. So, I think exact number is always better to have then some approximation. What do you think? > 15 февр. 2021 г., в 20:45, ткаленко кирилл < tkalkir...@yandex.ru > > написал(а): > > Hi, Nikolay! > > We set the number of segments in the working directory, we also delete > by segment, it seems that this is a matter of usability. I prefer to > dwell on my own version, this is a simple metric that does not hurt and > you can add more as needed. > > 15.02.2021, 17:10, "Nikolay Izhikov" < nizhi...@apache.org >: >> My suggestion that «count of files» is meaningless number. >> And «count of bytes written to the files» is useful number to know >> and use for capacity planning.. >> >>> 15 февр. 2021 г., в 15:59, ткаленко кирилл < tkalkir...@yandex.ru > >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> There may be a number (count of segments * segment size) or there >>> may be a count of segments, whichever is more convenient for the user. >>> >>> 15.02.2021, 13:14, "Nikolay Izhikov" < nizhi...@apache.org >: Hello, Kirill. Thanks for an answers. Now, I understand your intentions. > t also seems that it will be more natural to operate not just > bytes but multiples of a segment. Can’t agree here. From my point of view - it’s better to know exact number, not just «count of segments». > 15 февр. 2021 г., в 13:00, ткаленко кирилл < > tkalkir...@yandex.ru > написал(а): > > Hello, Nikolay! > > The period of one day (24h) seems more natural, you can take > more or less, I think that one day may not be enough, and it is worth > getting the metric for several days (collect statistics) for example > a week. Yes, the total size of the segments may not be > DataStorageConfiguration#getMaxWalArchiveSize, but for capacity > planning, accuracy is not so important to us, since the load can > always change, it will hurt users more if we overflow the archive and > it will not be able to start the node. So to say that more is better > than less, it also seems that it will be more natural to operate not > just bytes but multiples of a segment. > > In separate threads, you can discuss the metric that you propose > about page memory and indexes estimates. > > 14.02.2021, 11:54, "Nikolay Izhikov" < nizhi...@apache.org >: >> Hello, Kirill >> >> Your conclusions still not clear for me. >> >>> It is not possible for us to estimate how much space a user >>> will need in the archive so as not to overflow it under its load >>> We take the maximum 44 and multiply it by a >>> DataStorageConfiguration#getWalSegmentSize >> >> Why you take a single day (24h) for a standard period? Is there >> any rationale behind this? >> >> 1. We have `walAutoArchiveAfterInactivity` property. So WAL >> segment can have a size less than the maximum. >> 2. For CDC feature I want to introduce «WAL force rollover >> timeout» to make data available for a consumer in a guaranteed >> period [1]. >> >> Why does the user want to estimate those numbers in the first >> place? >> Are we talking about some kind of capacity planning? >> >> If yes, then maybe it will be better to have a
Re: Adding metrics of using WAL archive
Hello, Kirill. Can you, please, write down your proposal? What metrics you want to add in the Ignite? > 18 февр. 2021 г., в 14:11, ткаленко кирилл написал(а): > > Hi, Nikolay! > > Have we reached a consensus? > > 16.02.2021, 17:09, "ткаленко кирилл" : >> Hi, Zhenya! >> >> Users can also use it, I see nothing wrong with the presence of two metrics. >> >> 16.02.2021, 16:50, "Zhenya Stanilovsky" : >>> Kirill, is it good practice to have a metrics for internal use? Don`t >>> think so. >>> +1 witk Nikolay size is more readable than abstract segments count. >>> Hi, Nikolay! For internal use, leave the metric that I propose and also add the metric: Count of bytes logged in WAL. Why not "written" because for the mmap we cannot track when the physical writting will occur. 16.02.2021, 15:42, "Nikolay Izhikov" < nizhi...@apache.org >: > Kirill. > > «Count of segments» is a very internal thing for a regular user. > Regular user don’t want to know about such things. > > You suggest to calculate the number (space required to store WAL) with > some kind of rough calculation, and with the «Count of bytes written in > WAL» we can have exact number without any suggestions or calculations. > > Moreover, «Count of bytes written in WAL» is independent on internal > WAL implementation. > > So, I think exact number is always better to have then some > approximation. > > What do you think? > >>15 февр. 2021 г., в 20:45, ткаленко кирилл < tkalkir...@yandex.ru > >> написал(а): >> >>Hi, Nikolay! >> >>We set the number of segments in the working directory, we also >> delete by segment, it seems that this is a matter of usability. I prefer >> to dwell on my own version, this is a simple metric that does not hurt >> and you can add more as needed. >> >>15.02.2021, 17:10, "Nikolay Izhikov" < nizhi...@apache.org >: >>>My suggestion that «count of files» is meaningless number. >>>And «count of bytes written to the files» is useful number to know >>> and use for capacity planning.. >>> 15 февр. 2021 г., в 15:59, ткаленко кирилл < tkalkir...@yandex.ru > написал(а): Hi, Nikolay! There may be a number (count of segments * segment size) or there may be a count of segments, whichever is more convenient for the user. 15.02.2021, 13:14, "Nikolay Izhikov" < nizhi...@apache.org >: > Hello, Kirill. > > Thanks for an answers. > Now, I understand your intentions. > >> t also seems that it will be more natural to operate not just >> bytes but multiples of a segment. > > Can’t agree here. > From my point of view - it’s better to know exact number, not > just «count of segments». > >> 15 февр. 2021 г., в 13:00, ткаленко кирилл < >> tkalkir...@yandex.ru > написал(а): >> >> Hello, Nikolay! >> >> The period of one day (24h) seems more natural, you can take >> more or less, I think that one day may not be enough, and it is >> worth getting the metric for several days (collect statistics) for >> example a week. Yes, the total size of the segments may not be >> DataStorageConfiguration#getMaxWalArchiveSize, but for capacity >> planning, accuracy is not so important to us, since the load can >> always change, it will hurt users more if we overflow the archive >> and it will not be able to start the node. So to say that more is >> better than less, it also seems that it will be more natural to >> operate not just bytes but multiples of a segment. >> >> In separate threads, you can discuss the metric that you >> propose about page memory and indexes estimates. >> >> 14.02.2021, 11:54, "Nikolay Izhikov" < nizhi...@apache.org >: >>> Hello, Kirill >>> >>> Your conclusions still not clear for me. >>> It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load We take the maximum 44 and multiply it by a DataStorageConfiguration#getWalSegmentSize >>> >>> Why you take a single day (24h) for a standard period? Is >>> there any rationale behind this? >>> >>> 1. We have `walAutoArchiveAfterInactivity` property. So WAL >>> segment can have a size less than the maximum. >>> 2. For CDC feature I want to introduce «WAL force rollover >>> timeout» to make data availa
Re: Adding metrics of using WAL archive
Hello, Nikolay! org.apache.ignite.mxbean.DataStorageMetricsMXBean#getLastArchivedSegmentIndex - Get the index of the last archived segment. org.apache.ignite.mxbean.DataStorageMetricsMXBean#getMaxSizeCompressedArchivedSegment - Getting the size of the maximum compressed segment in the archive. org.apache.ignite.mxbean.DataStorageMetricsMXBean#getWalLoggingSize - Getting the total size in bytes of logged records to the WAL. 18.02.2021, 15:34, "Nikolay Izhikov" : > Hello, Kirill. > > Can you, please, write down your proposal? > What metrics you want to add in the Ignite? > >> 18 февр. 2021 г., в 14:11, ткаленко кирилл >> написал(а): >> >> Hi, Nikolay! >> >> Have we reached a consensus? >> >> 16.02.2021, 17:09, "ткаленко кирилл" : >>> Hi, Zhenya! >>> >>> Users can also use it, I see nothing wrong with the presence of two >>> metrics. >>> >>> 16.02.2021, 16:50, "Zhenya Stanilovsky" : Kirill, is it good practice to have a metrics for internal use? Don`t think so. +1 witk Nikolay size is more readable than abstract segments count. > Hi, Nikolay! > > For internal use, leave the metric that I propose and also add the > metric: Count of bytes logged in WAL. Why not "written" because for the > mmap we cannot track when the physical writting will occur. > > 16.02.2021, 15:42, "Nikolay Izhikov" < nizhi...@apache.org >: >> Kirill. >> >> «Count of segments» is a very internal thing for a regular user. >> Regular user don’t want to know about such things. >> >> You suggest to calculate the number (space required to store WAL) >> with some kind of rough calculation, and with the «Count of bytes >> written in WAL» we can have exact number without any suggestions or >> calculations. >> >> Moreover, «Count of bytes written in WAL» is independent on internal >> WAL implementation. >> >> So, I think exact number is always better to have then some >> approximation. >> >> What do you think? >> >>> 15 февр. 2021 г., в 20:45, ткаленко кирилл < tkalkir...@yandex.ru > >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> We set the number of segments in the working directory, we also >>> delete by segment, it seems that this is a matter of usability. I >>> prefer to dwell on my own version, this is a simple metric that does >>> not hurt and you can add more as needed. >>> >>> 15.02.2021, 17:10, "Nikolay Izhikov" < nizhi...@apache.org >: My suggestion that «count of files» is meaningless number. And «count of bytes written to the files» is useful number to know and use for capacity planning.. > 15 февр. 2021 г., в 15:59, ткаленко кирилл < > tkalkir...@yandex.ru > написал(а): > > Hi, Nikolay! > > There may be a number (count of segments * segment size) or > there may be a count of segments, whichever is more convenient for > the user. > > 15.02.2021, 13:14, "Nikolay Izhikov" < nizhi...@apache.org >: >> Hello, Kirill. >> >> Thanks for an answers. >> Now, I understand your intentions. >> >>> t also seems that it will be more natural to operate not just >>> bytes but multiples of a segment. >> >> Can’t agree here. >> From my point of view - it’s better to know exact number, not >> just «count of segments». >> >>> 15 февр. 2021 г., в 13:00, ткаленко кирилл < >>> tkalkir...@yandex.ru > написал(а): >>> >>> Hello, Nikolay! >>> >>> The period of one day (24h) seems more natural, you can take >>> more or less, I think that one day may not be enough, and it is >>> worth getting the metric for several days (collect statistics) for >>> example a week. Yes, the total size of the segments may not be >>> DataStorageConfiguration#getMaxWalArchiveSize, but for capacity >>> planning, accuracy is not so important to us, since the load can >>> always change, it will hurt users more if we overflow the archive >>> and it will not be able to start the node. So to say that more is >>> better than less, it also seems that it will be more natural to >>> operate not just bytes but multiples of a segment. >>> >>> In separate threads, you can discuss the metric that you >>> propose about page memory and indexes estimates. >>> >>> 14.02.2021, 11:54, "Nikolay Izhikov" < nizhi...@apache.org >: Hello, Kirill Your conclusions still not clear for me. > It is not possible for us to estimate h
[jira] [Created] (IGNITE-14207) Access to system views is not controlled by security processor
Andrey Kuznetsov created IGNITE-14207:
-
Summary: Access to system views is not controlled by security
processor
Key: IGNITE-14207
URL: https://issues.apache.org/jira/browse/IGNITE-14207
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Andrey Kuznetsov
As of now, it is impossible to restrict access to system views (SYS scheme)
with {{IgniteSecurityProcessor}}; this should be fixed.
Suggestions:
- add new {{SecurityPermission}};
- authorize this permission before accessing any system view.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Folks, Do we have any estimations of how long does it take to fix the issue [1] in C++ thin client? The bug must be fixed for sure, however, I tend to continue with the release (if fixing the bug require a few weeks) and prepare a batch of fixes for the 2.10.1. [1] https://issues.apache.org/jira/browse/IGNITE-14204 On Thu, 18 Feb 2021 at 13:22, Ilya Kasnacheev wrote: > > Hello! > > There was a ticket filed about the new feature, transactions in C++ thin > client, making this feature unusable if there's more than one connection > endpoint: > https://issues.apache.org/jira/browse/IGNITE-14204 > > I don't think this is a genuine blocker for 2.10, since there is a > workaround (use just one endpoint), nevertheless it is a critical crasher > bug, so I wonder if Igor could take a look at it promptly, include the fix > in 2.10. > > Regards, > -- > Ilya Kasnacheev > > > чт, 18 февр. 2021 г. в 09:03, Zhenya Stanilovsky >: > > > > > > > I fill the ticket with drop problem, plz take a look [1] > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14205 > > > > >Ilya, > > > > > >Thanks! > > >I've added this step to the Release Process wiki page also [1]. > > > > > >[1] > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P1.2ImplementationandScopeFinalization > > > > > >On Wed, 17 Feb 2021 at 18:05, Ilya Kasnacheev < ilya.kasnach...@gmail.com > > > wrote: > > >> > > >> Hello! > > >> > > >> I have added ignite-2.10 to Nightly build triggering. I hope we will > > have a > > >> 2.10 nightly tomorrow. Shame that I didn't do it earlier. > > >> > > https://ci.ignite.apache.org/buildConfiguration/Releases_NightlyRelease_RunApacheIgniteNightlyRelease?branch=ignite-2.10&buildTypeTab=overview&mode=builds > > >> > > >> Regards, > > >> -- > > >> Ilya Kasnacheev > > >> > > >> > > >> ср, 17 февр. 2021 г. в 17:37, Maxim Muzafarov < mmu...@apache.org >: > > >> > > >> > Folks, > > >> > > > >> > There is a possible issue with the performance for 2.9.1 vs 2.10. I'm > > >> > trying to reproduce on a stress-testing environment. > > >> > [1] > > >> > > > https://cwiki.apache.org/confluence/download/attachments/165224767/atomicPutRandomValueFullSync.jpg?api=v2 > > >> > > > >> > On Fri, 12 Feb 2021 at 20:46, Maxim Muzafarov < mmu...@apache.org > > > wrote: > > >> > > > > >> > > Folks, > > >> > > > > >> > > I'm going to cherry-pick these issues to the release branch, any > > >> > objections? > > >> > > > > >> > > > > >> > > Checkpointer thread holds write lock too long > > >> > > https://issues.apache.org/jira/browse/IGNITE-14140 > > >> > > > > >> > > Incorrect initialize checkpoint-runner-cpu thread pool > > >> > > https://issues.apache.org/jira/browse/IGNITE-14139 > > >> > > > > >> > > On Wed, 10 Feb 2021 at 21:59, Maxim Muzafarov < mmu...@apache.org > > > wrote: > > >> > > > > > >> > > > Folks, > > >> > > > > > >> > > > Do we need any other critical issues from the master branch that > > need > > >> > > > to be cherry-picked picked from the master branch? I've marked the > > >> > > > latest select issues with patching version 2.10. > > >> > > > > > >> > > > - benchmarks completed (I'll do another one prior to preparing rc) > > >> > > > - the release notes merged > > >> > > > - cherry-picked issue (IGNITE-14073 Fixed transactions failover) > > >> > > > - most of the documentation pages also merged > > >> > > > > > >> > > > Hopefully, by Friday the 12th everything will be ready for the > > >> > > > preparation of a release candidate. > > >> > > > > > >> > > > On Tue, 9 Feb 2021 at 05:09, Никита Сафонов < > > vlasovpavel2...@gmail.com > > > >> > wrote: > > >> > > > > > > >> > > > > Hi everyone, > > >> > > > > > > >> > > > > Below are two lists of items representing all the remaining (and > > >> > completed) > > >> > > > > documentation tasks for the Ignite 2.10 release. > > >> > > > > > > >> > > > > The "*Improvements*" part includes PRs on reworked > > documentation. > > >> > > > > The "*Finished*" part includes PRs on newly added documentation. > > >> > > > > > > >> > > > > *Improvements:* > > >> > > > > > > >> > > > > Documentation for .NET thin client service invocation > > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14129 > > >> > > > > [2] https://github.com/apache/ignite/pull/8756 > > >> > > > > > > >> > > > > Documentation for cache warm-up strategy > > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13385 > > >> > > > > [2] https://github.com/apache/ignite/pull/8703 > > >> > > > > > > >> > > > > *Finished:* > > >> > > > > > > >> > > > > Document control.(sh|bin) command to get an arbitrary SystemView > > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14142 > > >> > > > > [2] https://github.com/apache/ignite/pull/8775 > > >> > > > > > > >> > > > > Document metric for processed keys when rebuilding indexes > > >> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14143 > > >> > > > > [2] https://github.com/apache/ignite/pull/8776 > > >>
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Hi! I've today found an issue [1], there is wrong handling of inlined POJO. This bug appeared in 2.9.0 and makes it impossible to work with multi-column indexes created on old AI versions that contain inlined POJO keys in the middle. I'm working on the fix and asked Konstantin Orlov to review it. I think that it will take only a couple of days to fix this issue. From my side, it looks like a release blocker, but we've been living with that since 2.9.0. WDYT if the release can wait for the fix? [1] https://issues.apache.org/jira/browse/IGNITE-14206 On Thu, Feb 18, 2021 at 5:38 PM Maxim Muzafarov wrote: > Folks, > > > Do we have any estimations of how long does it take to fix the issue > [1] in C++ thin client? The bug must be fixed for sure, however, I > tend to continue with the release (if fixing the bug require a few > weeks) and prepare a batch of fixes for the 2.10.1. > > > [1] https://issues.apache.org/jira/browse/IGNITE-14204 > > On Thu, 18 Feb 2021 at 13:22, Ilya Kasnacheev > wrote: > > > > Hello! > > > > There was a ticket filed about the new feature, transactions in C++ thin > > client, making this feature unusable if there's more than one connection > > endpoint: > > https://issues.apache.org/jira/browse/IGNITE-14204 > > > > I don't think this is a genuine blocker for 2.10, since there is a > > workaround (use just one endpoint), nevertheless it is a critical crasher > > bug, so I wonder if Igor could take a look at it promptly, include the > fix > > in 2.10. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 18 февр. 2021 г. в 09:03, Zhenya Stanilovsky > > >: > > > > > > > > > > > I fill the ticket with drop problem, plz take a look [1] > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14205 > > > > > > >Ilya, > > > > > > > >Thanks! > > > >I've added this step to the Release Process wiki page also [1]. > > > > > > > >[1] > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P1.2ImplementationandScopeFinalization > > > > > > > >On Wed, 17 Feb 2021 at 18:05, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > > > wrote: > > > >> > > > >> Hello! > > > >> > > > >> I have added ignite-2.10 to Nightly build triggering. I hope we will > > > have a > > > >> 2.10 nightly tomorrow. Shame that I didn't do it earlier. > > > >> > > > > https://ci.ignite.apache.org/buildConfiguration/Releases_NightlyRelease_RunApacheIgniteNightlyRelease?branch=ignite-2.10&buildTypeTab=overview&mode=builds > > > >> > > > >> Regards, > > > >> -- > > > >> Ilya Kasnacheev > > > >> > > > >> > > > >> ср, 17 февр. 2021 г. в 17:37, Maxim Muzafarov < mmu...@apache.org > >: > > > >> > > > >> > Folks, > > > >> > > > > >> > There is a possible issue with the performance for 2.9.1 vs 2.10. > I'm > > > >> > trying to reproduce on a stress-testing environment. > > > >> > [1] > > > >> > > > > > https://cwiki.apache.org/confluence/download/attachments/165224767/atomicPutRandomValueFullSync.jpg?api=v2 > > > >> > > > > >> > On Fri, 12 Feb 2021 at 20:46, Maxim Muzafarov < mmu...@apache.org > > > > > wrote: > > > >> > > > > > >> > > Folks, > > > >> > > > > > >> > > I'm going to cherry-pick these issues to the release branch, any > > > >> > objections? > > > >> > > > > > >> > > > > > >> > > Checkpointer thread holds write lock too long > > > >> > > https://issues.apache.org/jira/browse/IGNITE-14140 > > > >> > > > > > >> > > Incorrect initialize checkpoint-runner-cpu thread pool > > > >> > > https://issues.apache.org/jira/browse/IGNITE-14139 > > > >> > > > > > >> > > On Wed, 10 Feb 2021 at 21:59, Maxim Muzafarov < > mmu...@apache.org > > > > wrote: > > > >> > > > > > > >> > > > Folks, > > > >> > > > > > > >> > > > Do we need any other critical issues from the master branch > that > > > need > > > >> > > > to be cherry-picked picked from the master branch? I've > marked the > > > >> > > > latest select issues with patching version 2.10. > > > >> > > > > > > >> > > > - benchmarks completed (I'll do another one prior to > preparing rc) > > > >> > > > - the release notes merged > > > >> > > > - cherry-picked issue (IGNITE-14073 Fixed transactions > failover) > > > >> > > > - most of the documentation pages also merged > > > >> > > > > > > >> > > > Hopefully, by Friday the 12th everything will be ready for the > > > >> > > > preparation of a release candidate. > > > >> > > > > > > >> > > > On Tue, 9 Feb 2021 at 05:09, Никита Сафонов < > > > vlasovpavel2...@gmail.com > > > > >> > wrote: > > > >> > > > > > > > >> > > > > Hi everyone, > > > >> > > > > > > > >> > > > > Below are two lists of items representing all the remaining > (and > > > >> > completed) > > > >> > > > > documentation tasks for the Ignite 2.10 release. > > > >> > > > > > > > >> > > > > The "*Improvements*" part includes PRs on reworked > > > documentation. > > > >> > > > > The "*Finished*" part includes PRs on newly added > documentation. > > > >> > > > > > > > >> > > > > *Improvements:* > > > >> > > > > > > > >> > > > > Docu
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Maxim, I believe I could fix the ticket [1] by the end of the next week. [1] https://issues.apache.org/jira/browse/IGNITE-14204 Best Regards, Igor On Thu, Feb 18, 2021 at 6:30 PM Max Timonin wrote: > Hi! I've today found an issue [1], there is wrong handling of inlined POJO. > This bug appeared in 2.9.0 and makes it impossible to work with > multi-column indexes created on old AI versions that contain inlined POJO > keys in the middle. > > I'm working on the fix and asked Konstantin Orlov to review it. I think > that it will take only a couple of days to fix this issue. From my side, it > looks like a release blocker, but we've been living with that since 2.9.0. > WDYT if the release can wait for the fix? > > [1] https://issues.apache.org/jira/browse/IGNITE-14206 > > On Thu, Feb 18, 2021 at 5:38 PM Maxim Muzafarov wrote: > > > Folks, > > > > > > Do we have any estimations of how long does it take to fix the issue > > [1] in C++ thin client? The bug must be fixed for sure, however, I > > tend to continue with the release (if fixing the bug require a few > > weeks) and prepare a batch of fixes for the 2.10.1. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14204 > > > > On Thu, 18 Feb 2021 at 13:22, Ilya Kasnacheev > > > wrote: > > > > > > Hello! > > > > > > There was a ticket filed about the new feature, transactions in C++ > thin > > > client, making this feature unusable if there's more than one > connection > > > endpoint: > > > https://issues.apache.org/jira/browse/IGNITE-14204 > > > > > > I don't think this is a genuine blocker for 2.10, since there is a > > > workaround (use just one endpoint), nevertheless it is a critical > crasher > > > bug, so I wonder if Igor could take a look at it promptly, include the > > fix > > > in 2.10. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 18 февр. 2021 г. в 09:03, Zhenya Stanilovsky > > > > >: > > > > > > > > > > > > > > > I fill the ticket with drop problem, plz take a look [1] > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14205 > > > > > > > > >Ilya, > > > > > > > > > >Thanks! > > > > >I've added this step to the Release Process wiki page also [1]. > > > > > > > > > >[1] > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P1.2ImplementationandScopeFinalization > > > > > > > > > >On Wed, 17 Feb 2021 at 18:05, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > > > wrote: > > > > >> > > > > >> Hello! > > > > >> > > > > >> I have added ignite-2.10 to Nightly build triggering. I hope we > will > > > > have a > > > > >> 2.10 nightly tomorrow. Shame that I didn't do it earlier. > > > > >> > > > > > > > https://ci.ignite.apache.org/buildConfiguration/Releases_NightlyRelease_RunApacheIgniteNightlyRelease?branch=ignite-2.10&buildTypeTab=overview&mode=builds > > > > >> > > > > >> Regards, > > > > >> -- > > > > >> Ilya Kasnacheev > > > > >> > > > > >> > > > > >> ср, 17 февр. 2021 г. в 17:37, Maxim Muzafarov < mmu...@apache.org > > >: > > > > >> > > > > >> > Folks, > > > > >> > > > > > >> > There is a possible issue with the performance for 2.9.1 vs > 2.10. > > I'm > > > > >> > trying to reproduce on a stress-testing environment. > > > > >> > [1] > > > > >> > > > > > > > > https://cwiki.apache.org/confluence/download/attachments/165224767/atomicPutRandomValueFullSync.jpg?api=v2 > > > > >> > > > > > >> > On Fri, 12 Feb 2021 at 20:46, Maxim Muzafarov < > mmu...@apache.org > > > > > > > wrote: > > > > >> > > > > > > >> > > Folks, > > > > >> > > > > > > >> > > I'm going to cherry-pick these issues to the release branch, > any > > > > >> > objections? > > > > >> > > > > > > >> > > > > > > >> > > Checkpointer thread holds write lock too long > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-14140 > > > > >> > > > > > > >> > > Incorrect initialize checkpoint-runner-cpu thread pool > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-14139 > > > > >> > > > > > > >> > > On Wed, 10 Feb 2021 at 21:59, Maxim Muzafarov < > > mmu...@apache.org > > > > > wrote: > > > > >> > > > > > > > >> > > > Folks, > > > > >> > > > > > > > >> > > > Do we need any other critical issues from the master branch > > that > > > > need > > > > >> > > > to be cherry-picked picked from the master branch? I've > > marked the > > > > >> > > > latest select issues with patching version 2.10. > > > > >> > > > > > > > >> > > > - benchmarks completed (I'll do another one prior to > > preparing rc) > > > > >> > > > - the release notes merged > > > > >> > > > - cherry-picked issue (IGNITE-14073 Fixed transactions > > failover) > > > > >> > > > - most of the documentation pages also merged > > > > >> > > > > > > > >> > > > Hopefully, by Friday the 12th everything will be ready for > the > > > > >> > > > preparation of a release candidate. > > > > >> > > > > > > > >> > > > On Tue, 9 Feb 2021 at 05:09, Никита Сафонов < > > > > vlasovpavel2...@gmail.com > > > > > >> > wrote: > > > > >> >
[jira] [Created] (IGNITE-14208) .NET: Examples multi targeting
Pavel Tupitsyn created IGNITE-14208:
---
Summary: .NET: Examples multi targeting
Key: IGNITE-14208
URL: https://issues.apache.org/jira/browse/IGNITE-14208
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.11
Currently examples require .NET SDK 2.1, which is quite old. Users are more
likely to have .NET Core 3.1 or .NET 5 installed.
Fix example projects and replace
{code}
netcoreapp2.1
{code}
with
{code}
netcoreapp2.1;netcoreapp3.1;net5
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14209) Need to implement data rebalancing which is required by atomic/transactional caches
Vyacheslav Koptilin created IGNITE-14209: Summary: Need to implement data rebalancing which is required by atomic/transactional caches Key: IGNITE-14209 URL: https://issues.apache.org/jira/browse/IGNITE-14209 Project: Ignite Issue Type: New Feature Reporter: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Maxim, Igor, Thanks for sharing details. Let's wait for these fixes. [1] https://issues.apache.org/jira/browse/IGNITE-14206 [2] https://issues.apache.org/jira/browse/IGNITE-14204 On Thu, 18 Feb 2021 at 18:35, Igor Sapego wrote: > > Maxim, > > I believe I could fix the ticket [1] by the end of the next week. > > [1] https://issues.apache.org/jira/browse/IGNITE-14204 > > Best Regards, > Igor > > > On Thu, Feb 18, 2021 at 6:30 PM Max Timonin wrote: > > > Hi! I've today found an issue [1], there is wrong handling of inlined POJO. > > This bug appeared in 2.9.0 and makes it impossible to work with > > multi-column indexes created on old AI versions that contain inlined POJO > > keys in the middle. > > > > I'm working on the fix and asked Konstantin Orlov to review it. I think > > that it will take only a couple of days to fix this issue. From my side, it > > looks like a release blocker, but we've been living with that since 2.9.0. > > WDYT if the release can wait for the fix? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14206 > > > > On Thu, Feb 18, 2021 at 5:38 PM Maxim Muzafarov wrote: > > > > > Folks, > > > > > > > > > Do we have any estimations of how long does it take to fix the issue > > > [1] in C++ thin client? The bug must be fixed for sure, however, I > > > tend to continue with the release (if fixing the bug require a few > > > weeks) and prepare a batch of fixes for the 2.10.1. > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14204 > > > > > > On Thu, 18 Feb 2021 at 13:22, Ilya Kasnacheev > > > > > wrote: > > > > > > > > Hello! > > > > > > > > There was a ticket filed about the new feature, transactions in C++ > > thin > > > > client, making this feature unusable if there's more than one > > connection > > > > endpoint: > > > > https://issues.apache.org/jira/browse/IGNITE-14204 > > > > > > > > I don't think this is a genuine blocker for 2.10, since there is a > > > > workaround (use just one endpoint), nevertheless it is a critical > > crasher > > > > bug, so I wonder if Igor could take a look at it promptly, include the > > > fix > > > > in 2.10. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > чт, 18 февр. 2021 г. в 09:03, Zhenya Stanilovsky > > > > > > >: > > > > > > > > > > > > > > > > > > > I fill the ticket with drop problem, plz take a look [1] > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14205 > > > > > > > > > > >Ilya, > > > > > > > > > > > >Thanks! > > > > > >I've added this step to the Release Process wiki page also [1]. > > > > > > > > > > > >[1] > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P1.2ImplementationandScopeFinalization > > > > > > > > > > > >On Wed, 17 Feb 2021 at 18:05, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > > > wrote: > > > > > >> > > > > > >> Hello! > > > > > >> > > > > > >> I have added ignite-2.10 to Nightly build triggering. I hope we > > will > > > > > have a > > > > > >> 2.10 nightly tomorrow. Shame that I didn't do it earlier. > > > > > >> > > > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/Releases_NightlyRelease_RunApacheIgniteNightlyRelease?branch=ignite-2.10&buildTypeTab=overview&mode=builds > > > > > >> > > > > > >> Regards, > > > > > >> -- > > > > > >> Ilya Kasnacheev > > > > > >> > > > > > >> > > > > > >> ср, 17 февр. 2021 г. в 17:37, Maxim Muzafarov < mmu...@apache.org > > > >: > > > > > >> > > > > > >> > Folks, > > > > > >> > > > > > > >> > There is a possible issue with the performance for 2.9.1 vs > > 2.10. > > > I'm > > > > > >> > trying to reproduce on a stress-testing environment. > > > > > >> > [1] > > > > > >> > > > > > > > > > > > https://cwiki.apache.org/confluence/download/attachments/165224767/atomicPutRandomValueFullSync.jpg?api=v2 > > > > > >> > > > > > > >> > On Fri, 12 Feb 2021 at 20:46, Maxim Muzafarov < > > mmu...@apache.org > > > > > > > > > wrote: > > > > > >> > > > > > > > >> > > Folks, > > > > > >> > > > > > > > >> > > I'm going to cherry-pick these issues to the release branch, > > any > > > > > >> > objections? > > > > > >> > > > > > > > >> > > > > > > > >> > > Checkpointer thread holds write lock too long > > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-14140 > > > > > >> > > > > > > > >> > > Incorrect initialize checkpoint-runner-cpu thread pool > > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-14139 > > > > > >> > > > > > > > >> > > On Wed, 10 Feb 2021 at 21:59, Maxim Muzafarov < > > > mmu...@apache.org > > > > > > wrote: > > > > > >> > > > > > > > > >> > > > Folks, > > > > > >> > > > > > > > > >> > > > Do we need any other critical issues from the master branch > > > that > > > > > need > > > > > >> > > > to be cherry-picked picked from the master branch? I've > > > marked the > > > > > >> > > > latest select issues with patching version 2.10. > > > > > >> > > > > > > > > >> > > > - benchmarks completed (I'll do another
[jira] [Created] (IGNITE-14210) Tracing: add tracing for thin client
Surkov Aleksandr created IGNITE-14210: - Summary: Tracing: add tracing for thin client Key: IGNITE-14210 URL: https://issues.apache.org/jira/browse/IGNITE-14210 Project: Ignite Issue Type: Improvement Reporter: Surkov Aleksandr Now it is possible to receive traces for thick client. It would be great to be able to do this for a thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [jira] [Created] (IGNITE-14208) .NET: Examples multi targeting
Big +1 for this.
On a related note, we just ran into a versioning issue related to the .Net
Standard 2.0 support in IA. We use .Net Core 3.1 with IA 2.8.1 and wanted
to use the StackExchange Redis client. However, the latest client has a
dependency on System.Diagnostics.PerformanceCounter 5.0.0, but IA C# 2.8.1
has a specific dependency for System.Diagnostics.PerformanceCounter < 5.0.0.
This means we're having to use a slightly older version of the Redis client
before they moved to support .Net Core 3.1
On Fri, Feb 19, 2021 at 4:55 AM Pavel Tupitsyn (Jira)
wrote:
> Pavel Tupitsyn created IGNITE-14208:
> ---
>
> Summary: .NET: Examples multi targeting
> Key: IGNITE-14208
> URL: https://issues.apache.org/jira/browse/IGNITE-14208
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Fix For: 2.11
>
>
> Currently examples require .NET SDK 2.1, which is quite old. Users are
> more likely to have .NET Core 3.1 or .NET 5 installed.
>
> Fix example projects and replace
>
> {code}
> netcoreapp2.1
> {code}
>
> with
>
> {code}
> netcoreapp2.1;netcoreapp3.1;net5
> {code}
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>
--
Re: Ignite 2.81. - NULL pointer exception
Was there a resolution for this issue? On Mon, Sep 7, 2020 at 9:40 AM Ilya Kasnacheev wrote: > Hello! > > I wonder why there's no stack traces for all the threads. > > I wonder if somebody from the development side will step in (2.8.1): > > [05:57:16,193][SEVERE][sys-stripe-15-#16][] Critical system error > detected. Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, > err=java.lang.NullPointerException]] > java.lang.NullPointerException > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1064) > // tx is null? > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:953) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:909) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:123) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:217) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:215) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) > at > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472) > at > org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229) > at > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > at java.lang.Thread.run(Thread.java:745) > > Regards, > -- > Ilya Kasnacheev > > > ср, 2 сент. 2020 г. в 11:05, Mahesh Renduchintala < > mahesh.renduchint...@aline-consulting.com>: > >> I sent the logs again. There is no specific activity. >> We have a cluster - 2 servers and about 15 thick clients >> >> Just happened without much info. I can say it is likely a new node joined >> in and it may have triggered this crash. >> >> >>
[jira] [Created] (IGNITE-14211) Python thin: SQL API is broken
Igor Sapego created IGNITE-14211: Summary: Python thin: SQL API is broken Key: IGNITE-14211 URL: https://issues.apache.org/jira/browse/IGNITE-14211 Project: Ignite Issue Type: Bug Affects Versions: python-0.3.4 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: python-0.4.0 Currently, Client.sql() call uses a 'schema' argument to get cache instance and fails when there are no such cache. It leads to weird fails when user tries to run SQL over PUBLIC schema, and may fail in other cases when cache name is different from schema name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
