[jira] [Created] (IGNITE-11987) [IEP-35] Add ability to configure metrics
Nikolay Izhikov created IGNITE-11987: Summary: [IEP-35] Add ability to configure metrics Key: IGNITE-11987 URL: https://issues.apache.org/jira/browse/IGNITE-11987 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Ignite should be able to: * Enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Empty TC job PDS (Indexing / WAL & Recovery)
Hi, Does anyone know what is the purpose of job PDS (Indexing / WAL & Recovery) [1]? It refers to non-existing IgnitePdsWithIndexingWalAndRecoveryTestSuite class and runs no tests. Can we delete it safely? [1] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexingWalRecovery?branch=%3Cdefault%3E&buildTypeTab=overview -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-11988) control.sh validate_indexes SQL Index issue add information about group and cache id
Kirill Tkalenko created IGNITE-11988: Summary: control.sh validate_indexes SQL Index issue add information about group and cache id Key: IGNITE-11988 URL: https://issues.apache.org/jira/browse/IGNITE-11988 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: Empty TC job PDS (Indexing / WAL & Recovery)
Hi Ivan, Please see the thread `Removal of TC Run Configuration PdsIndexingWalRecovery` https://lists.apache.org/thread.html/ad0b3b69c1ddf637e817f35b34e3f117e6565c38522d030e86e0e773@%3Cdev.ignite.apache.org%3E Since nobody came there, I guess it is ok to just remove it. Sincerely, Dmitriy Pavlov ср, 17 июл. 2019 г. в 12:18, Павлухин Иван : > Hi, > > Does anyone know what is the purpose of job PDS (Indexing / WAL & > Recovery) [1]? It refers to non-existing > IgnitePdsWithIndexingWalAndRecoveryTestSuite class and runs no tests. > Can we delete it safely? > > [1] > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexingWalRecovery?branch=%3Cdefault%3E&buildTypeTab=overview > > -- > Best regards, > Ivan Pavlukhin >
[jira] [Created] (IGNITE-11989) Preload predicate not used in GridCachePreloader
Maxim Muzafarov created IGNITE-11989:
Summary: Preload predicate not used in GridCachePreloader
Key: IGNITE-11989
URL: https://issues.apache.org/jira/browse/IGNITE-11989
Project: Ignite
Issue Type: Improvement
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Fix For: 2.8
{code:title=GridCachePreloader.java}
/**
* @return Preload predicate. If not {@code null}, will evaluate each
preloaded entry during
* send and receive, and if predicate evaluates to {@code false},
entry will be skipped.
*/
public IgnitePredicate preloadPredicate();
{code}
This is internal cache preload predicate, which is not used and not tested for
entry preloading. Can be removed to keep code simple.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-11990) Optimize heap usage for TcpDiscoveryNodeAddedMessage stored in pending messages in ServerImpl
Vladimir Malinovskiy created IGNITE-11990: - Summary: Optimize heap usage for TcpDiscoveryNodeAddedMessage stored in pending messages in ServerImpl Key: IGNITE-11990 URL: https://issues.apache.org/jira/browse/IGNITE-11990 Project: Ignite Issue Type: Improvement Reporter: Vladimir Malinovskiy Assignee: Vladimir Malinovskiy We are storing pending discovery messages in deserialized form. Pending message could be heavy, for example TcpDiscoveryNodeAddedMessage. I think we should store only information requeired for resending messages across ring. In case of TcpDiscoveryNodeAddedMessage we couldn't store unmarhalled data in DiscoveryDataPacket -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: Removal of TC Run Configuration PdsIndexingWalRecovery
Here is a closed PR [1]. Let's drop that run-config [2]. [1] https://github.com/apache/ignite/pull/4239/files [2] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexingWalRecovery?branch=%3Cdefault%3E&buildTypeTab=overview чт, 21 мар. 2019 г. в 17:53, Petr Ivanov : > > According to git log, test was removed (or renamed) somewhere here [1], but > there is no hard evidence. > AFAIK, that is only possible if merging branch where this file did not exist > with branch where it was added first time — new files do not staged > automatically. > > > [1] > https://github.com/apache/ignite/commit/2ebe7b3e0d2d9671feffe44319d5b2dc743e5837 > > > On 21 Mar 2019, at 17:03, Dmitriy Pavlov wrote: > > > > Hi Igniters, > > > > TC Run config > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > > > > > > references to non-existent suite class > > IgnitePdsWithIndexingWalAndRecoveryTestSuite > > > > Please share information if you know how it is named now. > > > > Otherwise, I suggest deleting run-config after 3 days. > > > > Sincerely, > > Dmitriy Pavlov > -- Best regards, Ivan Pavlukhin
Re: Removal of TC Run Configuration PdsIndexingWalRecovery
Yet another candidate https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_QueriesOom?branch=pull%2F4611%2Fhead&buildTypeTab=overview ср, 17 июл. 2019 г. в 14:06, Павлухин Иван : > > Here is a closed PR [1]. Let's drop that run-config [2]. > > [1] https://github.com/apache/ignite/pull/4239/files > [2] > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexingWalRecovery?branch=%3Cdefault%3E&buildTypeTab=overview > > чт, 21 мар. 2019 г. в 17:53, Petr Ivanov : > > > > > According to git log, test was removed (or renamed) somewhere here [1], but > > there is no hard evidence. > > AFAIK, that is only possible if merging branch where this file did not > > exist with branch where it was added first time — new files do not staged > > automatically. > > > > > > [1] > > https://github.com/apache/ignite/commit/2ebe7b3e0d2d9671feffe44319d5b2dc743e5837 > > > > > On 21 Mar 2019, at 17:03, Dmitriy Pavlov wrote: > > > > > > Hi Igniters, > > > > > > TC Run config > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > > > > > > > > > references to non-existent suite class > > > IgnitePdsWithIndexingWalAndRecoveryTestSuite > > > > > > Please share information if you know how it is named now. > > > > > > Otherwise, I suggest deleting run-config after 3 days. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
Re: Read Repair (ex. Consistency Check) - review request #2
Hello Anton, It's not possible, currently, to fix atomic caches. > You may only check the consistency. *And it's better than nothing*, I > think. Fair enough. >> 3. IgniteConsistencyViolationException is absolutely useless. It does not > >> provide any information about the issue and possible way to fix it. > It means that some keys from your get operation are broken. > IgniteConsistencyViolationException CAN be extended with a list of broken > keys in the future. I think it SHOULD be extended with additional fields/methods in the same way as CacheConsistencyViolationEvent >> Well, near caches are widely used and fully transactional, so I think it > >> makes sense to support the feature for near caches too. > As I told before, it will be nice to implement this in the future, but we > have more important tasks for now. I do not insist that it must be done right now. > >> For instance, I would like to see all these limitations on the IEP page > as > >> JIRA tickets. Perhaps, it would be good to create an epic/umbrella > ticket > >> in order to track all activities related to `Read Repair` feature. > Let's do this at merge day to be sure useless issues will not be created. > I am just trying to say that it is a good time to create tickets in order to track all of that otherwise the chance that all these limitations/improvements will not be addressed is very high. Thanks, S. вт, 16 июл. 2019 г. в 09:07, Anton Vinogradov : > Svala, > > >> Could you please take a look at PR: > Going to review today, thanks for attaching the bot visa. > > >> 1. Should I consider that my cluster is broken? There is no answer! The > >> false-positive result is possible. > That's a question about atomic nature. > It's not impossible to lock atomic entry to perform the check. > You should perform some attempts, it's your decision how many. > By default, atomic RR performs 3 attempts, you may increase this by setting > IGNITE_NEAR_GET_MAX_REMAPS or by just performing additional gets. > > >> 2. What should be done here in order to check/resolve the issue? > Perhaps, I > >> should restart a node (which one?), restart the whole cluster, put a new > >> value... > It's not possible, currently, to fix atomic caches. > You may only check the consistency. And it's better than nothing, I think. > We should find a way how to fix atomic consistency first. > A possible strategy is to use ЕntryProcessor which will replace all owner's > values with "latest" and do nothing in case newest (than latest) value > found (opposite to preloading approach). > > >> 3. IgniteConsistencyViolationException is absolutely useless. It does > not > >> provide any information about the issue and possible way to fix it. > It means that some keys from your get operation are broken. > IgniteConsistencyViolationException CAN be extended with a list of broken > keys in the future. > > >> It seems that transactional caches are covered much better. > Correct. > Tx caches consistency is more important that atomic consistency, that's why > it was implemented first. > BTW, AFAIK, atomics also were not fixed at 10078 [1]. > > >> Well, near caches are widely used and fully transactional, so I think it > >> makes sense to support the feature for near caches too. > As I told before, it will be nice to implement this in the future, but we > have more important tasks for now. > The main goal was to cover tx caches, to be able to fix them in case of the > real problem at production. > > Summarizing the roadmap, > My goal now is to finish the tx case, now we have an issue with false > positive consistency violation [2]. > Also, we're going to update Jepsen tests [3] with RR to ensure tx caches > fixed. > Next main goal is to use RR at TC checks [4], help with this issue are > appreciated. > > [1] https://issues.apache.org/jira/browse/IGNITE-10078 > [2] https://issues.apache.org/jira/browse/IGNITE-11973 > [3] https://issues.apache.org/jira/browse/IGNITE-11972 > [4] https://issues.apache.org/jira/browse/IGNITE-11971 > > > On Mon, Jul 15, 2019 at 4:51 PM Dmitriy Pavlov wrote: > > > Ok, thank you > > > > пн, 15 июл. 2019 г., 16:46 Nikolay Izhikov : > > > > > I did the review. > > > > > > пн, 15 июля 2019 г., 16:15 Dmitriy Pavlov : > > > > > > > Igniters, who did a review of > > > > https://issues.apache.org/jira/browse/IGNITE-10663 before the merge? > > > I've > > > > checked both PR https://github.com/apache/ignite/pull/5656 and > > Issue, > > > > and dev.list thread and didn't find any LGTM. > > > > > > > > Anton, since you've rejected lazy consensus in our process, we have > RTC > > > in > > > > that (core) module. So I'd like to know if the fix was covered by the > > > > review. > > > > > > > > Because you're a committer, a reviewer can be non-committer. So, who > > was > > > a > > > > reviewer? Or was process ignored? > > > > > > > > пн, 15 июл. 2019 г. в 15:37, Вячеслав Коптилин < > > slava.kopti...@gmail.com > > > >: > > > > > > > > > Hello Anton, > > > > > > > >
[jira] [Created] (IGNITE-11991) [TC Bot]: Rerun possible blockers sets incorrect "SCALE FACTOR" build parameter
Pavel Kuznetsov created IGNITE-11991: Summary: [TC Bot]: Rerun possible blockers sets incorrect "SCALE FACTOR" build parameter Key: IGNITE-11991 URL: https://issues.apache.org/jira/browse/IGNITE-11991 Project: Ignite Issue Type: Improvement Reporter: Pavel Kuznetsov 1) Issue "Trigger build" during PR check from the Bot UI. Scheduled build has parameter SCALE FACTOR=0.1 which is ok, because we want to get results sooner. 2) Issue "Rerun possible blockers" and see that SF for the "rerun" TC builds is 1.0 (default). Expected that SF of the rerun builds should be the same as in the initial RunAll build. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Folks, Sorry if I am repeating something. I checked a page [1] and have not found several items. 1. I thought that there was an agreement of dropping OLD service grid, was not it? 2. Also IndexingSpi seems to me as a candidate for removal. Should I add those items to the page? Or is there another page containing items to be removed that we agreed on? [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist ср, 17 июл. 2019 г. в 02:00, Denis Magda : > > Alex, Igniters, sorry for a delay. Got swamped with other duties. > > Does it wait till the next week? I'll make sure to dedicate some time for > that. Or if we'd like to run faster then I'll appreciate if someone else > steps in and prepares a list this week. I'll help to review and solidify it. > > - > Denis > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk > wrote: > > > Denis, > > > > Are we ready to present the list to the user list? > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda : > > > > > I wouldn't kick off dozens of voting discussions. Instead, the content on > > > the wiki page needs to be cleaned and rearranged. This will make the > > > content readable and comprehensible. I can do that. > > > > > > Next, let's ask the user community for an opinion. After reviewing and > > > incorporating the latter we can do one more dev list discussion with the > > > last call for opinions. Next, will be the voting time. If there is a > > > feature someone from the dev list is against of removing, then we can > > start > > > a separate vote for it later. But let's get into those cases first. > > > > > > - > > > Denis > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov > > wrote: > > > > > > > I propose each removal should have separated formal vote thread with > > > > consensus approval (since it is code modification). > > > > > > > > This means a single binding objection with justification is a blocker > > for > > > > removal. > > > > > > > > We need separation to let community members pick up an interesting > > topic > > > > from email subject. Not all members reading carefully each post in > > > > mile-long threads. > > > > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov : > > > > > > > > > +1 to email survey with following types of votes > > > > > - silence (agree with all proposed removals) > > > > > - we have to keep XXX because ... > > > > > > > > > > As a result, will gain lists > > > > > "to be removed" - no one objected > > > > > "can be removed" - single objection > > > > > "should be kept" - multi objections > > > > > > > > > > Denis or Dmitry Pavlov, could you please lead this thread? > > > > > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda > > > wrote: > > > > > > > > > > > Alex, > > > > > > > > > > > > I would do an email survey to hear an opinion of why someone > > > believes a > > > > > > feature A has to stay. It makes sense to ask about the APIs to be > > > > removed > > > > > > as well as integrations to go out of community support [1] in the > > > same > > > > > > thread. > > > > > > > > > > > > Has everyone expressed an opinion? If yes, I can go ahead and > > format > > > > the > > > > > > wishlist page and make it structured for the user thread. > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk < > > > > > > alexey.goncha...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Anton, good point. > > > > > > > > > > > > > > Do you have any idea how we can keep track of the voting? Should > > we > > > > > > launch > > > > > > > a google survey or survey monkey? Voting by email? > > > > > > > > > > > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov : > > > > > > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > Thank's for keeping an eye on page updates. > > > > > > > > Near Caches is not a bad feature, but it should be used with > > > > caution. > > > > > > > > At least we have to explain how it works on readme.io, why and > > > > when > > > > > it > > > > > > > > should be used because usage can drop the performance instead > > of > > > > > > > increasing > > > > > > > > it. > > > > > > > > > > > > > > > > Anyway, I added near caches because I never heard someone used > > > them > > > > > > > > meaningfully, not like a silver bullet. > > > > > > > > So, that's just a proposal :) > > > > > > > > > > > > > > > > Also, I'd like to propose to have some voting about full list > > > later > > > > > to > > > > > > > gain > > > > > > > > "must be removed", "can be removed" and "should be kept" lists. > > > > > > > > > > > > > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey Goncharuk < > > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Anton, > > > > > > > > > > > > > > > > > > I would like to
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Also, I did not quite get the point about JSR107 (JCache). From time to time I see on user-list threads where Ignite is used along with Spring annotation-based cache integration. I suppose it requires JCache interfaces. What is crucially wrong with supporting it? ср, 17 июл. 2019 г. в 15:19, Павлухин Иван : > > Folks, > > Sorry if I am repeating something. I checked a page [1] and have not > found several items. > 1. I thought that there was an agreement of dropping OLD service grid, > was not it? > 2. Also IndexingSpi seems to me as a candidate for removal. > > Should I add those items to the page? Or is there another page > containing items to be removed that we agreed on? > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > ср, 17 июл. 2019 г. в 02:00, Denis Magda : > > > > Alex, Igniters, sorry for a delay. Got swamped with other duties. > > > > Does it wait till the next week? I'll make sure to dedicate some time for > > that. Or if we'd like to run faster then I'll appreciate if someone else > > steps in and prepares a list this week. I'll help to review and solidify it. > > > > - > > Denis > > > > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk > > > > wrote: > > > > > Denis, > > > > > > Are we ready to present the list to the user list? > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda : > > > > > > > I wouldn't kick off dozens of voting discussions. Instead, the content > > > > on > > > > the wiki page needs to be cleaned and rearranged. This will make the > > > > content readable and comprehensible. I can do that. > > > > > > > > Next, let's ask the user community for an opinion. After reviewing and > > > > incorporating the latter we can do one more dev list discussion with the > > > > last call for opinions. Next, will be the voting time. If there is a > > > > feature someone from the dev list is against of removing, then we can > > > start > > > > a separate vote for it later. But let's get into those cases first. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov > > > wrote: > > > > > > > > > I propose each removal should have separated formal vote thread with > > > > > consensus approval (since it is code modification). > > > > > > > > > > This means a single binding objection with justification is a blocker > > > for > > > > > removal. > > > > > > > > > > We need separation to let community members pick up an interesting > > > topic > > > > > from email subject. Not all members reading carefully each post in > > > > > mile-long threads. > > > > > > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov : > > > > > > > > > > > +1 to email survey with following types of votes > > > > > > - silence (agree with all proposed removals) > > > > > > - we have to keep XXX because ... > > > > > > > > > > > > As a result, will gain lists > > > > > > "to be removed" - no one objected > > > > > > "can be removed" - single objection > > > > > > "should be kept" - multi objections > > > > > > > > > > > > Denis or Dmitry Pavlov, could you please lead this thread? > > > > > > > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda > > > > wrote: > > > > > > > > > > > > > Alex, > > > > > > > > > > > > > > I would do an email survey to hear an opinion of why someone > > > > believes a > > > > > > > feature A has to stay. It makes sense to ask about the APIs to be > > > > > removed > > > > > > > as well as integrations to go out of community support [1] in the > > > > same > > > > > > > thread. > > > > > > > > > > > > > > Has everyone expressed an opinion? If yes, I can go ahead and > > > format > > > > > the > > > > > > > wishlist page and make it structured for the user thread. > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk < > > > > > > > alexey.goncha...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Anton, good point. > > > > > > > > > > > > > > > > Do you have any idea how we can keep track of the voting? Should > > > we > > > > > > > launch > > > > > > > > a google survey or survey monkey? Voting by email? > > > > > > > > > > > > > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov : > > > > > > > > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > > > Thank's for keeping an eye on page updates. > > > > > > > > > Near Caches is not a bad feature, but it should be used with > > > > > caution. > > > > > > > > > At least we have to explain how it works on readme.io, why and > > > > > when > > > > > > it > > > > > > > > > should be used because usage can drop the performance instead > > > of > > > > > > > > increasing > > > > > > > > > it. > > > > > > > > > > > > > > > > > > Anyway, I added near caches because I never hea
Re: [DISCUSSION] Ignite 3.0 and to be removed list
Ivan, * About Service Grid: Yes, we discussed that old service grid implementation (GridServiceProcessor) should be removed in 3.0, now it is marked as obsolete. This was in the list, maybe it was lost during formatting. Also, a class `ServiceConfiguration` should be moved to common package of configurations: 'org.apache.ignite.configuration' it will bring to change of API. * About JSR107: I thought that JSR107 compliance is one of the advantages of Ignite, at least in In-Memory mode. I'm not sure why we should drop it. On Wed, Jul 17, 2019 at 3:26 PM Павлухин Иван wrote: > > Also, I did not quite get the point about JSR107 (JCache). From time > to time I see on user-list threads where Ignite is used along with > Spring annotation-based cache integration. I suppose it requires > JCache interfaces. What is crucially wrong with supporting it? > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван : > > > > Folks, > > > > Sorry if I am repeating something. I checked a page [1] and have not > > found several items. > > 1. I thought that there was an agreement of dropping OLD service grid, > > was not it? > > 2. Also IndexingSpi seems to me as a candidate for removal. > > > > Should I add those items to the page? Or is there another page > > containing items to be removed that we agreed on? > > > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda : > > > > > > Alex, Igniters, sorry for a delay. Got swamped with other duties. > > > > > > Does it wait till the next week? I'll make sure to dedicate some time for > > > that. Or if we'd like to run faster then I'll appreciate if someone else > > > steps in and prepares a list this week. I'll help to review and solidify > > > it. > > > > > > - > > > Denis > > > > > > > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk > > > > > > wrote: > > > > > > > Denis, > > > > > > > > Are we ready to present the list to the user list? > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda : > > > > > > > > > I wouldn't kick off dozens of voting discussions. Instead, the > > > > > content on > > > > > the wiki page needs to be cleaned and rearranged. This will make the > > > > > content readable and comprehensible. I can do that. > > > > > > > > > > Next, let's ask the user community for an opinion. After reviewing and > > > > > incorporating the latter we can do one more dev list discussion with > > > > > the > > > > > last call for opinions. Next, will be the voting time. If there is a > > > > > feature someone from the dev list is against of removing, then we can > > > > start > > > > > a separate vote for it later. But let's get into those cases first. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > I propose each removal should have separated formal vote thread with > > > > > > consensus approval (since it is code modification). > > > > > > > > > > > > This means a single binding objection with justification is a > > > > > > blocker > > > > for > > > > > > removal. > > > > > > > > > > > > We need separation to let community members pick up an interesting > > > > topic > > > > > > from email subject. Not all members reading carefully each post in > > > > > > mile-long threads. > > > > > > > > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov : > > > > > > > > > > > > > +1 to email survey with following types of votes > > > > > > > - silence (agree with all proposed removals) > > > > > > > - we have to keep XXX because ... > > > > > > > > > > > > > > As a result, will gain lists > > > > > > > "to be removed" - no one objected > > > > > > > "can be removed" - single objection > > > > > > > "should be kept" - multi objections > > > > > > > > > > > > > > Denis or Dmitry Pavlov, could you please lead this thread? > > > > > > > > > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda > > > > > wrote: > > > > > > > > > > > > > > > Alex, > > > > > > > > > > > > > > > > I would do an email survey to hear an opinion of why someone > > > > > believes a > > > > > > > > feature A has to stay. It makes sense to ask about the APIs to > > > > > > > > be > > > > > > removed > > > > > > > > as well as integrations to go out of community support [1] in > > > > > > > > the > > > > > same > > > > > > > > thread. > > > > > > > > > > > > > > > > Has everyone expressed an opinion? If yes, I can go ahead and > > > > format > > > > > > the > > > > > > > > wishlist page and make it structured for the user thread. > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html > > > > > > > > - > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk < > > > > > > > > alexey.goncha...@gmail.com> > > > > >
Improvements for new security approach.
Hello, Igniters. The main idea of the new security is propagation security context to other nodes and does action with initial permission. The solution looks fine but has imperfections. 1. ZookeaperDiscoveryImpl doesn't implement security into itself. As a result: Caused by: class org.apache.ignite.spi.IgniteSpiException: Security context isn't certain. 2. The visor tasks lost permission. The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses context. 3. The GridRestProcessor does tasks outside "withContext" section. As result context loses. 4. The GridRestProcessor isn't client, we can't read security subject from node attribute. We should transmit secCtx for fake nodes and secSubjId for real. 5. NoOpIgniteSecurityProcessor should include a disabled processor and validate it too if it is not null. It is important for a client node. For example: Into IgniteKernal#securityProcessor method createComponent return a GridSecurityProcessor. For server nodes are enabled, but for clients aren't. The clients aren't able to pass validation for this reason. 6. ATTR_SECURITY_SUBJECT was removed. It broke compatibility. I going to fix it.
[jira] [Created] (IGNITE-11992) Improvements for new security approach
Stepachev Maksim created IGNITE-11992: - Summary: Improvements for new security approach Key: IGNITE-11992 URL: https://issues.apache.org/jira/browse/IGNITE-11992 Project: Ignite Issue Type: Improvement Components: security Affects Versions: 2.8 Reporter: Stepachev Maksim Assignee: Stepachev Maksim Fix For: 2.8 1. ZookeaperDiscoveryImpl doesn't implement security into itself. As a result: Caused by: class org.apache.ignite.spi.IgniteSpiException: Security context isn't certain. 2. The visor tasks lost permission. The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses context. 3. The GridRestProcessor does tasks outside "withContext" section. As result context loses. 4. The GridRestProcessor isn't client, we can't read security subject from node attribute. We should transmit secCtx for fake nodes and secSubjId for real. 5. NoOpIgniteSecurityProcessor should include a disabled processor and validate it too if it is not null. It is important for a client node. For example: Into IgniteKernal#securityProcessor method createComponent return a GridSecurityProcessor. For server nodes are enabled, but for clients aren't. The clients aren't able to pass validation for this reason. 6. ATTR_SECURITY_SUBJECT was removed. It broke compatibility. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: Removal of TC Run Configuration PdsIndexingWalRecovery
FYI, Build configuration PdsIndexingWalRecovery was removed. ср, 17 июл. 2019 г. в 14:31, Павлухин Иван : > > Yet another candidate > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_QueriesOom?branch=pull%2F4611%2Fhead&buildTypeTab=overview > > ср, 17 июл. 2019 г. в 14:06, Павлухин Иван : > > > > Here is a closed PR [1]. Let's drop that run-config [2]. > > > > [1] https://github.com/apache/ignite/pull/4239/files > > [2] > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexingWalRecovery?branch=%3Cdefault%3E&buildTypeTab=overview > > > > чт, 21 мар. 2019 г. в 17:53, Petr Ivanov : > > > > > > > > According to git log, test was removed (or renamed) somewhere here [1], > > > but there is no hard evidence. > > > AFAIK, that is only possible if merging branch where this file did not > > > exist with branch where it was added first time — new files do not staged > > > automatically. > > > > > > > > > [1] > > > https://github.com/apache/ignite/commit/2ebe7b3e0d2d9671feffe44319d5b2dc743e5837 > > > > > > > On 21 Mar 2019, at 17:03, Dmitriy Pavlov wrote: > > > > > > > > Hi Igniters, > > > > > > > > TC Run config > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexingWalRecovery&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv > > > > > > > > > > > > references to non-existent suite class > > > > IgnitePdsWithIndexingWalAndRecoveryTestSuite > > > > > > > > Please share information if you know how it is named now. > > > > > > > > Otherwise, I suggest deleting run-config after 3 days. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-11993) Print warning if awaiting next wal segment it too long
Kirill Tkalenko created IGNITE-11993: Summary: Print warning if awaiting next wal segment it too long Key: IGNITE-11993 URL: https://issues.apache.org/jira/browse/IGNITE-11993 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 We must print warn to log, if awaiting next WAL segment more then defined threshold. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11994) [TC Bot] Prepare new view to select base branch and other build parameters
Dmitriy Pavlov created IGNITE-11994: --- Summary: [TC Bot] Prepare new view to select base branch and other build parameters Key: IGNITE-11994 URL: https://issues.apache.org/jira/browse/IGNITE-11994 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov New view required for reports view and for VISAs creation for non-standard master branches, additional features may be contributed to this new view later -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: [DISCUSSION] Ignite 3.0 and to be removed list
JSR107 point - it is standard, it is always easy to refer to something user may already know. BTW we have 1.0 in Ignite dependency, 1.1.1 recently released, maybe we should upgrade in 3.0. See also: https://mvnrepository.com/artifact/javax.cache/cache-api/1.1.1 ср, 17 июл. 2019 г. в 15:51, Vyacheslav Daradur : > Ivan, > > * About Service Grid: > Yes, we discussed that old service grid implementation > (GridServiceProcessor) should be removed in 3.0, now it is marked as > obsolete. > This was in the list, maybe it was lost during formatting. > > Also, a class `ServiceConfiguration` should be moved to common package > of configurations: 'org.apache.ignite.configuration' it will bring to > change of API. > > * About JSR107: > I thought that JSR107 compliance is one of the advantages of Ignite, > at least in In-Memory mode. > I'm not sure why we should drop it. > > On Wed, Jul 17, 2019 at 3:26 PM Павлухин Иван wrote: > > > > Also, I did not quite get the point about JSR107 (JCache). From time > > to time I see on user-list threads where Ignite is used along with > > Spring annotation-based cache integration. I suppose it requires > > JCache interfaces. What is crucially wrong with supporting it? > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван : > > > > > > Folks, > > > > > > Sorry if I am repeating something. I checked a page [1] and have not > > > found several items. > > > 1. I thought that there was an agreement of dropping OLD service grid, > > > was not it? > > > 2. Also IndexingSpi seems to me as a candidate for removal. > > > > > > Should I add those items to the page? Or is there another page > > > containing items to be removed that we agreed on? > > > > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda : > > > > > > > > Alex, Igniters, sorry for a delay. Got swamped with other duties. > > > > > > > > Does it wait till the next week? I'll make sure to dedicate some > time for > > > > that. Or if we'd like to run faster then I'll appreciate if someone > else > > > > steps in and prepares a list this week. I'll help to review and > solidify it. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk < > alexey.goncha...@gmail.com> > > > > wrote: > > > > > > > > > Denis, > > > > > > > > > > Are we ready to present the list to the user list? > > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda : > > > > > > > > > > > I wouldn't kick off dozens of voting discussions. Instead, the > content on > > > > > > the wiki page needs to be cleaned and rearranged. This will make > the > > > > > > content readable and comprehensible. I can do that. > > > > > > > > > > > > Next, let's ask the user community for an opinion. After > reviewing and > > > > > > incorporating the latter we can do one more dev list discussion > with the > > > > > > last call for opinions. Next, will be the voting time. If there > is a > > > > > > feature someone from the dev list is against of removing, then > we can > > > > > start > > > > > > a separate vote for it later. But let's get into those cases > first. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov < > dpav...@apache.org> > > > > > wrote: > > > > > > > > > > > > > I propose each removal should have separated formal vote > thread with > > > > > > > consensus approval (since it is code modification). > > > > > > > > > > > > > > This means a single binding objection with justification is a > blocker > > > > > for > > > > > > > removal. > > > > > > > > > > > > > > We need separation to let community members pick up an > interesting > > > > > topic > > > > > > > from email subject. Not all members reading carefully each > post in > > > > > > > mile-long threads. > > > > > > > > > > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov : > > > > > > > > > > > > > > > +1 to email survey with following types of votes > > > > > > > > - silence (agree with all proposed removals) > > > > > > > > - we have to keep XXX because ... > > > > > > > > > > > > > > > > As a result, will gain lists > > > > > > > > "to be removed" - no one objected > > > > > > > > "can be removed" - single objection > > > > > > > > "should be kept" - multi objections > > > > > > > > > > > > > > > > Denis or Dmitry Pavlov, could you please lead this thread? > > > > > > > > > > > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda < > dma...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > > > Alex, > > > > > > > > > > > > > > > > > > I would do an email survey to hear an opinion of why > someone > > > > > > believes a > > > > > > > > > feature A has to stay. It makes sense to ask about the > APIs to be > > > > > > > removed > > > > > > > > > as well as integrations to go out of community support [1] > in the > > > > > > same > > > > > > > > > thread. > > > > > > > > > > > > >
[jira] [Created] (IGNITE-11995) control.sh if experimental command disabled - don't show help for experemental commands
Kirill Tkalenko created IGNITE-11995: Summary: control.sh if experimental command disabled - don't show help for experemental commands Key: IGNITE-11995 URL: https://issues.apache.org/jira/browse/IGNITE-11995 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 If experimental command disabled: * don't show WALCommand help * if user ask for help for particular command - print out warning about experimental commands instead of ignoring user request -- This message was sent by Atlassian JIRA (v7.6.14#76016)
