[jira] [Created] (IGNITE-12671) Update of partition's states can stuck when rebalance completed during exchange
Vladislav Pyatkov created IGNITE-12671:
--
Summary: Update of partition's states can stuck when rebalance
completed during exchange
Key: IGNITE-12671
URL: https://issues.apache.org/jira/browse/IGNITE-12671
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Single message is ignoring during exchange:
{code:java|GridCachePartitionExchangeManager.java}
if (exchangeInProgress()) {
if (log.isInfoEnabled())
log.info("Ignore single message without exchange id (there is exchange in
progress) [nodeId=" + node.id() + "]");
return;
}
{code}
By thew reason the message does not be received after exchange. As result
waiting ideal assignment stuck until next rebalance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: IGNITE-12361 Migrate Flume module to ignite-extensions
Hi Saikat, I left a couple of comments in pr: https://github.com/apache/ignite-extensions/pull/4#pullrequestreview-357891629. Please tell me what do you think about it. Best Regards, Evgenii вт, 11 февр. 2020 г. в 17:15, Saikat Maitra : > Hi, > > Can someone please help in review for these following PRs. I have > received approval for release process from Alexey and would need a code > review approval for following PR. > > Jira https://issues.apache.org/jira/browse/IGNITE-12361 > > PR https://github.com/apache/ignite-extensions/pull/4 > https://github.com/apache/ignite/pull/7227 > > Regards, > Saikat > > On Tue, Feb 11, 2020 at 6:47 PM Saikat Maitra > wrote: > > > Hi Alexey, > > > > > > I think we can release for spring boot autoconfigure module. > > > > Nikolay - Do you have tentative timeline when you are planning for > release > > of spring boot autoconfigure module. > > > > > > After that we are planning to make release for flink ext. > > > > > > Since, each module are independent so they will be released > independently. > > > > > > Regards, > > Saikat > > > > On Mon, 10 Feb 2020 at 7:33 AM, Alexey Goncharuk < > > alexey.goncha...@gmail.com> wrote: > > > >> Saikat, > >> > >> Yes, I think we can go ahead with the modules PRs as long as reviewers > are > >> ok with the changes. Given that there is an activity around the spring > >> module, which modules do you think will get to the first release? > >> > >> сб, 1 февр. 2020 г. в 21:37, Saikat Maitra : > >> > >> > Hi Alexey, > >> > > >> > Please let me know if I can share more info on the release process. I > >> have > >> > updated the issue confluence page on discussed approach for Ignite > >> > Extensions. Do you think the open PRs can be merged in Ignite > Extensions > >> > repo? > >> > > >> > Independent Integrations: > >> > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations > >> > Discussion Links: > >> > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-DiscussionLinks > >> > Tickets: > >> > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-Tickets > >> > > >> > Regards, > >> > Saikat > >> > > >> > On Sun, Jan 26, 2020 at 3:11 PM Saikat Maitra < > saikat.mai...@gmail.com> > >> > wrote: > >> > > >> > > Hi Alexey, > >> > > > >> > > As discussed I have updated the wiki with agreed solution. > >> > > > >> > > Independent Integrations: > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations > >> > > > >> > > Discussion Links: > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-DiscussionLinks > >> > > > >> > > Tickets: > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-Tickets > >> > > > >> > > Please let me know if I can share more information. > >> > > > >> > > Regards, > >> > > Saikat > >> > > > >> > > > >> > > On Fri, Jan 17, 2020 at 9:16 PM Saikat Maitra < > >> saikat.mai...@gmail.com> > >> > > wrote: > >> > > > >> > >> Hello Alexey, > >> > >> > >> > >> Thank you for your email. > >> > >> > >> > >> 1. Yes, we discussed in dev list and agreed on creating a new > >> repository > >> > >> for hosting our Ignite integrations. Please find the discussion > >> thread > >> > >> below. I will update the wiki page as well and share updates. > >> > >> > >> > >> > >> > >> > >> > > >> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html > >> > >> > >> > >> 2. I was hoping to complete migration of the following modules > >> before we > >> > >> go ahead with release. I am tracking the jira story here > >> > >> https://issues.apache.org/jira/browse/IGNITE-12355 > >> > >> > >> > >>- Flink > >> > >>- Twitter > >> > >>- Storm > >> > >>- ZeroMQ > >> > >>- RocketMQ > >> > >>- Flume > >> > >>- MQTT > >> > >>- Camel > >> > >>- JMS > >> > >> > >> > >> 3. The dependencies for modules are pointing to latest snapshot of > >> > >> ignite project and if there are changes in ignite master branch > then > >> > >> related affected Ignite extensions module also need to be modified. > >> We > >> > will > >> > >> verify all the extensions for upcoming release but release only the > >> one > >> > >> that are impacted. We will plan to avoid publishing any extension > >> unless > >> > >> there are changes. Here is the discussion thread on release > process: > >> > >> > >> > >> > >> > >> > >> > > >> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-dependencies-and-release-process-for-Ignite-Extensions-td44478.html > >> > >> > >> > >> 4. Sounds good, we can maintain a compatibility matrix to
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hi Maxim, Do you have any understanding in regards to documentation readiness? I do remember Nikolay was creating a page for the new metrics framework and Artem stepped in as a reviewer. But not sure if that supposedly the largest item is completed and if the other pages need to be updated. - Denis On Tue, Feb 11, 2020 at 6:19 AM Maxim Muzafarov wrote: > Igniters, > > > Current the 2.8 release status > > > 1. The PR with RELEASE_NOTES fully updated [1]. > > 2. Previously mentioned performance drop has not been confirmed. Run > many times in different environments. All test results within the > margin of error. > In-memory, putAll, 4 nodes, 1 client > IgnitePutAllBenchmark: +1% > IgnitePutAllTxBenchmark: -6% > > 3. Waiting for the vote completion > (Allow or prohibit a joint use of @deprecated and @IgniteExperimental) > > 4. Mark MVCC with IgniteExperimental [2]. > > 5. Wait for ML examples to be fixed [3]. > > [1] https://github.com/apache/ignite/pull/7367/files > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/Mark-MVCC-with-IgniteExperimental-td45669.html > [3] https://issues.apache.org/jira/browse/IGNITE-12657 > > On Tue, 11 Feb 2020 at 15:08, Ivan Bessonov wrote: > > > > Hello Igniters, > > > > I'd like to add one more fix to the release: [1] > > It adds versioning to internal classes of distributed metastorage > component. > > Without this fix it would be much harder to update these classes without > > breaking binary compatibility. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12638 > > > > ср, 5 февр. 2020 г. в 22:33, Maxim Muzafarov : > > > > > Ivan, > > > > > > > Should not we state in release notes what new experimental API was > added? > > > > > > I think we should. Will do. > > > Just not to miss anything that we should mark with > > > @IgniteExperimental: Consistency Check [1], Monitoring [2] anything > > > else? > > > > > > > As Flink integration was moved to external repository how Ignite 2.8 > > > users will be able to use that integration? > > > > > > Since ignite-extension has a separate release cycle (right?), it is > > > better to release ignite-extension rather than cherry-pick this change > > > back to 2.8. I also think it is not a blocker for the release, but we > > > should do our best make the first ignite-extension release as earlier > > > as possible. > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10663 > > > [2] https://issues.apache.org/jira/browse/IGNITE-11848 > > > > > > On Wed, 5 Feb 2020 at 22:07, Ivan Pavlukhin > wrote: > > > > > > > > Maxim, > > > > > > > > A couple of questions: > > > > 1. We added an annotation to designate experimental API. Should not > we > > > > state in release notes what new experimental API was added? Perhaps > in > > > > a separate block. > > > > 2. As Flink integration was moved to external repository how Ignite > > > > 2.8 users will be able to use that integration? > > > > > > > > ср, 5 февр. 2020 г. в 21:21, Maxim Muzafarov : > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > I've prepared RELEASE_NOTES pull-request [1] to the 2.8 release. > > > > > > > > > > Currently, IEP-35 monitoring issues are not included in this PR. > Will > > > > > do it soon. > > > > > Please, take a look. > > > > > > > > > > > > > > > [1] https://github.com/apache/ignite/pull/7367/files > > > > > > > > > > On Mon, 3 Feb 2020 at 14:38, Maxim Muzafarov > > > wrote: > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > Let me share the current status of the release. > > > > > > > > > > > > 1. > > > > > > Waiting for the issues [1] [2] (discussed previously this > thread) to > > > > > > be tested by TC.Bot and merged to the 2.8 release branch. > > > > > > > > > > > > 2. > > > > > > Only 2 release BLOCKER issues left. I'm planning to move these > issues > > > > > > to 2.8.1 release. > > > > > > The issue [4] (Error during purges by expiration: Unknown page > type) > > > > > > will be covered by [1] [2]. > > > > > > The issue [3] (Apache Ignite Cluster(Amazon S3 Based Discovery) > Nodes > > > > > > getting down) probably require additional info to reproduce the > > > issue. > > > > > > > > > > > > 3. > > > > > > A potential performance drop on `putAll` operations on an > in-memory > > > > > > cluster (see [5] for details). > > > > > > I'll try to reproduce in another test environment. > > > > > > > > > > > > > > > > > > Will keep you posted. > > > > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12593 > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-12594 > > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-12398 > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-12489 > > > > > > [5] > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks(LATEST) > > > > > > > > > > > > On Thu, 30 Jan 2020 at 15:02, Alexey Goncharuk > > > > > > wrote: > > > > > > > > > > > > > > Sounds good, will do! > >
[jira] [Created] (IGNITE-12670) .NET: Calculate IAffinity.GetPartition locally for default affinity
Pavel Tupitsyn created IGNITE-12670: --- Summary: .NET: Calculate IAffinity.GetPartition locally for default affinity Key: IGNITE-12670 URL: https://issues.apache.org/jira/browse/IGNITE-12670 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn For default affinity we already know how to calculate partition on .NET side, see `ClientRendezvousAffinityFunction`. This is faster than serializing the key and calling Java. Aside from other things, Near Cache depends on GetPartition for some use cases, so that will get faster too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12669) Remove not used rebalanceDelay from production code
Maxim Muzafarov created IGNITE-12669:
Summary: Remove not used rebalanceDelay from production code
Key: IGNITE-12669
URL: https://issues.apache.org/jira/browse/IGNITE-12669
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Currently, we've got rebalanceDelay property which is not used (in tests too)
and persists in production code.
Must be removed.
{code}
/** Delay before rebalancing code is start executing after exchange
completion. For tests only. */
private volatile long rebalanceDelay;
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Allow or prohibit a joint use of @deprecated and @IgniteExperimental
-1 Prohibit: My justification builds solely on the possibility to encourage a user to switch to an API that will be changed and later break the compilation.
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Maxim, rebalanceDelay was introduced before the BLT appear in the product to solve scenarios which are now solved by BLT. It's pointless for me having it in the product since BLT was introduced. I do not think delaying rebalancing per cache group has any meaning. I cannot image any reason for it. rebalanceOrder is also useless, agreed. ср, 12 февр. 2020 г. в 16:19, Maxim Muzafarov : > Alexey, > > Why do you think delaying of historical rebalance (on BLT node join) > for particular cache groups is not the real world use case? Probably > the same topic may be started on user-list to collect more use cases > from real users. > > In general, I support reducing the number of available rebalance > configuration parameters, but we should do it really carefully. > I can also propose - rebalanceOrder param for removing. > > On Wed, 12 Feb 2020 at 15:50, Alexei Scherbakov > wrote: > > > > Maxim, > > > > In general rebalanceDelay is used to delay/disable rebalance then > topology > > is changed. > > Right now we have BLT to avoid unnecesary rebalancing when topology is > > changed. > > If a node left from cluster topology no rebalancing happens until the > node > > explicitly removed from baseline topology. > > > > I would like to know real world scenarios which can not be covered by BLT > > configuration. > > > > > > > > ср, 12 февр. 2020 г. в 15:16, Maxim Muzafarov : > > > > > Alexey, > > > > > > > All scenarios where rebalanceDelay has meaning are handled by > baseline > > > topology now. > > > > > > Can you, please, provide more details here e.g. the whole list of > > > scenarios where rebalanceDelay is used and how these handled by > > > baseline topology? > > > > > > Actually, I doubt that it covers exactly all the cases due to > > > rebalanceDelay is a "per cache group property" rather than "baseline" > > > is meaningful for the whole topology. > > > > > > On Wed, 12 Feb 2020 at 12:58, Alexei Scherbakov > > > wrote: > > > > > > > > I've meant baseline topology. > > > > > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < > > > > alexey.scherbak...@gmail.com>: > > > > > > > > > > > > > > V.Pyatkov > > > > > > > > > > Doesn't rebalance topology solves it ? > > > > > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov : > > > > > > > > > >> Hi, > > > > >> > > > > >> I am sure we can to reduce this ability, but do not completely. > > > > >> We can use rebalance delay for disable it until manually > triggered. > > > > >> > > > > >> CacheConfiguration#setRebalanceDelay(-1) > > > > >> > > > > >> It may helpful for cluster where can not allow performance drop > from > > > > >> rebalance at any time. > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > >> > > > > > > > > > > > > > > > -- > > > > > > > > > > Best regards, > > > > > Alexei Scherbakov > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > Alexei Scherbakov > > > > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
Yes, you are right. Missed resources, I'll remove them tomorrow ср, 12 февр. 2020 г. в 16:23, Stepan Pilschikov : > With mnist_tf_model in same directory > All others looks right > > ср, 12 февр. 2020 г. в 16:21, Stepan Pilschikov >: > >> Hmm, interesting, got it >> Also found >> apache-ignite-2.8.0-bin/examples/src/main/resources/models/mleap >> I think its also should be removed then >> >> ср, 12 февр. 2020 г. в 16:11, Alexey Zinoviev : >> >>> Please, have a look to the next ticket >>> https://issues.apache.org/jira/browse/IGNITE-12659 >>> Also tensorflow packages are blockers for IGFS deprecation and removal. >>> >>> ср, 12 февр. 2020 г. в 15:58, Alexey Zinoviev : >>> They are not lost, they are removed from release branch due to a lot of bugs, cves and so on, don't worry about that. ср, 12 февр. 2020 г., 14:31 Stepan Pilschikov < pilshchikov@gmail.com>: > Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow in > libs/optional > > > ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov < > pilshchikov@gmail.com>: > >> But now have new problems >> I build ignite-2.8 build on TC >> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 >> Previous >> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 >> >> New build much lighter >> Previous: 5.7 Gb >> Current: 4.3 Gb >> And its looks like something missing, on a first look i notice that >> /libs/optional/ignite-ml-mleap-model-parser lost completely >> >> >> ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> >>> Thanks for fix >>> Duplicated examples deleted and tutorial works on real (1+ node) >>> cluster now >>> I think ticket can be closed, have no power here >>> >>> вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev < >>> zaleslaw@gmail.com>: >>> Sorry, for that, but I it touches ML-related stuff only and doesn't influence on any another module. I merged them to master later (currently, I have a 4 tickets in a queue). Will keep in mind for the next fixes вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : > Alexey, > > Is the approach when we cherry-pick fixes to the 2.8 only after all > fixes have verified in the master branch better? I just want to be > sure the release branch to be stable enough. > > On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev < > zaleslaw@gmail.com> wrote: > > > > Fixed both in release branch 2.8. Please verify and let me know > > > > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < > pilshchikov@gmail.com>: > > > > > And one more > > > https://issues.apache.org/jira/browse/IGNITE-12658 - > > > TutorialStepByStepExample example failed if cluster with more > then 1 node > > > > > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < > zaleslaw@gmail.com>: > > > > > >> Great, thank you so much, will fix next week > > >> > > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < > pilshchikov@gmail.com > > >> >: > > >> > > >>> Hi, Alexey, could you please looking on one small accident > happen in ML > > >>> examples: > > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 > examples exactly > > >>> the same. > > >>> > > >>> Also want to say that all previous examples have one common > approach for > > >>> meaningful output, like ">>> Something important". In this > two i seeing > > >>> different one, could you please also pay attention to it. > > >>> > > >>> Best regards, > > >>> Stepan > > >>> > > >> >
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
With mnist_tf_model in same directory All others looks right ср, 12 февр. 2020 г. в 16:21, Stepan Pilschikov : > Hmm, interesting, got it > Also found apache-ignite-2.8.0-bin/examples/src/main/resources/models/mleap > I think its also should be removed then > > ср, 12 февр. 2020 г. в 16:11, Alexey Zinoviev : > >> Please, have a look to the next ticket >> https://issues.apache.org/jira/browse/IGNITE-12659 >> Also tensorflow packages are blockers for IGFS deprecation and removal. >> >> ср, 12 февр. 2020 г. в 15:58, Alexey Zinoviev : >> >>> They are not lost, they are removed from release branch due to a lot of >>> bugs, cves and so on, don't worry about that. >>> >>> ср, 12 февр. 2020 г., 14:31 Stepan Pilschikov >> >: >>> Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow in libs/optional ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov < pilshchikov@gmail.com>: > But now have new problems > I build ignite-2.8 build on TC > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 > Previous > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 > > New build much lighter > Previous: 5.7 Gb > Current: 4.3 Gb > And its looks like something missing, on a first look i notice that > /libs/optional/ignite-ml-mleap-model-parser lost completely > > > ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov < > pilshchikov@gmail.com>: > >> Thanks for fix >> Duplicated examples deleted and tutorial works on real (1+ node) >> cluster now >> I think ticket can be closed, have no power here >> >> вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev > >: >> >>> Sorry, for that, but I it touches ML-related stuff only and doesn't >>> influence on any another module. >>> I merged them to master later (currently, I have a 4 tickets in a >>> queue). >>> >>> Will keep in mind for the next fixes >>> >>> вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : >>> Alexey, Is the approach when we cherry-pick fixes to the 2.8 only after all fixes have verified in the master branch better? I just want to be sure the release branch to be stable enough. On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev < zaleslaw@gmail.com> wrote: > > Fixed both in release branch 2.8. Please verify and let me know > > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < pilshchikov@gmail.com>: > > > And one more > > https://issues.apache.org/jira/browse/IGNITE-12658 - > > TutorialStepByStepExample example failed if cluster with more then 1 node > > > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < zaleslaw@gmail.com>: > > > >> Great, thank you so much, will fix next week > >> > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < pilshchikov@gmail.com > >> >: > >> > >>> Hi, Alexey, could you please looking on one small accident happen in ML > >>> examples: > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 examples exactly > >>> the same. > >>> > >>> Also want to say that all previous examples have one common approach for > >>> meaningful output, like ">>> Something important". In this two i seeing > >>> different one, could you please also pay attention to it. > >>> > >>> Best regards, > >>> Stepan > >>> > >> >>>
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
Hmm, interesting, got it Also found apache-ignite-2.8.0-bin/examples/src/main/resources/models/mleap I think its also should be removed then ср, 12 февр. 2020 г. в 16:11, Alexey Zinoviev : > Please, have a look to the next ticket > https://issues.apache.org/jira/browse/IGNITE-12659 > Also tensorflow packages are blockers for IGFS deprecation and removal. > > ср, 12 февр. 2020 г. в 15:58, Alexey Zinoviev : > >> They are not lost, they are removed from release branch due to a lot of >> bugs, cves and so on, don't worry about that. >> >> ср, 12 февр. 2020 г., 14:31 Stepan Pilschikov > >: >> >>> Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow in >>> libs/optional >>> >>> >>> ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov < >>> pilshchikov@gmail.com>: >>> But now have new problems I build ignite-2.8 build on TC https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 Previous https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 New build much lighter Previous: 5.7 Gb Current: 4.3 Gb And its looks like something missing, on a first look i notice that /libs/optional/ignite-ml-mleap-model-parser lost completely ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov < pilshchikov@gmail.com>: > Thanks for fix > Duplicated examples deleted and tutorial works on real (1+ node) > cluster now > I think ticket can be closed, have no power here > > вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev >: > >> Sorry, for that, but I it touches ML-related stuff only and doesn't >> influence on any another module. >> I merged them to master later (currently, I have a 4 tickets in a >> queue). >> >> Will keep in mind for the next fixes >> >> вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : >> >>> Alexey, >>> >>> Is the approach when we cherry-pick fixes to the 2.8 only after all >>> fixes have verified in the master branch better? I just want to be >>> sure the release branch to be stable enough. >>> >>> On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev < >>> zaleslaw@gmail.com> wrote: >>> > >>> > Fixed both in release branch 2.8. Please verify and let me know >>> > >>> > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < >>> pilshchikov@gmail.com>: >>> > >>> > > And one more >>> > > https://issues.apache.org/jira/browse/IGNITE-12658 - >>> > > TutorialStepByStepExample example failed if cluster with more >>> then 1 node >>> > > >>> > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < >>> zaleslaw@gmail.com>: >>> > > >>> > >> Great, thank you so much, will fix next week >>> > >> >>> > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < >>> pilshchikov@gmail.com >>> > >> >: >>> > >> >>> > >>> Hi, Alexey, could you please looking on one small accident >>> happen in ML >>> > >>> examples: >>> > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 >>> examples exactly >>> > >>> the same. >>> > >>> >>> > >>> Also want to say that all previous examples have one common >>> approach for >>> > >>> meaningful output, like ">>> Something important". In this two >>> i seeing >>> > >>> different one, could you please also pay attention to it. >>> > >>> >>> > >>> Best regards, >>> > >>> Stepan >>> > >>> >>> > >> >>> >>
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Alexey, Why do you think delaying of historical rebalance (on BLT node join) for particular cache groups is not the real world use case? Probably the same topic may be started on user-list to collect more use cases from real users. In general, I support reducing the number of available rebalance configuration parameters, but we should do it really carefully. I can also propose - rebalanceOrder param for removing. On Wed, 12 Feb 2020 at 15:50, Alexei Scherbakov wrote: > > Maxim, > > In general rebalanceDelay is used to delay/disable rebalance then topology > is changed. > Right now we have BLT to avoid unnecesary rebalancing when topology is > changed. > If a node left from cluster topology no rebalancing happens until the node > explicitly removed from baseline topology. > > I would like to know real world scenarios which can not be covered by BLT > configuration. > > > > ср, 12 февр. 2020 г. в 15:16, Maxim Muzafarov : > > > Alexey, > > > > > All scenarios where rebalanceDelay has meaning are handled by baseline > > topology now. > > > > Can you, please, provide more details here e.g. the whole list of > > scenarios where rebalanceDelay is used and how these handled by > > baseline topology? > > > > Actually, I doubt that it covers exactly all the cases due to > > rebalanceDelay is a "per cache group property" rather than "baseline" > > is meaningful for the whole topology. > > > > On Wed, 12 Feb 2020 at 12:58, Alexei Scherbakov > > wrote: > > > > > > I've meant baseline topology. > > > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < > > > alexey.scherbak...@gmail.com>: > > > > > > > > > > > V.Pyatkov > > > > > > > > Doesn't rebalance topology solves it ? > > > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov : > > > > > > > >> Hi, > > > >> > > > >> I am sure we can to reduce this ability, but do not completely. > > > >> We can use rebalance delay for disable it until manually triggered. > > > >> > > > >> CacheConfiguration#setRebalanceDelay(-1) > > > >> > > > >> It may helpful for cluster where can not allow performance drop from > > > >> rebalance at any time. > > > >> > > > >> > > > >> > > > >> -- > > > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > >> > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > Alexei Scherbakov > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > -- > > Best regards, > Alexei Scherbakov
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
Please, have a look to the next ticket https://issues.apache.org/jira/browse/IGNITE-12659 Also tensorflow packages are blockers for IGFS deprecation and removal. ср, 12 февр. 2020 г. в 15:58, Alexey Zinoviev : > They are not lost, they are removed from release branch due to a lot of > bugs, cves and so on, don't worry about that. > > ср, 12 февр. 2020 г., 14:31 Stepan Pilschikov : > >> Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow in >> libs/optional >> >> >> ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> >>> But now have new problems >>> I build ignite-2.8 build on TC >>> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 >>> Previous >>> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 >>> >>> New build much lighter >>> Previous: 5.7 Gb >>> Current: 4.3 Gb >>> And its looks like something missing, on a first look i notice that >>> /libs/optional/ignite-ml-mleap-model-parser lost completely >>> >>> >>> ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov < >>> pilshchikov@gmail.com>: >>> Thanks for fix Duplicated examples deleted and tutorial works on real (1+ node) cluster now I think ticket can be closed, have no power here вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev : > Sorry, for that, but I it touches ML-related stuff only and doesn't > influence on any another module. > I merged them to master later (currently, I have a 4 tickets in a > queue). > > Will keep in mind for the next fixes > > вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : > >> Alexey, >> >> Is the approach when we cherry-pick fixes to the 2.8 only after all >> fixes have verified in the master branch better? I just want to be >> sure the release branch to be stable enough. >> >> On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev >> wrote: >> > >> > Fixed both in release branch 2.8. Please verify and let me know >> > >> > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> > >> > > And one more >> > > https://issues.apache.org/jira/browse/IGNITE-12658 - >> > > TutorialStepByStepExample example failed if cluster with more >> then 1 node >> > > >> > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < >> zaleslaw@gmail.com>: >> > > >> > >> Great, thank you so much, will fix next week >> > >> >> > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < >> pilshchikov@gmail.com >> > >> >: >> > >> >> > >>> Hi, Alexey, could you please looking on one small accident >> happen in ML >> > >>> examples: >> > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 >> examples exactly >> > >>> the same. >> > >>> >> > >>> Also want to say that all previous examples have one common >> approach for >> > >>> meaningful output, like ">>> Something important". In this two >> i seeing >> > >>> different one, could you please also pay attention to it. >> > >>> >> > >>> Best regards, >> > >>> Stepan >> > >>> >> > >> >> >
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
They are not lost, they are removed from release branch due to a lot of bugs, cves and so on, don't worry about that. ср, 12 февр. 2020 г., 14:31 Stepan Pilschikov : > Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow in > libs/optional > > > ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov >: > >> But now have new problems >> I build ignite-2.8 build on TC >> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 >> Previous >> https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 >> >> New build much lighter >> Previous: 5.7 Gb >> Current: 4.3 Gb >> And its looks like something missing, on a first look i notice that >> /libs/optional/ignite-ml-mleap-model-parser lost completely >> >> >> ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> >>> Thanks for fix >>> Duplicated examples deleted and tutorial works on real (1+ node) cluster >>> now >>> I think ticket can be closed, have no power here >>> >>> вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev : >>> Sorry, for that, but I it touches ML-related stuff only and doesn't influence on any another module. I merged them to master later (currently, I have a 4 tickets in a queue). Will keep in mind for the next fixes вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : > Alexey, > > Is the approach when we cherry-pick fixes to the 2.8 only after all > fixes have verified in the master branch better? I just want to be > sure the release branch to be stable enough. > > On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev > wrote: > > > > Fixed both in release branch 2.8. Please verify and let me know > > > > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < > pilshchikov@gmail.com>: > > > > > And one more > > > https://issues.apache.org/jira/browse/IGNITE-12658 - > > > TutorialStepByStepExample example failed if cluster with more then > 1 node > > > > > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < > zaleslaw@gmail.com>: > > > > > >> Great, thank you so much, will fix next week > > >> > > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < > pilshchikov@gmail.com > > >> >: > > >> > > >>> Hi, Alexey, could you please looking on one small accident > happen in ML > > >>> examples: > > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 examples > exactly > > >>> the same. > > >>> > > >>> Also want to say that all previous examples have one common > approach for > > >>> meaningful output, like ">>> Something important". In this two i > seeing > > >>> different one, could you please also pay attention to it. > > >>> > > >>> Best regards, > > >>> Stepan > > >>> > > >> >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Maxim, In general rebalanceDelay is used to delay/disable rebalance then topology is changed. Right now we have BLT to avoid unnecesary rebalancing when topology is changed. If a node left from cluster topology no rebalancing happens until the node explicitly removed from baseline topology. I would like to know real world scenarios which can not be covered by BLT configuration. ср, 12 февр. 2020 г. в 15:16, Maxim Muzafarov : > Alexey, > > > All scenarios where rebalanceDelay has meaning are handled by baseline > topology now. > > Can you, please, provide more details here e.g. the whole list of > scenarios where rebalanceDelay is used and how these handled by > baseline topology? > > Actually, I doubt that it covers exactly all the cases due to > rebalanceDelay is a "per cache group property" rather than "baseline" > is meaningful for the whole topology. > > On Wed, 12 Feb 2020 at 12:58, Alexei Scherbakov > wrote: > > > > I've meant baseline topology. > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < > > alexey.scherbak...@gmail.com>: > > > > > > > > V.Pyatkov > > > > > > Doesn't rebalance topology solves it ? > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov : > > > > > >> Hi, > > >> > > >> I am sure we can to reduce this ability, but do not completely. > > >> We can use rebalance delay for disable it until manually triggered. > > >> > > >> CacheConfiguration#setRebalanceDelay(-1) > > >> > > >> It may helpful for cluster where can not allow performance drop from > > >> rebalance at any time. > > >> > > >> > > >> > > >> -- > > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > >> > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12668) Extend test coverage for plugin providers configuration
Andrey N. Gura created IGNITE-12668: --- Summary: Extend test coverage for plugin providers configuration Key: IGNITE-12668 URL: https://issues.apache.org/jira/browse/IGNITE-12668 Project: Ignite Issue Type: Improvement Reporter: Andrey N. Gura Assignee: Andrey N. Gura Fix For: 2.9 Tests related with plugin providers configuration change should be added (https://issues.apache.org/jira/browse/IGNITE-11744) -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Alexey, > All scenarios where rebalanceDelay has meaning are handled by baseline > topology now. Can you, please, provide more details here e.g. the whole list of scenarios where rebalanceDelay is used and how these handled by baseline topology? Actually, I doubt that it covers exactly all the cases due to rebalanceDelay is a "per cache group property" rather than "baseline" is meaningful for the whole topology. On Wed, 12 Feb 2020 at 12:58, Alexei Scherbakov wrote: > > I've meant baseline topology. > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > > > > > V.Pyatkov > > > > Doesn't rebalance topology solves it ? > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov : > > > >> Hi, > >> > >> I am sure we can to reduce this ability, but do not completely. > >> We can use rebalance delay for disable it until manually triggered. > >> > >> CacheConfiguration#setRebalanceDelay(-1) > >> > >> It may helpful for cluster where can not allow performance drop from > >> rebalance at any time. > >> > >> > >> > >> -- > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > >> > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > > > > -- > > Best regards, > Alexei Scherbakov
[jira] [Created] (IGNITE-12667) Falky test FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
Andrey N. Gura created IGNITE-12667:
---
Summary: Falky test
FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
Key: IGNITE-12667
URL: https://issues.apache.org/jira/browse/IGNITE-12667
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
Assignee: Andrey N. Gura
Fix For: 2.9
Test {{FailureProcessorThreadDumpThrottlingTest#testThrottlingPerFailureType}}
is flaky. On TC agents thread dumps generation takes a lot of time, so current
throttling timeout is too small for TC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
Also lost ignite-ml-tensorflow-model-parser and ignite-tensorflow in libs/optional ср, 12 февр. 2020 г. в 14:25, Stepan Pilschikov : > But now have new problems > I build ignite-2.8 build on TC > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 > Previous > https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 > > New build much lighter > Previous: 5.7 Gb > Current: 4.3 Gb > And its looks like something missing, on a first look i notice that > /libs/optional/ignite-ml-mleap-model-parser lost completely > > > ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov >: > >> Thanks for fix >> Duplicated examples deleted and tutorial works on real (1+ node) cluster >> now >> I think ticket can be closed, have no power here >> >> вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev : >> >>> Sorry, for that, but I it touches ML-related stuff only and doesn't >>> influence on any another module. >>> I merged them to master later (currently, I have a 4 tickets in a queue). >>> >>> Will keep in mind for the next fixes >>> >>> вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : >>> Alexey, Is the approach when we cherry-pick fixes to the 2.8 only after all fixes have verified in the master branch better? I just want to be sure the release branch to be stable enough. On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev wrote: > > Fixed both in release branch 2.8. Please verify and let me know > > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < pilshchikov@gmail.com>: > > > And one more > > https://issues.apache.org/jira/browse/IGNITE-12658 - > > TutorialStepByStepExample example failed if cluster with more then 1 node > > > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < zaleslaw@gmail.com>: > > > >> Great, thank you so much, will fix next week > >> > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < pilshchikov@gmail.com > >> >: > >> > >>> Hi, Alexey, could you please looking on one small accident happen in ML > >>> examples: > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 examples exactly > >>> the same. > >>> > >>> Also want to say that all previous examples have one common approach for > >>> meaningful output, like ">>> Something important". In this two i seeing > >>> different one, could you please also pay attention to it. > >>> > >>> Best regards, > >>> Stepan > >>> > >> >>>
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
But now have new problems I build ignite-2.8 build on TC https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/5043672 Previous https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/4988324 New build much lighter Previous: 5.7 Gb Current: 4.3 Gb And its looks like something missing, on a first look i notice that /libs/optional/ignite-ml-mleap-model-parser lost completely ср, 12 февр. 2020 г. в 14:18, Stepan Pilschikov : > Thanks for fix > Duplicated examples deleted and tutorial works on real (1+ node) cluster > now > I think ticket can be closed, have no power here > > вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev : > >> Sorry, for that, but I it touches ML-related stuff only and doesn't >> influence on any another module. >> I merged them to master later (currently, I have a 4 tickets in a queue). >> >> Will keep in mind for the next fixes >> >> вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : >> >>> Alexey, >>> >>> Is the approach when we cherry-pick fixes to the 2.8 only after all >>> fixes have verified in the master branch better? I just want to be >>> sure the release branch to be stable enough. >>> >>> On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev >>> wrote: >>> > >>> > Fixed both in release branch 2.8. Please verify and let me know >>> > >>> > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < >>> pilshchikov@gmail.com>: >>> > >>> > > And one more >>> > > https://issues.apache.org/jira/browse/IGNITE-12658 - >>> > > TutorialStepByStepExample example failed if cluster with more then 1 >>> node >>> > > >>> > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev < >>> zaleslaw@gmail.com>: >>> > > >>> > >> Great, thank you so much, will fix next week >>> > >> >>> > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < >>> pilshchikov@gmail.com >>> > >> >: >>> > >> >>> > >>> Hi, Alexey, could you please looking on one small accident happen >>> in ML >>> > >>> examples: >>> > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 examples >>> exactly >>> > >>> the same. >>> > >>> >>> > >>> Also want to say that all previous examples have one common >>> approach for >>> > >>> meaningful output, like ">>> Something important". In this two i >>> seeing >>> > >>> different one, could you please also pay attention to it. >>> > >>> >>> > >>> Best regards, >>> > >>> Stepan >>> > >>> >>> > >> >>> >>
[jira] [Created] (IGNITE-12666) Provide cluster performance profiling tool
Amelchev Nikita created IGNITE-12666: Summary: Provide cluster performance profiling tool Key: IGNITE-12666 URL: https://issues.apache.org/jira/browse/IGNITE-12666 Project: Ignite Issue Type: New Feature Reporter: Amelchev Nikita Assignee: Amelchev Nikita For now, Ignite has not build-in profiling tool for user's operations and internal processes. Such a tool will be able to collect performance statistics and create a human-readable report. It will help to analyze workload and to tune configuration and applications. Example of similar tools in other products: AWR [[1]|https://docs.oracle.com/cd/E11882_01/server.112/e41573/autostat.htm#PFGRF94176] [[2]|http://www.dba-oracle.com/t_sample_awr_report.htm] [[3]|http://expertoracle.com/2018/02/06/performance-tuning-basics-15-awr-report-analysis/] (Oracle) ; pgbadger [[4]|https://github.com/darold/pgbadger], pgmetrics [[5]|https://pgmetrics.io/docs/index.html#example], powa [[6]|https://powa.readthedocs.io/en/latest/] (PostgresSQL). Example of html report: [powa|https://powa.readthedocs.io/en/latest/]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: ML examples EvaluatorExample and MultipleMetricsExample looks the same
Thanks for fix Duplicated examples deleted and tutorial works on real (1+ node) cluster now I think ticket can be closed, have no power here вт, 11 февр. 2020 г. в 20:44, Alexey Zinoviev : > Sorry, for that, but I it touches ML-related stuff only and doesn't > influence on any another module. > I merged them to master later (currently, I have a 4 tickets in a queue). > > Will keep in mind for the next fixes > > вт, 11 февр. 2020 г. в 18:58, Maxim Muzafarov : > >> Alexey, >> >> Is the approach when we cherry-pick fixes to the 2.8 only after all >> fixes have verified in the master branch better? I just want to be >> sure the release branch to be stable enough. >> >> On Tue, 11 Feb 2020 at 18:36, Alexey Zinoviev >> wrote: >> > >> > Fixed both in release branch 2.8. Please verify and let me know >> > >> > вт, 11 февр. 2020 г. в 14:58, Stepan Pilschikov < >> pilshchikov@gmail.com>: >> > >> > > And one more >> > > https://issues.apache.org/jira/browse/IGNITE-12658 - >> > > TutorialStepByStepExample example failed if cluster with more then 1 >> node >> > > >> > > вт, 11 февр. 2020 г. в 11:52, Alexey Zinoviev > >: >> > > >> > >> Great, thank you so much, will fix next week >> > >> >> > >> вт, 11 февр. 2020 г., 11:39 Stepan Pilschikov < >> pilshchikov@gmail.com >> > >> >: >> > >> >> > >>> Hi, Alexey, could you please looking on one small accident happen >> in ML >> > >>> examples: >> > >>> https://issues.apache.org/jira/browse/IGNITE-12657 - 2 examples >> exactly >> > >>> the same. >> > >>> >> > >>> Also want to say that all previous examples have one common >> approach for >> > >>> meaningful output, like ">>> Something important". In this two i >> seeing >> > >>> different one, could you please also pay attention to it. >> > >>> >> > >>> Best regards, >> > >>> Stepan >> > >>> >> > >> >> >
[jira] [Created] (IGNITE-12665) SQL: Potential race on MapResult close.
Andrey Mashenkov created IGNITE-12665: - Summary: SQL: Potential race on MapResult close. Key: IGNITE-12665 URL: https://issues.apache.org/jira/browse/IGNITE-12665 Project: Ignite Issue Type: Task Components: sql Reporter: Andrey Mashenkov Fix For: 2.9 Seems, a race possible on MapQueryResult*s*.close() as this code can be called twice. Let's rewrite it make sure every map result is closed via MapQueryResult*s*.closeResult(int) method only. Then allow cleanup once all map results are closed. Then MapQueryResult*s*.allClosed() can be optimized as we always know number of map results and all map results are closed via MapQueryResult*s* instance. Seems, MepQueryExecutor.onQueryRequest0() has dead code. See "res.openResult(rs)" call when 'null' passed as argument. Start point is MapQueryResult.openResult(res). -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Allow or prohibit a joint use of @deprecated and @IgniteExperimental
-1 Prohibit. To me as a developer the situation when old but stable API is deprecated with only experimental (thus unstable/unfinished) alternative is very far from comfortable. And from outside folks it may look like as a sign of immature processes inside Ignite community (which is definitely not the case) and reduce overall users' impression. On Tue, Feb 11, 2020 at 2:20 PM Andrey Gura wrote: > -1 Prohibit > > On Mon, Feb 10, 2020 at 11:02 AM Alexey Goncharuk > wrote: > > > > Dear Apache Ignite community, > > > > We would like to conduct a formal vote on the subject of whether to allow > > or prohibit a joint existence of @deprecated annotation for an old API > > and @IgniteExperimental [1] for a new (replacement) API. The result of > this > > vote will be formalized as an Apache Ignite development rule to be used > in > > future. > > > > The discussion thread where you can address all non-vote messages is [2]. > > > > The votes are: > > *[+1 Allow]* Allow to deprecate the old APIs even when new APIs are > marked > > with @IgniteExperimental to explicitly notify users that an old APIs will > > be removed in the next major release AND new APIs are available. > > *[-1 Prohibit]* Never deprecate the old APIs unless the new APIs are > stable > > and released without @IgniteExperimental. The old APIs javadoc may be > > updated with a reference to new APIs to encourage users to evaluate new > > APIs. The deprecation and new API release may happen simultaneously if > the > > new API is not marked with @IgniteExperimental or the annotation is > removed > > in the same release. > > > > Neither of the choices prohibits deprecation of an API without a > > replacement if community decides so. > > > > The vote will hold for 72 hours and will end on February 13th 2020 08:00 > > UTC: > > > https://www.timeanddate.com/countdown/to?year=2020=2=13=8=0=0=utc-1 > > > > All votes count, there is no binding/non-binding status for this. > > > > [1] > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/lang/IgniteExperimental.java > > [2] > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Public-API-deprecation-rules-td45647.html > > > > Thanks, > > --AG >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
I've meant baseline topology. ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < alexey.scherbak...@gmail.com>: > > V.Pyatkov > > Doesn't rebalance topology solves it ? > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov : > >> Hi, >> >> I am sure we can to reduce this ability, but do not completely. >> We can use rebalance delay for disable it until manually triggered. >> >> CacheConfiguration#setRebalanceDelay(-1) >> >> It may helpful for cluster where can not allow performance drop from >> rebalance at any time. >> >> >> >> -- >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12664) Failed to dump debug information. Failed to create string representation of binary object.
Ivan Pavlukhin created IGNITE-12664:
---
Summary: Failed to dump debug information. Failed to create string
representation of binary object.
Key: IGNITE-12664
URL: https://issues.apache.org/jira/browse/IGNITE-12664
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
Fix For: 2.9
Logging long transactions warning fails:
{noformat}
Dec 12, 2019 12:18:09 PM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to dump debug information: class o.a.i.IgniteException: Failed
to create string representation of binary object.
class org.apache.ignite.IgniteException: Failed to create string representation
of binary object.
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1021)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:761)
Caused by: java.lang.ClassNotFoundException:
org.springframework.security.core.authority.SimpleGrantedAuthority
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
{noformat}
We are using replicated cache: Cache sessionsCache
where MapSession is:
{code}
public final class MapSession implements ExpiringSession, Serializable {
public static final int DEFAULT_MAX_INACTIVE_INTERVAL_SECONDS = 1800;
private String id;
private Map sessionAttrs;
private long creationTime;
private long lastAccessedTime;
private int maxInactiveInterval;
private static final long serialVersionUID = 7160779239673823561L;
{code}
and sessionAttrs contains SimpleGrantedAuthority.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
V.Pyatkov Doesn't rebalance topology solves it ? ср, 12 февр. 2020 г. в 12:31, V.Pyatkov : > Hi, > > I am sure we can to reduce this ability, but do not completely. > We can use rebalance delay for disable it until manually triggered. > > CacheConfiguration#setRebalanceDelay(-1) > > It may helpful for cluster where can not allow performance drop from > rebalance at any time. > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > -- Best regards, Alexei Scherbakov
Re[4]: [DISCUSSION] Deprecation of obsolete rebalancing functionality
How can i understand it from documentation ? If Ignite persistence is enabled, Ignite enforces the baseline topology concept which represents a set of server nodes in the cluster that will persist data on disk. >No, baseline is supported for im-memory caches as well. > >ср, 12 февр. 2020 г. в 12:18, Zhenya Stanilovsky < arzamas...@mail.ru.invalid >>: > >> >> >> But baseline, it`s about persistence [1] isn`t it? I wrote about >> pure inmemory case. >> >> [1] https://apacheignite.readme.io/docs/baseline-topology >> >Vyacheslav, Evgeny, >> > >> >All scenarios where rebalanceDelay has meaning are handled by baseline >> >topology now. >> > >> >ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov < >> > alexey.scherbak...@gmail.com >: >> > >> >> Sergey, >> >> >> >> The ticket looks outdated. >> >> In fact this is already implemented. >> >> >> >> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev < >> sergey-a.kosa...@db.com >: >> >> >> >>> Classification: Public >> >>> >> >>> Hi, Alexey. >> >>> I believe it can't be done until in-memory caches will use baseline >> >>> topology [1]. >> >>> In our case we are using rebalanceDelay for in-memory caches. >> >>> >> >>> [1] https://issues.apache.org/jira/browse/IGNITE-8414 >> >>> >> >>> >> >>> Kind regards, >> >>> Sergey Kosarev >> >>> >> >>> -Original Message- >> >>> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] >> >>> Sent: 12 February 2020 11:33 >> >>> To: dev@ignite.apache.org >> >>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing >> >>> functionality >> >>> >> >>> >> >>> >> >>> I know guys who use this setting (may be erroneously) = MAX_INT for >> real >> >>> rebalance delaying (very small sla) grid without persistence. But i >> don`t >> >>> know further algo, may be if backup nodes become extremely small they >> >>> creates the same cluster near it. Can ignite simple disable rebalance? >> >>> >> >>> >Folks, >> >>> > >> >>> >I want to deprecate some obsolete functionality related to >> rebalancing. >> >>> >Details in [1] >> >>> > >> >>> >Any objections ? >> >>> > >> >>> >[1] https://issues.apache.org/jira/browse/IGNITE-12662 >> >>> > >> >>> >-- >> >>> > >> >>> >Best regards, >> >>> >Alexei Scherbakov >> >>> > >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> --- >> >>> This e-mail may contain confidential and/or privileged information. If >> >>> you are not the intended recipient (or have received this e-mail in >> error) >> >>> please notify the sender immediately and delete this e-mail. Any >> >>> unauthorized copying, disclosure or distribution of the material in >> this >> >>> e-mail is strictly forbidden. >> >>> >> >>> Please refer to https://www.db.com/disclosures for additional EU >> >>> corporate and regulatory disclosures and to >> >>> http://www.db.com/unitedkingdom/content/privacy.htm for information >> >>> about privacy. >> >>> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Alexei Scherbakov >> >> >> > >> >-- >> > >> >Best regards, >> >Alexei Scherbakov >> > >> >> >> >> > > > >-- > >Best regards, >Alexei Scherbakov >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Hi, I am sure we can to reduce this ability, but do not completely. We can use rebalance delay for disable it until manually triggered. CacheConfiguration#setRebalanceDelay(-1) It may helpful for cluster where can not allow performance drop from rebalance at any time. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Re[2]: [DISCUSSION] Deprecation of obsolete rebalancing functionality
No, baseline is supported for im-memory caches as well. ср, 12 февр. 2020 г. в 12:18, Zhenya Stanilovsky : > > > But baseline, it`s about persistence [1] isn`t it? I wrote about > pure inmemory case. > > [1] https://apacheignite.readme.io/docs/baseline-topology > >Vyacheslav, Evgeny, > > > >All scenarios where rebalanceDelay has meaning are handled by baseline > >topology now. > > > >ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov < > >alexey.scherbak...@gmail.com >: > > > >> Sergey, > >> > >> The ticket looks outdated. > >> In fact this is already implemented. > >> > >> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev < > sergey-a.kosa...@db.com >: > >> > >>> Classification: Public > >>> > >>> Hi, Alexey. > >>> I believe it can't be done until in-memory caches will use baseline > >>> topology [1]. > >>> In our case we are using rebalanceDelay for in-memory caches. > >>> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-8414 > >>> > >>> > >>> Kind regards, > >>> Sergey Kosarev > >>> > >>> -Original Message- > >>> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] > >>> Sent: 12 February 2020 11:33 > >>> To: dev@ignite.apache.org > >>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing > >>> functionality > >>> > >>> > >>> > >>> I know guys who use this setting (may be erroneously) = MAX_INT for > real > >>> rebalance delaying (very small sla) grid without persistence. But i > don`t > >>> know further algo, may be if backup nodes become extremely small they > >>> creates the same cluster near it. Can ignite simple disable rebalance? > >>> > >>> >Folks, > >>> > > >>> >I want to deprecate some obsolete functionality related to > rebalancing. > >>> >Details in [1] > >>> > > >>> >Any objections ? > >>> > > >>> >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > >>> > > >>> >-- > >>> > > >>> >Best regards, > >>> >Alexei Scherbakov > >>> > > >>> > >>> > >>> > >>> > >>> > >>> > >>> --- > >>> This e-mail may contain confidential and/or privileged information. If > >>> you are not the intended recipient (or have received this e-mail in > error) > >>> please notify the sender immediately and delete this e-mail. Any > >>> unauthorized copying, disclosure or distribution of the material in > this > >>> e-mail is strictly forbidden. > >>> > >>> Please refer to https://www.db.com/disclosures for additional EU > >>> corporate and regulatory disclosures and to > >>> http://www.db.com/unitedkingdom/content/privacy.htm for information > >>> about privacy. > >>> > >> > >> > >> -- > >> > >> Best regards, > >> Alexei Scherbakov > >> > > > >-- > > > >Best regards, > >Alexei Scherbakov > > > > > > -- Best regards, Alexei Scherbakov
Re[2]: [DISCUSSION] Deprecation of obsolete rebalancing functionality
But baseline, it`s about persistence [1] isn`t it? I wrote about pure inmemory case. [1] https://apacheignite.readme.io/docs/baseline-topology >Vyacheslav, Evgeny, > >All scenarios where rebalanceDelay has meaning are handled by baseline >topology now. > >ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov < >alexey.scherbak...@gmail.com >: > >> Sergey, >> >> The ticket looks outdated. >> In fact this is already implemented. >> >> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev < sergey-a.kosa...@db.com >: >> >>> Classification: Public >>> >>> Hi, Alexey. >>> I believe it can't be done until in-memory caches will use baseline >>> topology [1]. >>> In our case we are using rebalanceDelay for in-memory caches. >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-8414 >>> >>> >>> Kind regards, >>> Sergey Kosarev >>> >>> -Original Message- >>> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] >>> Sent: 12 February 2020 11:33 >>> To: dev@ignite.apache.org >>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing >>> functionality >>> >>> >>> >>> I know guys who use this setting (may be erroneously) = MAX_INT for real >>> rebalance delaying (very small sla) grid without persistence. But i don`t >>> know further algo, may be if backup nodes become extremely small they >>> creates the same cluster near it. Can ignite simple disable rebalance? >>> >>> >Folks, >>> > >>> >I want to deprecate some obsolete functionality related to rebalancing. >>> >Details in [1] >>> > >>> >Any objections ? >>> > >>> >[1] https://issues.apache.org/jira/browse/IGNITE-12662 >>> > >>> >-- >>> > >>> >Best regards, >>> >Alexei Scherbakov >>> > >>> >>> >>> >>> >>> >>> >>> --- >>> This e-mail may contain confidential and/or privileged information. If >>> you are not the intended recipient (or have received this e-mail in error) >>> please notify the sender immediately and delete this e-mail. Any >>> unauthorized copying, disclosure or distribution of the material in this >>> e-mail is strictly forbidden. >>> >>> Please refer to https://www.db.com/disclosures for additional EU >>> corporate and regulatory disclosures and to >>> http://www.db.com/unitedkingdom/content/privacy.htm for information >>> about privacy. >>> >> >> >> -- >> >> Best regards, >> Alexei Scherbakov >> > >-- > >Best regards, >Alexei Scherbakov >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Vyacheslav, Evgeny, All scenarios where rebalanceDelay has meaning are handled by baseline topology now. ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov < alexey.scherbak...@gmail.com>: > Sergey, > > The ticket looks outdated. > In fact this is already implemented. > > ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev : > >> Classification: Public >> >> Hi, Alexey. >> I believe it can't be done until in-memory caches will use baseline >> topology [1]. >> In our case we are using rebalanceDelay for in-memory caches. >> >> [1] https://issues.apache.org/jira/browse/IGNITE-8414 >> >> >> Kind regards, >> Sergey Kosarev >> >> -Original Message- >> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] >> Sent: 12 February 2020 11:33 >> To: dev@ignite.apache.org >> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing >> functionality >> >> >> >> I know guys who use this setting (may be erroneously) = MAX_INT for real >> rebalance delaying (very small sla) grid without persistence. But i don`t >> know further algo, may be if backup nodes become extremely small they >> creates the same cluster near it. Can ignite simple disable rebalance? >> >> >Folks, >> > >> >I want to deprecate some obsolete functionality related to rebalancing. >> >Details in [1] >> > >> >Any objections ? >> > >> >[1] https://issues.apache.org/jira/browse/IGNITE-12662 >> > >> >-- >> > >> >Best regards, >> >Alexei Scherbakov >> > >> >> >> >> >> >> >> --- >> This e-mail may contain confidential and/or privileged information. If >> you are not the intended recipient (or have received this e-mail in error) >> please notify the sender immediately and delete this e-mail. Any >> unauthorized copying, disclosure or distribution of the material in this >> e-mail is strictly forbidden. >> >> Please refer to https://www.db.com/disclosures for additional EU >> corporate and regulatory disclosures and to >> http://www.db.com/unitedkingdom/content/privacy.htm for information >> about privacy. >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
RE: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Classification: Public Alexey, then I don't have objections. -Original Message- From: Alexei Scherbakov [mailto:alexey.scherbak...@gmail.com] Sent: 12 February 2020 12:01 To: dev Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality Sergey, The ticket looks outdated. In fact this is already implemented. ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev : > Classification: Public > > Hi, Alexey. > I believe it can't be done until in-memory caches will use baseline > topology [1]. > In our case we are using rebalanceDelay for in-memory caches. > > [1] https://issues.apache.org/jira/browse/IGNITE-8414 > > > Kind regards, > Sergey Kosarev > > -Original Message- > From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] > Sent: 12 February 2020 11:33 > To: dev@ignite.apache.org > Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing > functionality > > > > I know guys who use this setting (may be erroneously) = MAX_INT for > real rebalance delaying (very small sla) grid without persistence. But > i don`t know further algo, may be if backup nodes become extremely > small they creates the same cluster near it. Can ignite simple disable > rebalance? > > >Folks, > > > >I want to deprecate some obsolete functionality related to rebalancing. > >Details in [1] > > > >Any objections ? > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > > > >-- > > > >Best regards, > >Alexei Scherbakov > > > > > > > > > --- > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. > Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information > about privacy. > -- Best regards, Alexei Scherbakov --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
[jira] [Created] (IGNITE-12663) Let's limit all thread pools' sizes to 3 in tests
Ilya Kasnacheev created IGNITE-12663: Summary: Let's limit all thread pools' sizes to 3 in tests Key: IGNITE-12663 URL: https://issues.apache.org/jira/browse/IGNITE-12663 Project: Ignite Issue Type: Test Reporter: Ilya Kasnacheev The rationale is, it is very painful shoving through thread dumps of test with N CPU threads in every pool. Why 3? It should allow all kinds of race conditions to still happen. Of course, we should allow specific tests to override this value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Sergey, The ticket looks outdated. In fact this is already implemented. ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev : > Classification: Public > > Hi, Alexey. > I believe it can't be done until in-memory caches will use baseline > topology [1]. > In our case we are using rebalanceDelay for in-memory caches. > > [1] https://issues.apache.org/jira/browse/IGNITE-8414 > > > Kind regards, > Sergey Kosarev > > -Original Message- > From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] > Sent: 12 February 2020 11:33 > To: dev@ignite.apache.org > Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality > > > > I know guys who use this setting (may be erroneously) = MAX_INT for real > rebalance delaying (very small sla) grid without persistence. But i don`t > know further algo, may be if backup nodes become extremely small they > creates the same cluster near it. Can ignite simple disable rebalance? > > >Folks, > > > >I want to deprecate some obsolete functionality related to rebalancing. > >Details in [1] > > > >Any objections ? > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > > > >-- > > > >Best regards, > >Alexei Scherbakov > > > > > > > > > --- > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information about > privacy. > -- Best regards, Alexei Scherbakov
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Hi, Alexei! CacheConfiguration#getRebalanceDelay was extremely useful for the caches backed by @CacheLocalStore to prevent rebalancing during full cluster startup/shutdown. But @CacheLocalStore annotation is deprecated also. I think "rebalancing delay" stuff might be useful for replicated cached to have a gap for administrators to switch load for example. On Wed, Feb 12, 2020 at 11:33 AM Zhenya Stanilovsky wrote: > > > > I know guys who use this setting (may be erroneously) = MAX_INT for real > rebalance delaying (very small sla) grid without persistence. But i don`t > know further algo, may be if backup nodes become extremely small they > creates the same cluster near it. Can ignite simple disable rebalance? > > >Folks, > > > >I want to deprecate some obsolete functionality related to rebalancing. > >Details in [1] > > > >Any objections ? > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > > > >-- > > > >Best regards, > >Alexei Scherbakov > > > > > > -- Best Regards, Vyacheslav D.
RE: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Classification: Public Hi, Alexey. I believe it can't be done until in-memory caches will use baseline topology [1]. In our case we are using rebalanceDelay for in-memory caches. [1] https://issues.apache.org/jira/browse/IGNITE-8414 Kind regards, Sergey Kosarev -Original Message- From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID] Sent: 12 February 2020 11:33 To: dev@ignite.apache.org Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality I know guys who use this setting (may be erroneously) = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes become extremely small they creates the same cluster near it. Can ignite simple disable rebalance? >Folks, > >I want to deprecate some obsolete functionality related to rebalancing. >Details in [1] > >Any objections ? > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > >-- > >Best regards, >Alexei Scherbakov > --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
I know guys who use this setting (may be erroneously) = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes become extremely small they creates the same cluster near it. Can ignite simple disable rebalance? >Folks, > >I want to deprecate some obsolete functionality related to rebalancing. >Details in [1] > >Any objections ? > >[1] https://issues.apache.org/jira/browse/IGNITE-12662 > >-- > >Best regards, >Alexei Scherbakov >
[DISCUSSION] Deprecation of obsolete rebalancing functionality
Folks, I want to deprecate some obsolete functionality related to rebalancing. Details in [1] Any objections ? [1] https://issues.apache.org/jira/browse/IGNITE-12662 -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12662) Get rid of CacheConfiguration#getRebalanceDelay and related functionality.
Alexey Scherbakov created IGNITE-12662: -- Summary: Get rid of CacheConfiguration#getRebalanceDelay and related functionality. Key: IGNITE-12662 URL: https://issues.apache.org/jira/browse/IGNITE-12662 Project: Ignite Issue Type: Improvement Reporter: Alexey Scherbakov Fix For: 2.9 We have for a long time this property to mitigate case with premature rebalancing on node restart. Currently this is handled by baseline topology. I suggest to deprecate and remove related functionality in next releases. For example org.apache.ignite.IgniteCache#rebalance is no longer needed as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
