Re: Re[4]: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)
Hi Yuriy, Just would like to realize current state. Are you still working on Ignite text queries? If not, are you going to continue with it? пт, 13 дек. 2019 г. в 11:52, Ivan Pavlukhin : > > Yuriy, > > Sure, I will be glad to help. > > > - incorrect nodes/partition selection during querying? > Apparently this is the problem. If you feel it really complicated to > understand and debug then I can dig deeper and share my vision how the > problem can be fixed. > > ср, 11 дек. 2019 г. в 18:46, Yuriy Shuliga : > > > > I will look to the MOVING partition issue. > > But also need a guidance there. > > > > Ivan, don't you mind to be that person? > > > > The question is whether we have an issue with: > > - wrong storing targets during indexing OR > > - incorrect nodes/partition selection during querying? > > > > BR, > > Yuriy Shluiha > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
Re: Internal classes are exposed in public API
>> Also I agree with Alexey about introducing public IgniteMonitoring facade > This is not an issue with the API. > Just the new feature that doesn’t affects API. I disagree. It's part of API and it affects user experience. > Moreover, I create a ticket to fix it, already. Creating an issue does not solve the problem. >> Absence of newly created metrics in old MBeans that forces user use >> exporter SPI while his code base uses old MBeans. > Why this is issue? Because it is user experience. As I wrote already user must configure additional SPI in order to gt just a couple of numbers. It is not good idea from point of view. >> Inconsistent MetricRegistry API. > It’s consistent. I described concrete problems with API consistency early in this thread. Jus saying "it's consistent" doesn't make it consistent. >> Metrics lookups from map instead of using direct reference >> (performance problem). > 1. We(You and I) did this choice together to simplify creation of the new > metrics. No. I pointed to this problem. > 2. This is not public API issue. But this is issue. >> Ignoring of statisticsEnabled flag. > I don’t ignore this flag. But flag's value is ignored. > It just doesn’t exists in new framework(because of scope). I don't understand how this scope was formulated. There is some feature. It didn't removed. So it should be taken into account during adding new functionality if it affected. > I don’t think it’s an issue. It's just opinion. Form my point of view it is bug. >> JmxExporterSpi creates beans that doesn't satisfy best MBeans practices. > Please, clarify your statement. > What is best MBeans practices you are talking about? Again. I provided link to the article about it early in this thread. >> Not finished IGNITE-11927 > How this can be API issue? As I wrote early in this thread (may be twice) it changes the API significantly. On Fri, Jan 17, 2020 at 9:24 PM Николай Ижиков wrote: > > > Also I agree with Alexey about introducing public IgniteMonitoring facade > > This is not an issue with the API. > Just the new feature that doesn’t affects API. > Moreover, I create a ticket to fix it, already. > > > It's right. But if you add checking of statisticsEnabling property then > > test will fail. It's just not good tests. > > My changes doesn’t affect any `staticticsEnabled` property. > I don’ understand your point here. > > > Redundant ReadOnlyMetricRegistry. > > It’s not redundant. > It required for exporters and provide read only access to MetricRegistry > existing in the node. > > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > Absence of newly created metrics in old MBeans that forces user use > > exporter SPI while his code base uses old MBeans. > > Why this is issue? > > > Inconsistent MetricRegistry API. > > It’s consistent. > > > Metrics lookups from map instead of using direct reference > > (performance problem). > > 1. We(You and I) did this choice together to simplify creation of the new > metrics. > 2. This is not public API issue. > > > > Ignoring of statisticsEnabled flag. > > I don’t ignore this flag. > It just doesn’t exists in new framework(because of scope). > I don’t think it’s an issue. > > > JmxExporterSpi creates beans that doesn't satisfy best MBeans practices. > > Please, clarify your statement. > What is best MBeans practices you are talking about? > > > Not finished IGNITE-11927 > > > How this can be API issue? > > > > 17 янв. 2020 г., в 20:52, Andrey Gura написал(а): > > > >>> All issues Alexey mentioned in starting letter are fixed with my PR [1]. > >>> I don’t think other issues you mentioned are blocker for the release. > > > > As I mentioned already IGNITE-11927 is part of IEP-35 and > > implementation seriously affects API's. Also I agree with Alexey about > > introducing public IgniteMonitoring facade. So thiss PR doesn't fix > > all issues. > > > >>> I talk about ignored existing functionality. > >> There is no existing tests that was broken by this contribution. > > > > It's right. But if you add checking of statisticsEnabling property > > then test will fail. It's just not good tests. > > > >> If you know the issues with it, feel free to create a ticket I will fix it > >> ASAP. > > > > I already fix it all in IGNITE-11927 > > > >>> 1. Moving IEP-35 API's to the internal package. > >> We should move the product forward and shouldn't hide major contribution > >> from the user just because your second guess «I don’t like the API I just > >> reviewed and approved». > > > > We should move the product forward with with really finished features, > > not pieces of features. > > > >> So I am against this proposal. > > > > It is not argument. > > > >> But, I’m ready to see your proposal for the API change and discuss them. > > > > We can prepare it together. But we can't block release. > > > >>> Because IGNITE-11927 doesn't solve all problems > >> What is *ALL* problems? > > > > Redundant ReadOnlyMetricRegistry. > >
Re: Master compilation error
Will fix the compilation shortly, apologies for not checking locally. An additional compilation attempt is a good idea, but: first, I believe, there is still an option to merge a PR directly to apache git, second - when running a check, we need to make sure that master gets fast-forwarded exactly to the revision that was checked (though, it will help to avoid a lot of concurrent merge failures). I have no enough experience with Github, so I am not sure if this is possible. пн, 20 янв. 2020 г. в 14:40, Anton Vinogradov : > Also, is it possible to perform the same check on the merge attempt? > > Each PR can be merged from GitHub page, can we append check to the "megre > button" flow? > Can we restrict merges bypassing this button? > > On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov wrote: > > > Should we perform an additional compilation attempt on pull/xxx/merge at > > each visa request? > > > > On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn > > wrote: > > > >> > Main question is "how this may happen in case fix got the Visa [2] ?". > >> This can happen because of other changes in master. > >> "Visa" truly works only when master is in the same state during the > merge > >> as it was during TC run. > >> > >> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov wrote: > >> > >> > It seems, this because of IGNITE-12227 fix [1]. > >> > Main question is "how this may happen in case fix got the Visa [2] ?". > >> > > >> > [1] > >> > > >> > > >> > https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles > >> > [2] > >> > > >> > > >> > https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 > >> > > >> > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков > >> > wrote: > >> > > >> > > Hello. Igniters. > >> > > > >> > > Master build fails: > >> > > > >> > > > >> > > > >> > > >> > https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead > >> > > > >> > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal > >> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > >> > > (default-testCompile) on project ignite-core: Compilation failure: > >> > > Compilation failure: > >> > > [13:37:02][Step 3/4] [ERROR] > >> > > > >> > > >> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] > >> > > cannot find symbol > >> > > [13:37:02][Step 3/4] [ERROR] symbol: static > >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >> > > [13:37:02][Step 3/4] [ERROR] location: class > >> > > [13:37:02][Step 3/4] [ERROR] > >> > > > >> > > >> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] > >> > > cannot find symbol > >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable > >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >> > > [13:37:02][Step 3/4] [ERROR] location: class > >> > > > >> > > >> > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest > >> > > [13:37:02][Step 3/4] [ERROR] > >> > > > >> > > >> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] > >> > > cannot find symbol > >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable > >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >> > > [13:37:02][Step 3/4] [ERROR] location: class > >> > > > >> > > >> > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > >> > > [13:37:02][Step 3/4] [ERROR] > >> > > > >> > > >> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] > >> > > cannot find symbol > >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable > >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >> > > [13:37:02][Step 3/4] [ERROR] location: class > >> > > > >> > > >> > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > >> > > > >> > > > >> > > >> > > >
Re: JAVADOC fails on local build. Should it be checked on TC?
Maxim, >From the first glance it seems that "javadoc" profile was really missed. Are there any other problems except springdata22? If no then we can add the profile. Also it is interesting how it influence on execution time? пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov : > > Igniters, > > > I've run locally maven command according to DEVNOTES: > > mvn initialize -Pjavadoc > > and it fails due to: 'Other Packages' section should not be present, > all packages should have corresponding documentation groups. The > reason of that is a newly added `org.apache.ignite.springdata22` > package [1] is missing in maven-javadoc-plugin configuration [2]. > > > We have Javadoc Suite [3] but it not checks such issues due to > `javadoc` maven profile required to be enabled. > Should we enable `javadoc` profile for this suite? > Any other thoughts? > > [1] https://issues.apache.org/jira/browse/IGNITE-12259 > [2] https://issues.apache.org/jira/browse/IGNITE-12528 > [3] > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv -- Best regards, Ivan Pavlukhin
Re: Internal classes are exposed in public API
> However, we should do this only when the new APIs are production-ready. Denis, the problem is in understanding what does it mean "production ready". Obviously we have different understanding of this term. > What if release the improvements labeling as EA instead of hiding them completely? It's like RC. Usually GA release follows and it must have stable API. > I would also encourage us to put aside emotions, don't blame or point fingers All my finger points are related with API not with person. On Fri, Jan 17, 2020 at 11:00 PM Denis Magda wrote: > > Folks, if you don't mind I'll share some thoughts/suggestions as an > observer who was not involved in the feature development. > > It's absolutely 'ok' to deprecate an API that is replaced with a much > better version. However, we should do this only when the new APIs are > production-ready. If there are still many limitations or open items then > don't deprecate anything that exists and release the new APIs labeling as > early access. What if release the improvements labeling as EA instead of > hiding them completely? > > I would also encourage us to put aside emotions, don't blame or point > fingers. This IEP is a great initiative and you both have already done a > tremendous job by developing, architecting and reviewing changes. Just be > respectful. Nobody is trying to block the feature from being released. > Everyone would be glad to tap into improvements and start using them in > prod. But if more time is needed for the GA let's reiterate a bit. > > - > Denis > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков wrote: > > > > Also I agree with Alexey about introducing public IgniteMonitoring facade > > > > This is not an issue with the API. > > Just the new feature that doesn’t affects API. > > Moreover, I create a ticket to fix it, already. > > > > > It's right. But if you add checking of statisticsEnabling property then > > test will fail. It's just not good tests. > > > > My changes doesn’t affect any `staticticsEnabled` property. > > I don’ understand your point here. > > > > > Redundant ReadOnlyMetricRegistry. > > > > It’s not redundant. > > It required for exporters and provide read only access to MetricRegistry > > existing in the node. > > > > > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > > > Absence of newly created metrics in old MBeans that forces user use > > > exporter SPI while his code base uses old MBeans. > > > > Why this is issue? > > > > > Inconsistent MetricRegistry API. > > > > It’s consistent. > > > > > Metrics lookups from map instead of using direct reference > > > (performance problem). > > > > 1. We(You and I) did this choice together to simplify creation of the new > > metrics. > > 2. This is not public API issue. > > > > > > > Ignoring of statisticsEnabled flag. > > > > I don’t ignore this flag. > > It just doesn’t exists in new framework(because of scope). > > I don’t think it’s an issue. > > > > > JmxExporterSpi creates beans that doesn't satisfy best MBeans practices. > > > > Please, clarify your statement. > > What is best MBeans practices you are talking about? > > > > > Not finished IGNITE-11927 > > > > > > How this can be API issue? > > > > > > > 17 янв. 2020 г., в 20:52, Andrey Gura написал(а): > > > > > >>> All issues Alexey mentioned in starting letter are fixed with my PR > > [1]. > > >>> I don’t think other issues you mentioned are blocker for the release. > > > > > > As I mentioned already IGNITE-11927 is part of IEP-35 and > > > implementation seriously affects API's. Also I agree with Alexey about > > > introducing public IgniteMonitoring facade. So thiss PR doesn't fix > > > all issues. > > > > > >>> I talk about ignored existing functionality. > > >> There is no existing tests that was broken by this contribution. > > > > > > It's right. But if you add checking of statisticsEnabling property > > > then test will fail. It's just not good tests. > > > > > >> If you know the issues with it, feel free to create a ticket I will fix > > it ASAP. > > > > > > I already fix it all in IGNITE-11927 > > > > > >>> 1. Moving IEP-35 API's to the internal package. > > >> We should move the product forward and shouldn't hide major > > contribution from the user just because your second guess «I don’t like the > > API I just reviewed and approved». > > > > > > We should move the product forward with with really finished features, > > > not pieces of features. > > > > > >> So I am against this proposal. > > > > > > It is not argument. > > > > > >> But, I’m ready to see your proposal for the API change and discuss them. > > > > > > We can prepare it together. But we can't block release. > > > > > >>> Because IGNITE-11927 doesn't solve all problems > > >> What is *ALL* problems? > > > > > > Redundant ReadOnlyMetricRegistry. > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > Absence of newly created metrics in old MBeans that forces user use > > > exporter SPI while his code base
Re: Master compilation error
Also, is it possible to perform the same check on the merge attempt? Each PR can be merged from GitHub page, can we append check to the "megre button" flow? Can we restrict merges bypassing this button? On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov wrote: > Should we perform an additional compilation attempt on pull/xxx/merge at > each visa request? > > On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn > wrote: > >> > Main question is "how this may happen in case fix got the Visa [2] ?". >> This can happen because of other changes in master. >> "Visa" truly works only when master is in the same state during the merge >> as it was during TC run. >> >> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov wrote: >> >> > It seems, this because of IGNITE-12227 fix [1]. >> > Main question is "how this may happen in case fix got the Visa [2] ?". >> > >> > [1] >> > >> > >> https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles >> > [2] >> > >> > >> https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 >> > >> > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков >> > wrote: >> > >> > > Hello. Igniters. >> > > >> > > Master build fails: >> > > >> > > >> > > >> > >> https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead >> > > >> > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal >> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile >> > > (default-testCompile) on project ignite-core: Compilation failure: >> > > Compilation failure: >> > > [13:37:02][Step 3/4] [ERROR] >> > > >> > >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] >> > > cannot find symbol >> > > [13:37:02][Step 3/4] [ERROR] symbol: static >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> > > [13:37:02][Step 3/4] [ERROR] location: class >> > > [13:37:02][Step 3/4] [ERROR] >> > > >> > >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] >> > > cannot find symbol >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> > > [13:37:02][Step 3/4] [ERROR] location: class >> > > >> > >> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest >> > > [13:37:02][Step 3/4] [ERROR] >> > > >> > >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] >> > > cannot find symbol >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> > > [13:37:02][Step 3/4] [ERROR] location: class >> > > >> > >> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest >> > > [13:37:02][Step 3/4] [ERROR] >> > > >> > >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] >> > > cannot find symbol >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> > > [13:37:02][Step 3/4] [ERROR] location: class >> > > >> > >> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest >> > > >> > > >> > >> >
[MTCGA]: new failures in builds [4944094] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master ~Build Apache Ignite~ https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite?branch=%3Cdefault%3E Changes may lead to failure were done by - anton kalashnikov https://ci.ignite.apache.org/viewModification.html?modId=895719 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 14:56:18 20-01-2020
Re: Master compilation error
Should we perform an additional compilation attempt on pull/xxx/merge at each visa request? On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn wrote: > > Main question is "how this may happen in case fix got the Visa [2] ?". > This can happen because of other changes in master. > "Visa" truly works only when master is in the same state during the merge > as it was during TC run. > > On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov wrote: > > > It seems, this because of IGNITE-12227 fix [1]. > > Main question is "how this may happen in case fix got the Visa [2] ?". > > > > [1] > > > > > https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles > > [2] > > > > > https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 > > > > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков > > wrote: > > > > > Hello. Igniters. > > > > > > Master build fails: > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead > > > > > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal > > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > > > (default-testCompile) on project ignite-core: Compilation failure: > > > Compilation failure: > > > [13:37:02][Step 3/4] [ERROR] > > > > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] > > > cannot find symbol > > > [13:37:02][Step 3/4] [ERROR] symbol: static > > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > > [13:37:02][Step 3/4] [ERROR] location: class > > > [13:37:02][Step 3/4] [ERROR] > > > > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] > > > cannot find symbol > > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > > [13:37:02][Step 3/4] [ERROR] location: class > > > > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest > > > [13:37:02][Step 3/4] [ERROR] > > > > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] > > > cannot find symbol > > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > > [13:37:02][Step 3/4] [ERROR] location: class > > > > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > > > [13:37:02][Step 3/4] [ERROR] > > > > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] > > > cannot find symbol > > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > > [13:37:02][Step 3/4] [ERROR] location: class > > > > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > > > > > > > > >
Re: Internal classes are exposed in public API
After giving it some thought, I agree with Denis - there is nothing wrong with exposing the new APIs, we just need to make it clear that we are still going to change it. Should we Introduce something like @IgniteExperimental annotation (I believe it has been discussed a dozen of times on the dev-list)? пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > +1 to mark feature or whole release as EA. > > пт, 17 янв. 2020 г., 23:00 Denis Magda : > > > Folks, if you don't mind I'll share some thoughts/suggestions as an > > observer who was not involved in the feature development. > > > > It's absolutely 'ok' to deprecate an API that is replaced with a much > > better version. However, we should do this only when the new APIs are > > production-ready. If there are still many limitations or open items then > > don't deprecate anything that exists and release the new APIs labeling as > > early access. What if release the improvements labeling as EA instead of > > hiding them completely? > > > > I would also encourage us to put aside emotions, don't blame or point > > fingers. This IEP is a great initiative and you both have already done a > > tremendous job by developing, architecting and reviewing changes. Just be > > respectful. Nobody is trying to block the feature from being released. > > Everyone would be glad to tap into improvements and start using them in > > prod. But if more time is needed for the GA let's reiterate a bit. > > > > - > > Denis > > > > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков > > wrote: > > > > > > Also I agree with Alexey about introducing public IgniteMonitoring > > facade > > > > > > This is not an issue with the API. > > > Just the new feature that doesn’t affects API. > > > Moreover, I create a ticket to fix it, already. > > > > > > > It's right. But if you add checking of statisticsEnabling property > then > > > test will fail. It's just not good tests. > > > > > > My changes doesn’t affect any `staticticsEnabled` property. > > > I don’ understand your point here. > > > > > > > Redundant ReadOnlyMetricRegistry. > > > > > > It’s not redundant. > > > It required for exporters and provide read only access to > MetricRegistry > > > existing in the node. > > > > > > > > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > > > > > Absence of newly created metrics in old MBeans that forces user use > > > > exporter SPI while his code base uses old MBeans. > > > > > > Why this is issue? > > > > > > > Inconsistent MetricRegistry API. > > > > > > It’s consistent. > > > > > > > Metrics lookups from map instead of using direct reference > > > > (performance problem). > > > > > > 1. We(You and I) did this choice together to simplify creation of the > new > > > metrics. > > > 2. This is not public API issue. > > > > > > > > > > Ignoring of statisticsEnabled flag. > > > > > > I don’t ignore this flag. > > > It just doesn’t exists in new framework(because of scope). > > > I don’t think it’s an issue. > > > > > > > JmxExporterSpi creates beans that doesn't satisfy best MBeans > > practices. > > > > > > Please, clarify your statement. > > > What is best MBeans practices you are talking about? > > > > > > > Not finished IGNITE-11927 > > > > > > > > > How this can be API issue? > > > > > > > > > > 17 янв. 2020 г., в 20:52, Andrey Gura написал(а): > > > > > > > >>> All issues Alexey mentioned in starting letter are fixed with my PR > > > [1]. > > > >>> I don’t think other issues you mentioned are blocker for the > release. > > > > > > > > As I mentioned already IGNITE-11927 is part of IEP-35 and > > > > implementation seriously affects API's. Also I agree with Alexey > about > > > > introducing public IgniteMonitoring facade. So thiss PR doesn't fix > > > > all issues. > > > > > > > >>> I talk about ignored existing functionality. > > > >> There is no existing tests that was broken by this contribution. > > > > > > > > It's right. But if you add checking of statisticsEnabling property > > > > then test will fail. It's just not good tests. > > > > > > > >> If you know the issues with it, feel free to create a ticket I will > > fix > > > it ASAP. > > > > > > > > I already fix it all in IGNITE-11927 > > > > > > > >>> 1. Moving IEP-35 API's to the internal package. > > > >> We should move the product forward and shouldn't hide major > > > contribution from the user just because your second guess «I don’t like > > the > > > API I just reviewed and approved». > > > > > > > > We should move the product forward with with really finished > features, > > > > not pieces of features. > > > > > > > >> So I am against this proposal. > > > > > > > > It is not argument. > > > > > > > >> But, I’m ready to see your proposal for the API change and discuss > > them. > > > > > > > > We can prepare it together. But we can't block release. > > > > > > > >>> Because IGNITE-11927 doesn't solve all problems > > > >> What is *ALL* problems? > > > > > > > > Redundant ReadOnlyMetricRegistry. > > > >
Master compilation error
Hello. Igniters. Master build fails: https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead [13:37:02][Step 3/4] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project ignite-core: Compilation failure: Compilation failure: [13:37:02][Step 3/4] [ERROR] /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] cannot find symbol [13:37:02][Step 3/4] [ERROR] symbol: static IGNITE_BASELINE_AUTO_ADJUST_ENABLED [13:37:02][Step 3/4] [ERROR] location: class [13:37:02][Step 3/4] [ERROR] /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] cannot find symbol [13:37:02][Step 3/4] [ERROR] symbol: variable IGNITE_BASELINE_AUTO_ADJUST_ENABLED [13:37:02][Step 3/4] [ERROR] location: class org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest [13:37:02][Step 3/4] [ERROR] /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] cannot find symbol [13:37:02][Step 3/4] [ERROR] symbol: variable IGNITE_BASELINE_AUTO_ADJUST_ENABLED [13:37:02][Step 3/4] [ERROR] location: class org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest [13:37:02][Step 3/4] [ERROR] /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] cannot find symbol [13:37:02][Step 3/4] [ERROR] symbol: variable IGNITE_BASELINE_AUTO_ADJUST_ENABLED [13:37:02][Step 3/4] [ERROR] location: class org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest
Re: Internal classes are exposed in public API
Andrey. Let’s move from the long letters to the code. If you want to change API - please, propose this changes. I think everybody wins if we make our API better. Please, describe proposed changes. It would be great if you have some examples or PR for it. As for this release, I have plans to contribute tickets «[IEP-35] Expose MetricRegistry to the public API» [1] and «[IEP-35] public Java metric API» [2] for it. Any objections on it? [1] https://github.com/apache/ignite/pull/7269 [2] https://issues.apache.org/jira/browse/IGNITE-12553 > 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): > > It solves problem. > > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk > wrote: >> >> After giving it some thought, I agree with Denis - there is nothing wrong >> with exposing the new APIs, we just need to make it clear that we are still >> going to change it. >> >> Should we Introduce something like @IgniteExperimental annotation (I >> believe it has been discussed a dozen of times on the dev-list)? >> >> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : >> >>> +1 to mark feature or whole release as EA. >>> >>> пт, 17 янв. 2020 г., 23:00 Denis Magda : >>> Folks, if you don't mind I'll share some thoughts/suggestions as an observer who was not involved in the feature development. It's absolutely 'ok' to deprecate an API that is replaced with a much better version. However, we should do this only when the new APIs are production-ready. If there are still many limitations or open items then don't deprecate anything that exists and release the new APIs labeling as early access. What if release the improvements labeling as EA instead of hiding them completely? I would also encourage us to put aside emotions, don't blame or point fingers. This IEP is a great initiative and you both have already done a tremendous job by developing, architecting and reviewing changes. Just be respectful. Nobody is trying to block the feature from being released. Everyone would be glad to tap into improvements and start using them in prod. But if more time is needed for the GA let's reiterate a bit. - Denis On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков wrote: >> Also I agree with Alexey about introducing public IgniteMonitoring facade > > This is not an issue with the API. > Just the new feature that doesn’t affects API. > Moreover, I create a ticket to fix it, already. > >> It's right. But if you add checking of statisticsEnabling property >>> then > test will fail. It's just not good tests. > > My changes doesn’t affect any `staticticsEnabled` property. > I don’ understand your point here. > >> Redundant ReadOnlyMetricRegistry. > > It’s not redundant. > It required for exporters and provide read only access to >>> MetricRegistry > existing in the node. > > >> MetricExporterSpi that requires ReadOnlyMetricRegistry. > >> Absence of newly created metrics in old MBeans that forces user use >> exporter SPI while his code base uses old MBeans. > > Why this is issue? > >> Inconsistent MetricRegistry API. > > It’s consistent. > >> Metrics lookups from map instead of using direct reference >> (performance problem). > > 1. We(You and I) did this choice together to simplify creation of the >>> new > metrics. > 2. This is not public API issue. > > >> Ignoring of statisticsEnabled flag. > > I don’t ignore this flag. > It just doesn’t exists in new framework(because of scope). > I don’t think it’s an issue. > >> JmxExporterSpi creates beans that doesn't satisfy best MBeans practices. > > Please, clarify your statement. > What is best MBeans practices you are talking about? > >> Not finished IGNITE-11927 > > > How this can be API issue? > > >> 17 янв. 2020 г., в 20:52, Andrey Gura написал(а): >> All issues Alexey mentioned in starting letter are fixed with my PR > [1]. I don’t think other issues you mentioned are blocker for the >>> release. >> >> As I mentioned already IGNITE-11927 is part of IEP-35 and >> implementation seriously affects API's. Also I agree with Alexey >>> about >> introducing public IgniteMonitoring facade. So thiss PR doesn't fix >> all issues. >> I talk about ignored existing functionality. >>> There is no existing tests that was broken by this contribution. >> >> It's right. But if you add checking of statisticsEnabling property >> then test will fail. It's just not good tests. >> >>> If you know the issues with it, feel free to create a ticket I will fix > it ASAP. >> >> I already fix it all in IGNITE-11927 >> 1.
Re: Master compilation error
> Main question is "how this may happen in case fix got the Visa [2] ?". This can happen because of other changes in master. "Visa" truly works only when master is in the same state during the merge as it was during TC run. On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov wrote: > It seems, this because of IGNITE-12227 fix [1]. > Main question is "how this may happen in case fix got the Visa [2] ?". > > [1] > > https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles > [2] > > https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 > > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков > wrote: > > > Hello. Igniters. > > > > Master build fails: > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead > > > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > > (default-testCompile) on project ignite-core: Compilation failure: > > Compilation failure: > > [13:37:02][Step 3/4] [ERROR] > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] > > cannot find symbol > > [13:37:02][Step 3/4] [ERROR] symbol: static > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > [13:37:02][Step 3/4] [ERROR] location: class > > [13:37:02][Step 3/4] [ERROR] > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] > > cannot find symbol > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > [13:37:02][Step 3/4] [ERROR] location: class > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest > > [13:37:02][Step 3/4] [ERROR] > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] > > cannot find symbol > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > [13:37:02][Step 3/4] [ERROR] location: class > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > > [13:37:02][Step 3/4] [ERROR] > > > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] > > cannot find symbol > > [13:37:02][Step 3/4] [ERROR] symbol: variable > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > > [13:37:02][Step 3/4] [ERROR] location: class > > > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > > > > >
Re: Internal classes are exposed in public API
It solves problem. On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk wrote: > > After giving it some thought, I agree with Denis - there is nothing wrong > with exposing the new APIs, we just need to make it clear that we are still > going to change it. > > Should we Introduce something like @IgniteExperimental annotation (I > believe it has been discussed a dozen of times on the dev-list)? > > пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > > > +1 to mark feature or whole release as EA. > > > > пт, 17 янв. 2020 г., 23:00 Denis Magda : > > > > > Folks, if you don't mind I'll share some thoughts/suggestions as an > > > observer who was not involved in the feature development. > > > > > > It's absolutely 'ok' to deprecate an API that is replaced with a much > > > better version. However, we should do this only when the new APIs are > > > production-ready. If there are still many limitations or open items then > > > don't deprecate anything that exists and release the new APIs labeling as > > > early access. What if release the improvements labeling as EA instead of > > > hiding them completely? > > > > > > I would also encourage us to put aside emotions, don't blame or point > > > fingers. This IEP is a great initiative and you both have already done a > > > tremendous job by developing, architecting and reviewing changes. Just be > > > respectful. Nobody is trying to block the feature from being released. > > > Everyone would be glad to tap into improvements and start using them in > > > prod. But if more time is needed for the GA let's reiterate a bit. > > > > > > - > > > Denis > > > > > > > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков > > > wrote: > > > > > > > > Also I agree with Alexey about introducing public IgniteMonitoring > > > facade > > > > > > > > This is not an issue with the API. > > > > Just the new feature that doesn’t affects API. > > > > Moreover, I create a ticket to fix it, already. > > > > > > > > > It's right. But if you add checking of statisticsEnabling property > > then > > > > test will fail. It's just not good tests. > > > > > > > > My changes doesn’t affect any `staticticsEnabled` property. > > > > I don’ understand your point here. > > > > > > > > > Redundant ReadOnlyMetricRegistry. > > > > > > > > It’s not redundant. > > > > It required for exporters and provide read only access to > > MetricRegistry > > > > existing in the node. > > > > > > > > > > > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > > > > > > > Absence of newly created metrics in old MBeans that forces user use > > > > > exporter SPI while his code base uses old MBeans. > > > > > > > > Why this is issue? > > > > > > > > > Inconsistent MetricRegistry API. > > > > > > > > It’s consistent. > > > > > > > > > Metrics lookups from map instead of using direct reference > > > > > (performance problem). > > > > > > > > 1. We(You and I) did this choice together to simplify creation of the > > new > > > > metrics. > > > > 2. This is not public API issue. > > > > > > > > > > > > > Ignoring of statisticsEnabled flag. > > > > > > > > I don’t ignore this flag. > > > > It just doesn’t exists in new framework(because of scope). > > > > I don’t think it’s an issue. > > > > > > > > > JmxExporterSpi creates beans that doesn't satisfy best MBeans > > > practices. > > > > > > > > Please, clarify your statement. > > > > What is best MBeans practices you are talking about? > > > > > > > > > Not finished IGNITE-11927 > > > > > > > > > > > > How this can be API issue? > > > > > > > > > > > > > 17 янв. 2020 г., в 20:52, Andrey Gura написал(а): > > > > > > > > > >>> All issues Alexey mentioned in starting letter are fixed with my PR > > > > [1]. > > > > >>> I don’t think other issues you mentioned are blocker for the > > release. > > > > > > > > > > As I mentioned already IGNITE-11927 is part of IEP-35 and > > > > > implementation seriously affects API's. Also I agree with Alexey > > about > > > > > introducing public IgniteMonitoring facade. So thiss PR doesn't fix > > > > > all issues. > > > > > > > > > >>> I talk about ignored existing functionality. > > > > >> There is no existing tests that was broken by this contribution. > > > > > > > > > > It's right. But if you add checking of statisticsEnabling property > > > > > then test will fail. It's just not good tests. > > > > > > > > > >> If you know the issues with it, feel free to create a ticket I will > > > fix > > > > it ASAP. > > > > > > > > > > I already fix it all in IGNITE-11927 > > > > > > > > > >>> 1. Moving IEP-35 API's to the internal package. > > > > >> We should move the product forward and shouldn't hide major > > > > contribution from the user just because your second guess «I don’t like > > > the > > > > API I just reviewed and approved». > > > > > > > > > > We should move the product forward with with really finished > > features, > > > > > not pieces of features. > > > > > > > > > >> So I am against this proposal. > > > > > > > > > > It
[jira] [Created] (IGNITE-12555) .NET: Thin Client: deserializing DateTime fields causes BinaryTypeGet request for every value
Pavel Tupitsyn created IGNITE-12555:
---
Summary: .NET: Thin Client: deserializing DateTime fields causes
BinaryTypeGet request for every value
Key: IGNITE-12555
URL: https://issues.apache.org/jira/browse/IGNITE-12555
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.7.6, 2.7.5, 2.7, 2.6, 2.5, 2.4, 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8
Actual: The following code causes 10 BinaryProcessorClient.GetBinaryType calls
(2 fields, 5 Foo instances). Every call is a server request.
Expected: 0 calls. Binary metadata should be cached after PutAll call.
{code}
public class CacheDateTimeMetaTest : ClientTestBase
{
[Test]
public void TestDateTimeMeta()
{
var data = Enumerable.Range(1, 5)
.Select(x => new Foo
{
Id = x,
StartDate = DateTime.Now.AddHours(x),
EndDate = DateTime.Now.AddDays(x)
});
var cache = Client.GetOrCreateCache("foo");
cache.PutAll(data.Select(x => new KeyValuePair(x.Id, x)));
var res = cache.Query(new ScanQuery()).GetAll();
Assert.AreEqual(cache.GetSize(), res.Count);
}
public class Foo
{
public int Id { get; set; }
public DateTime? StartDate { get; set; }
public DateTime? EndDate { get; set; }
}
}
{code}
User list discussion:
http://apache-ignite-users.70518.x6.nabble.com/Getting-all-data-from-cache-via-scan-query-is-taking-lot-of-time-td30949.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Master compilation error
Master is fixed. пн, 20 янв. 2020 г. в 15:08, Alexey Goncharuk : > Will fix the compilation shortly, apologies for not checking locally. > > An additional compilation attempt is a good idea, but: first, I believe, > there is still an option to merge a PR directly to apache git, second - > when running a check, we need to make sure that master gets fast-forwarded > exactly to the revision that was checked (though, it will help to avoid a > lot of concurrent merge failures). I have no enough experience with Github, > so I am not sure if this is possible. > > пн, 20 янв. 2020 г. в 14:40, Anton Vinogradov : > >> Also, is it possible to perform the same check on the merge attempt? >> >> Each PR can be merged from GitHub page, can we append check to the "megre >> button" flow? >> Can we restrict merges bypassing this button? >> >> On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov wrote: >> >> > Should we perform an additional compilation attempt on pull/xxx/merge at >> > each visa request? >> > >> > On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn >> > wrote: >> > >> >> > Main question is "how this may happen in case fix got the Visa [2] >> ?". >> >> This can happen because of other changes in master. >> >> "Visa" truly works only when master is in the same state during the >> merge >> >> as it was during TC run. >> >> >> >> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov >> wrote: >> >> >> >> > It seems, this because of IGNITE-12227 fix [1]. >> >> > Main question is "how this may happen in case fix got the Visa [2] >> ?". >> >> > >> >> > [1] >> >> > >> >> > >> >> >> https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles >> >> > [2] >> >> > >> >> > >> >> >> https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 >> >> > >> >> > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков >> >> > wrote: >> >> > >> >> > > Hello. Igniters. >> >> > > >> >> > > Master build fails: >> >> > > >> >> > > >> >> > > >> >> > >> >> >> https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead >> >> > > >> >> > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal >> >> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile >> >> > > (default-testCompile) on project ignite-core: Compilation failure: >> >> > > Compilation failure: >> >> > > [13:37:02][Step 3/4] [ERROR] >> >> > > >> >> > >> >> >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] >> >> > > cannot find symbol >> >> > > [13:37:02][Step 3/4] [ERROR] symbol: static >> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> >> > > [13:37:02][Step 3/4] [ERROR] location: class >> >> > > [13:37:02][Step 3/4] [ERROR] >> >> > > >> >> > >> >> >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] >> >> > > cannot find symbol >> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> >> > > [13:37:02][Step 3/4] [ERROR] location: class >> >> > > >> >> > >> >> >> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest >> >> > > [13:37:02][Step 3/4] [ERROR] >> >> > > >> >> > >> >> >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] >> >> > > cannot find symbol >> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> >> > > [13:37:02][Step 3/4] [ERROR] location: class >> >> > > >> >> > >> >> >> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest >> >> > > [13:37:02][Step 3/4] [ERROR] >> >> > > >> >> > >> >> >> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] >> >> > > cannot find symbol >> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >> >> > > [13:37:02][Step 3/4] [ERROR] location: class >> >> > > >> >> > >> >> >> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest >> >> > > >> >> > > >> >> > >> >> >> > >> >
Re: Internal classes are exposed in public API
+1 to @IgniteExperimental On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > After giving it some thought, I agree with Denis - there is nothing wrong > with exposing the new APIs, we just need to make it clear that we are still > going to change it. > > Should we Introduce something like @IgniteExperimental annotation (I > believe it has been discussed a dozen of times on the dev-list)? > > пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > > > +1 to mark feature or whole release as EA. > > > > пт, 17 янв. 2020 г., 23:00 Denis Magda : > > > > > Folks, if you don't mind I'll share some thoughts/suggestions as an > > > observer who was not involved in the feature development. > > > > > > It's absolutely 'ok' to deprecate an API that is replaced with a much > > > better version. However, we should do this only when the new APIs are > > > production-ready. If there are still many limitations or open items > then > > > don't deprecate anything that exists and release the new APIs labeling > as > > > early access. What if release the improvements labeling as EA instead > of > > > hiding them completely? > > > > > > I would also encourage us to put aside emotions, don't blame or point > > > fingers. This IEP is a great initiative and you both have already done > a > > > tremendous job by developing, architecting and reviewing changes. Just > be > > > respectful. Nobody is trying to block the feature from being released. > > > Everyone would be glad to tap into improvements and start using them in > > > prod. But if more time is needed for the GA let's reiterate a bit. > > > > > > - > > > Denis > > > > > > > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков > > > wrote: > > > > > > > > Also I agree with Alexey about introducing public IgniteMonitoring > > > facade > > > > > > > > This is not an issue with the API. > > > > Just the new feature that doesn’t affects API. > > > > Moreover, I create a ticket to fix it, already. > > > > > > > > > It's right. But if you add checking of statisticsEnabling property > > then > > > > test will fail. It's just not good tests. > > > > > > > > My changes doesn’t affect any `staticticsEnabled` property. > > > > I don’ understand your point here. > > > > > > > > > Redundant ReadOnlyMetricRegistry. > > > > > > > > It’s not redundant. > > > > It required for exporters and provide read only access to > > MetricRegistry > > > > existing in the node. > > > > > > > > > > > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > > > > > > > Absence of newly created metrics in old MBeans that forces user use > > > > > exporter SPI while his code base uses old MBeans. > > > > > > > > Why this is issue? > > > > > > > > > Inconsistent MetricRegistry API. > > > > > > > > It’s consistent. > > > > > > > > > Metrics lookups from map instead of using direct reference > > > > > (performance problem). > > > > > > > > 1. We(You and I) did this choice together to simplify creation of the > > new > > > > metrics. > > > > 2. This is not public API issue. > > > > > > > > > > > > > Ignoring of statisticsEnabled flag. > > > > > > > > I don’t ignore this flag. > > > > It just doesn’t exists in new framework(because of scope). > > > > I don’t think it’s an issue. > > > > > > > > > JmxExporterSpi creates beans that doesn't satisfy best MBeans > > > practices. > > > > > > > > Please, clarify your statement. > > > > What is best MBeans practices you are talking about? > > > > > > > > > Not finished IGNITE-11927 > > > > > > > > > > > > How this can be API issue? > > > > > > > > > > > > > 17 янв. 2020 г., в 20:52, Andrey Gura > написал(а): > > > > > > > > > >>> All issues Alexey mentioned in starting letter are fixed with my > PR > > > > [1]. > > > > >>> I don’t think other issues you mentioned are blocker for the > > release. > > > > > > > > > > As I mentioned already IGNITE-11927 is part of IEP-35 and > > > > > implementation seriously affects API's. Also I agree with Alexey > > about > > > > > introducing public IgniteMonitoring facade. So thiss PR doesn't fix > > > > > all issues. > > > > > > > > > >>> I talk about ignored existing functionality. > > > > >> There is no existing tests that was broken by this contribution. > > > > > > > > > > It's right. But if you add checking of statisticsEnabling property > > > > > then test will fail. It's just not good tests. > > > > > > > > > >> If you know the issues with it, feel free to create a ticket I > will > > > fix > > > > it ASAP. > > > > > > > > > > I already fix it all in IGNITE-11927 > > > > > > > > > >>> 1. Moving IEP-35 API's to the internal package. > > > > >> We should move the product forward and shouldn't hide major > > > > contribution from the user just because your second guess «I don’t > like > > > the > > > > API I just reviewed and approved». > > > > > > > > > > We should move the product forward with with really finished > > features, > > > > > not pieces of features. > > > > > > > > > >>
Re: Internal classes are exposed in public API
Hello, I totally agree. It would be nice to have a marker that can be used to indicate that the feature may be changed in future releases and should be used to your own risk. Thanks, S. пн, 20 янв. 2020 г. в 12:16, Anton Vinogradov : > +1 to @IgniteExperimental > > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > After giving it some thought, I agree with Denis - there is nothing wrong > > with exposing the new APIs, we just need to make it clear that we are > still > > going to change it. > > > > Should we Introduce something like @IgniteExperimental annotation (I > > believe it has been discussed a dozen of times on the dev-list)? > > > > пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > > > > > +1 to mark feature or whole release as EA. > > > > > > пт, 17 янв. 2020 г., 23:00 Denis Magda : > > > > > > > Folks, if you don't mind I'll share some thoughts/suggestions as an > > > > observer who was not involved in the feature development. > > > > > > > > It's absolutely 'ok' to deprecate an API that is replaced with a much > > > > better version. However, we should do this only when the new APIs are > > > > production-ready. If there are still many limitations or open items > > then > > > > don't deprecate anything that exists and release the new APIs > labeling > > as > > > > early access. What if release the improvements labeling as EA instead > > of > > > > hiding them completely? > > > > > > > > I would also encourage us to put aside emotions, don't blame or point > > > > fingers. This IEP is a great initiative and you both have already > done > > a > > > > tremendous job by developing, architecting and reviewing changes. > Just > > be > > > > respectful. Nobody is trying to block the feature from being > released. > > > > Everyone would be glad to tap into improvements and start using them > in > > > > prod. But if more time is needed for the GA let's reiterate a bit. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков > > > > > wrote: > > > > > > > > > > Also I agree with Alexey about introducing public > IgniteMonitoring > > > > facade > > > > > > > > > > This is not an issue with the API. > > > > > Just the new feature that doesn’t affects API. > > > > > Moreover, I create a ticket to fix it, already. > > > > > > > > > > > It's right. But if you add checking of statisticsEnabling > property > > > then > > > > > test will fail. It's just not good tests. > > > > > > > > > > My changes doesn’t affect any `staticticsEnabled` property. > > > > > I don’ understand your point here. > > > > > > > > > > > Redundant ReadOnlyMetricRegistry. > > > > > > > > > > It’s not redundant. > > > > > It required for exporters and provide read only access to > > > MetricRegistry > > > > > existing in the node. > > > > > > > > > > > > > > > > MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > > > > > > > > > Absence of newly created metrics in old MBeans that forces user > use > > > > > > exporter SPI while his code base uses old MBeans. > > > > > > > > > > Why this is issue? > > > > > > > > > > > Inconsistent MetricRegistry API. > > > > > > > > > > It’s consistent. > > > > > > > > > > > Metrics lookups from map instead of using direct reference > > > > > > (performance problem). > > > > > > > > > > 1. We(You and I) did this choice together to simplify creation of > the > > > new > > > > > metrics. > > > > > 2. This is not public API issue. > > > > > > > > > > > > > > > > Ignoring of statisticsEnabled flag. > > > > > > > > > > I don’t ignore this flag. > > > > > It just doesn’t exists in new framework(because of scope). > > > > > I don’t think it’s an issue. > > > > > > > > > > > JmxExporterSpi creates beans that doesn't satisfy best MBeans > > > > practices. > > > > > > > > > > Please, clarify your statement. > > > > > What is best MBeans practices you are talking about? > > > > > > > > > > > Not finished IGNITE-11927 > > > > > > > > > > > > > > > How this can be API issue? > > > > > > > > > > > > > > > > 17 янв. 2020 г., в 20:52, Andrey Gura > > написал(а): > > > > > > > > > > > >>> All issues Alexey mentioned in starting letter are fixed with > my > > PR > > > > > [1]. > > > > > >>> I don’t think other issues you mentioned are blocker for the > > > release. > > > > > > > > > > > > As I mentioned already IGNITE-11927 is part of IEP-35 and > > > > > > implementation seriously affects API's. Also I agree with Alexey > > > about > > > > > > introducing public IgniteMonitoring facade. So thiss PR doesn't > fix > > > > > > all issues. > > > > > > > > > > > >>> I talk about ignored existing functionality. > > > > > >> There is no existing tests that was broken by this contribution. > > > > > > > > > > > > It's right. But if you add checking of statisticsEnabling > property > > > > > > then test will fail. It's just not good tests. > > > > > > > > > > > >> If you know the issues with it, feel free to create a
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim, I took a quick look at IGNITE-12456 and I am not sure it's about data corruption. In the attached logs blocked system threads are reported, however, there is no enough information to investigate the issue (the full thread dump was not attached). I asked the ticket creator to attach missing pieces. Should we consider moving this ticket to a next release? пн, 20 янв. 2020 г. в 08:54, Zhenya Stanilovsky : > > Maxim, performance fix issue [1] already in master, if no objections, can > u merge it into 2.8 ? Thanks ! > [1] https://issues.apache.org/jira/browse/IGNITE-12547 > > >Igniters, > > > > > >Here is the actual list of BLOCKER release issues: > > > >IGNITE-12456 Cluster Data Store grid gets Corrupted for Load test > >*[Unassigned]* OPEN > >IGNITE-12489 Error during purges by expiration: Unknown page type* > >[Unassigned]* OPEN > >IGNITE-8641 SpringDataExample should use example-ignite.xml config > >*[Unassigned]* OPEN > > > >IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes > getting > >down [Emmanouil Gkatziouras] OPEN > >IGNITE-9184 Cluster hangs during concurrent node client and server nodes > >restart [Dmitriy Sorokin] IN PROGRESS > >IGNITE-12553 [IEP-35] public Java metric API Improvement [Nikolay Izhikov] > >Blocker IN PROGRESS > > > >IGNITE-12227 Default auto-adjust baseline enabled flag calculated > >incorrectly [Anton Kalashnikov] PATCH AVAILABLE > >IGNITE-12470 Pme-free switch feature should be deactivatable [Sergei > >Ryzhov] PATCH AVAILABLE > >IGNITE-12552 [IEP-35] Expose MetricRegistry to the public API Improvement > >[Nikolay Izhikov] PATCH AVAILABLE > > > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12456 > >[2] https://issues.apache.org/jira/browse/IGNITE-12489 > >[3] https://issues.apache.org/jira/browse/IGNITE-8641 > >[8] https://issues.apache.org/jira/browse/IGNITE-12398 > >[3] https://issues.apache.org/jira/browse/IGNITE-9184 > >[6] https://issues.apache.org/jira/browse/IGNITE-12553 > >[7] https://issues.apache.org/jira/browse/IGNITE-12227 > >[9] https://issues.apache.org/jira/browse/IGNITE-12470 > >[5] https://issues.apache.org/jira/browse/IGNITE-12552 > > > > > >On Sat, 18 Jan 2020 at 19:11, Sergey Antonov < antonovserge...@gmail.com > > > >wrote: > > > >> Maxim, > >> > >> Conflicts in pr [1] are resolved. TC Run all is started. > >> > >> [1] https://github.com/apache/ignite/pull/7238 > >> > >> пт, 17 янв. 2020 г. в 16:04, Sergey Antonov < antonovserge...@gmail.com > >: > >> > >>> Maxim, > >>> > >>> I will do that on monday (20/01). > >>> > >>> пт, 17 янв. 2020 г. в 13:08, Maxim Muzafarov < mmu...@apache.org >: > >>> > Sergey, > > > Can you, please, resolve the PR conflicts [1] [2]? > > [1] https://github.com/apache/ignite/pull/7238 > [2] https://issues.apache.org/jira/browse/IGNITE-11256 > > On Thu, 16 Jan 2020 at 16:59, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > wrote: > > > > Hello! > > > > I have bumped beanutils and re-ran Cassandra Store tests. Can you > please > > comment on the ticket? > > > > I think that fixing ZooKeeper is too much effort (there's chaos with > > jackson vs. jackson-asl), maybe it should be split up as a separate > ticket > > to be done later. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 15 янв. 2020 г. в 18:31, Vladimir Pligin < vova199...@yandex.ru > >: > > > > > Thanks, Ilya. It would be really great to have your patch included > into 2.8 > > > scope. > > > I'd like to give my two cent as well. For example we have > vulnerable > > > dependencies here: > > > modules/cassandra/store/pom.xml - commons-beanutils > > > modules/zookeeper/pom.xml - transitive Jackson from Curator > > > > > > I'd suggest to uprgrade commons-beanutils:commons-beanutils to > 1.9.4 > and > > > override com.fasterxml.jackson.core:jackson-databind to our common > jackson > > > version from other modules. > > > > > > > > > > > > -- > > > Sent from: > http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >>> > >>> > >>> -- > >>> BR, Sergey Antonov > >>> > >> > >> > >> -- > >> BR, Sergey Antonov > >> > > > >
Re: Master compilation error
It seems, this because of IGNITE-12227 fix [1]. Main question is "how this may happen in case fix got the Visa [2] ?". [1] https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles [2] https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков wrote: > Hello. Igniters. > > Master build fails: > > > https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > (default-testCompile) on project ignite-core: Compilation failure: > Compilation failure: > [13:37:02][Step 3/4] [ERROR] > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] > cannot find symbol > [13:37:02][Step 3/4] [ERROR] symbol: static > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > [13:37:02][Step 3/4] [ERROR] location: class > [13:37:02][Step 3/4] [ERROR] > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] > cannot find symbol > [13:37:02][Step 3/4] [ERROR] symbol: variable > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > [13:37:02][Step 3/4] [ERROR] location: class > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest > [13:37:02][Step 3/4] [ERROR] > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] > cannot find symbol > [13:37:02][Step 3/4] [ERROR] symbol: variable > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > [13:37:02][Step 3/4] [ERROR] location: class > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > [13:37:02][Step 3/4] [ERROR] > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] > cannot find symbol > [13:37:02][Step 3/4] [ERROR] symbol: variable > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > [13:37:02][Step 3/4] [ERROR] location: class > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > >
Re: Thin client: compute support
Huge +1 from me for Feature Masks. I think this should be our top priority for thin client protocol, since it simplifies change management a lot. On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego wrote: > Sorry for the late reply. > > Approach with taskId will require a lot of changes in protocol and thus > more "heavy" for implementation, but it definitely looks to me less hacky > than reqId-approach. Moreover, as was mentioned, server notifications > mechanism will be required in a future anyway with high probability. So > from this point of view I like taskId-approach. > > On the other hand, what we should also consider here is performance. > Speaking of latency, it looks like reqId will have better results in case > of > small and fast tasks. The only question here, if we want to optimize thin > clients for this case. > > Also, what are you talking about mostly involves clients on platforms > that already have Compute API for thick clients. Let me mention one > more point of view here and another concern here. > > The changes you propose are going to change protocol version for sure. > In case with taskId approach and server notifications - even more so. > > But such clients as Python, Node.js, PHP, Go most probably won't have > support for this API, at least for now. Or never. But current > backward-compatibility mechanism implies protocol versions where we > imply that client that supports version 1.5 also supports all the features > introduced in all the previous versions of the protocol. > > Thus implementing Compute API in any of the proposed ways *may* > force mentioned clients to support changes in protocol which they not > necessarily need in order to introduce new features in the future. > > So, maybe it's a good time for us to change our backward compatibility > mechanism from protocol versioning to feature masks? > > WDYT? > > Best Regards, > Igor > > > On Fri, Jan 17, 2020 at 9:37 AM Alex Plehanov > wrote: > > > Looks like we didn't rich consensus here. > > > > Igor, as thin client maintainer, can you please share your opinion? > > > > Everyone else also welcome, please share your thoughts about options to > > implement operations for compute. > > > > > > чт, 28 нояб. 2019 г. в 10:02, Alex Plehanov : > > > > > > Since all thin client operations are inherently async, we should be > > able > > > to cancel any of them > > > It's illogical to have such ability. What should do cancel operation of > > > cancel operation? Moreover, sometimes it's dangerous, for example, > create > > > cache operation should never be canceled. There should be an explicit > set > > > of processes that we can cancel: queries, transactions, tasks, > services. > > > The lifecycle of services is more complex than the lifecycle of tasks. > > With > > > services, I suppose, we can't use request cancelation, so tasks will be > > the > > > only process with an exceptional pattern. > > > > > > > The request would be "execute task with specified node filter" - > simple > > > and efficient. > > > It's not simple: every compute or service request should contain > complex > > > node filtering logic, which duplicates the same logic for cluster API. > > > It's not efficient: for example, we can't implement forPredicate() > > > filtering in this case. > > > > > > > > > ср, 27 нояб. 2019 г. в 19:25, Pavel Tupitsyn : > > > > > >> > The request is already processed (task is started), we can't cancel > > the > > >> request > > >> The request is not "start a task". It is "execute task" (and get > > result). > > >> Same as "cache get" - you get a result in the end, we don't "start > cache > > >> get" then "end cache get". > > >> > > >> Since all thin client operations are inherently async, we should be > able > > >> to > > >> cancel any of them > > >> by sending another request with an id of prior request to be > cancelled. > > >> That's why I'm advocating for this approach - it will work for > anything, > > >> no > > >> special cases. > > >> And it keeps "happy path" as simple as it is right now. > > >> > > >> Queries are different because we retrieve results in pages, we can't > do > > >> them as one request. > > >> Transactions are also different because client controls when they > should > > >> end. > > >> There is no reason for task execution to be a special case like > queries > > or > > >> transactions. > > >> > > >> > we always need to send 2 requests to server to execute the task > > >> Nope. We don't need to get nodes on client at all. > > >> The request would be "execute task with specified node filter" - > simple > > >> and > > >> efficient. > > >> > > >> > > >> On Wed, Nov 27, 2019 at 4:31 PM Alex Plehanov < > plehanov.a...@gmail.com> > > >> wrote: > > >> > > >> > > We do cancel a request to perform a task. We may and should use > > this > > >> to > > >> > cancel any other request in future. > > >> > The request is already processed (task is started), we can't cancel > > the > > >> > request. As you mentioned before, we
Re: [jira] [Created] (IGNITE-12556) Online Dev Tools
What is it? Some kind of advertisement? Should we close it? пн, 20 янв. 2020 г. в 16:45, Stephen (Jira) : > > Stephen created IGNITE-12556: > > > Summary: Online Dev Tools > Key: IGNITE-12556 > URL: https://issues.apache.org/jira/browse/IGNITE-12556 > Project: Ignite > Issue Type: Bug > Environment: https://onlinedevtools.in > > check this link > > useful web developer tools link > > https://onlinedevtools.in/lodash_underscore_alternative > > https://onlinedevtools.in/online/sqlformatter > > https://onlinedevtools.in/online/npmpackageanalyzer > > https://onlinedevtools.in/curl > > https://onlinedevtools.in/crontab > > https://onlinedevtools.in/devnews > > https://diffviewer.onlinedevtools.in > Reporter: Stephen > > > https://onlinedevtools.in > > check this link > > useful web developer tools link > > https://onlinedevtools.in/lodash_underscore_alternative > > https://onlinedevtools.in/online/sqlformatter > > https://onlinedevtools.in/online/npmpackageanalyzer > > https://onlinedevtools.in/curl > > https://onlinedevtools.in/crontab > > https://onlinedevtools.in/devnews > > https://diffviewer.onlinedevtools.in > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005) -- Best regards, Ivan Pavlukhin
Re: Internal classes are exposed in public API
> Let’s move from the long letters to the code. Let's thinking before coding. Development is not only coding. Why such a rush? Measure thrice and cut once. "Long letters" is way of discussion before writing code. And it's ok. On Mon, Jan 20, 2020 at 1:32 PM Николай Ижиков wrote: > > Andrey. > > Let’s move from the long letters to the code. > If you want to change API - please, propose this changes. > I think everybody wins if we make our API better. > > Please, describe proposed changes. > It would be great if you have some examples or PR for it. > > As for this release, I have plans to contribute tickets > «[IEP-35] Expose MetricRegistry to the public API» [1] and > «[IEP-35] public Java metric API» [2] for it. > > Any objections on it? > > [1] https://github.com/apache/ignite/pull/7269 > [2] https://issues.apache.org/jira/browse/IGNITE-12553 > > > > 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): > > > > It solves problem. > > > > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk > > wrote: > >> > >> After giving it some thought, I agree with Denis - there is nothing wrong > >> with exposing the new APIs, we just need to make it clear that we are still > >> going to change it. > >> > >> Should we Introduce something like @IgniteExperimental annotation (I > >> believe it has been discussed a dozen of times on the dev-list)? > >> > >> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > >> > >>> +1 to mark feature or whole release as EA. > >>> > >>> пт, 17 янв. 2020 г., 23:00 Denis Magda : > >>> > Folks, if you don't mind I'll share some thoughts/suggestions as an > observer who was not involved in the feature development. > > It's absolutely 'ok' to deprecate an API that is replaced with a much > better version. However, we should do this only when the new APIs are > production-ready. If there are still many limitations or open items then > don't deprecate anything that exists and release the new APIs labeling as > early access. What if release the improvements labeling as EA instead of > hiding them completely? > > I would also encourage us to put aside emotions, don't blame or point > fingers. This IEP is a great initiative and you both have already done a > tremendous job by developing, architecting and reviewing changes. Just be > respectful. Nobody is trying to block the feature from being released. > Everyone would be glad to tap into improvements and start using them in > prod. But if more time is needed for the GA let's reiterate a bit. > > - > Denis > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков > wrote: > > >> Also I agree with Alexey about introducing public IgniteMonitoring > facade > > > > This is not an issue with the API. > > Just the new feature that doesn’t affects API. > > Moreover, I create a ticket to fix it, already. > > > >> It's right. But if you add checking of statisticsEnabling property > >>> then > > test will fail. It's just not good tests. > > > > My changes doesn’t affect any `staticticsEnabled` property. > > I don’ understand your point here. > > > >> Redundant ReadOnlyMetricRegistry. > > > > It’s not redundant. > > It required for exporters and provide read only access to > >>> MetricRegistry > > existing in the node. > > > > > >> MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > >> Absence of newly created metrics in old MBeans that forces user use > >> exporter SPI while his code base uses old MBeans. > > > > Why this is issue? > > > >> Inconsistent MetricRegistry API. > > > > It’s consistent. > > > >> Metrics lookups from map instead of using direct reference > >> (performance problem). > > > > 1. We(You and I) did this choice together to simplify creation of the > >>> new > > metrics. > > 2. This is not public API issue. > > > > > >> Ignoring of statisticsEnabled flag. > > > > I don’t ignore this flag. > > It just doesn’t exists in new framework(because of scope). > > I don’t think it’s an issue. > > > >> JmxExporterSpi creates beans that doesn't satisfy best MBeans > practices. > > > > Please, clarify your statement. > > What is best MBeans practices you are talking about? > > > >> Not finished IGNITE-11927 > > > > > > How this can be API issue? > > > > > >> 17 янв. 2020 г., в 20:52, Andrey Gura написал(а): > >> > All issues Alexey mentioned in starting letter are fixed with my PR > > [1]. > I don’t think other issues you mentioned are blocker for the > >>> release. > >> > >> As I mentioned already IGNITE-11927 is part of IEP-35 and > >> implementation seriously affects API's. Also I agree with Alexey > >>> about > >> introducing public IgniteMonitoring
Re: Master compilation error
Hello! I do the following: mvn clean install -DskipTests -Dmaven.javadoc.skip=true -Dmaven.scaladoc.skip=true -Plgpl Maybe -Pall-java is needed actually, though, it will not check C++ and .Net anyway :-/ Regards, -- Ilya Kasnacheev пн, 20 янв. 2020 г. в 16:35, Alexey Goncharuk : > Ok, now I'm confused: what is a kosher command to check the build locally? > > пн, 20 янв. 2020 г. в 15:38, Alexey Goncharuk >: > > > Master is fixed. > > > > пн, 20 янв. 2020 г. в 15:08, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > >> Will fix the compilation shortly, apologies for not checking locally. > >> > >> An additional compilation attempt is a good idea, but: first, I believe, > >> there is still an option to merge a PR directly to apache git, second - > >> when running a check, we need to make sure that master gets > fast-forwarded > >> exactly to the revision that was checked (though, it will help to avoid > a > >> lot of concurrent merge failures). I have no enough experience with > Github, > >> so I am not sure if this is possible. > >> > >> пн, 20 янв. 2020 г. в 14:40, Anton Vinogradov : > >> > >>> Also, is it possible to perform the same check on the merge attempt? > >>> > >>> Each PR can be merged from GitHub page, can we append check to the > "megre > >>> button" flow? > >>> Can we restrict merges bypassing this button? > >>> > >>> On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov > wrote: > >>> > >>> > Should we perform an additional compilation attempt on pull/xxx/merge > >>> at > >>> > each visa request? > >>> > > >>> > On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn > > >>> > wrote: > >>> > > >>> >> > Main question is "how this may happen in case fix got the Visa [2] > >>> ?". > >>> >> This can happen because of other changes in master. > >>> >> "Visa" truly works only when master is in the same state during the > >>> merge > >>> >> as it was during TC run. > >>> >> > >>> >> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov > >>> wrote: > >>> >> > >>> >> > It seems, this because of IGNITE-12227 fix [1]. > >>> >> > Main question is "how this may happen in case fix got the Visa [2] > >>> ?". > >>> >> > > >>> >> > [1] > >>> >> > > >>> >> > > >>> >> > >>> > https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles > >>> >> > [2] > >>> >> > > >>> >> > > >>> >> > >>> > https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 > >>> >> > > >>> >> > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков < > nizhi...@apache.org > >>> > > >>> >> > wrote: > >>> >> > > >>> >> > > Hello. Igniters. > >>> >> > > > >>> >> > > Master build fails: > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > >>> >> > >>> > https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead > >>> >> > > > >>> >> > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal > >>> >> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile > >>> >> > > (default-testCompile) on project ignite-core: Compilation > failure: > >>> >> > > Compilation failure: > >>> >> > > [13:37:02][Step 3/4] [ERROR] > >>> >> > > > >>> >> > > >>> >> > >>> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] > >>> >> > > cannot find symbol > >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: static > >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class > >>> >> > > [13:37:02][Step 3/4] [ERROR] > >>> >> > > > >>> >> > > >>> >> > >>> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] > >>> >> > > cannot find symbol > >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable > >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class > >>> >> > > > >>> >> > > >>> >> > >>> > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest > >>> >> > > [13:37:02][Step 3/4] [ERROR] > >>> >> > > > >>> >> > > >>> >> > >>> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] > >>> >> > > cannot find symbol > >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable > >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED > >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class > >>> >> > > > >>> >> > > >>> >> > >>> > org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest > >>> >> > > [13:37:02][Step 3/4] [ERROR] > >>> >> > > >
Re: Ignite-spring-boot-autoconfigurer
Hello, Saikat.
Thanks, for feedback.
I raised a PR [1] to `ignite-extensions`.
You can find description of the new module below(examples can be found at [2]):
Module provides the ability to integrate `Ignite` into you spring-boot
application with zero(or minimal) configuration.
After you add this module as a dependency to your spring-boot application
`Ignite` node will be configured and injected into `BeanFactory`.
Algorithm to configure `Ignite` is the following:
1. If `IgniteConfiguration` bean exists in the `BeanFactory` it will be used.
2. If `IgniteConfiguration` bean doesn't exist following rules are applied:
2.1. Default `Ignite` configuration created.
2.2. If `IgniteConfigurer` bean exists in `BeanFactory` it will be used to
customize `IgniteConfiguration`.
If a user wants to set custom SPI instances or similar hardcoded values
one should do it with `IgniteConfigurer` implementation.
2.3 Application properties applied to `IgniteConfiguration`. Prefix for
the properties is `ignite`.
[1] https://github.com/apache/ignite-extensions/pull/6
[2] https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
> 18 янв. 2020 г., в 06:44, Saikat Maitra написал(а):
>
> Hi Nikolay,
>
> Thank you for your email. As part of Ignite Extensions migration we are
> migrating Ignite Extensions to following repo.
>
> https://github.com/apache/ignite-extensions
>
> We have added flink and pub-sub modules and few additional modules are open
> in PR.
>
> You can refer to this PR to see how we are migrating the modules
> https://github.com/apache/ignite-extensions/pull/5
>
> I wanted to connect and discuss the changes to understand the spring boot
> auto configure feature. We currently have an ignite spring module that allows
> resource injection capabilities and provides a parser for Spring based xml
> configuration files. Can you please review and share if the changes you are
> proposing can be added as part of Ignite spring module or it make sense to
> make it a separate spring boot auto configure module.
>
> https://github.com/apache/ignite/tree/master/modules/spring
>
> Regards,
> Saikat
>
>
>
>
>
>
>
> On Fri, Jan 17, 2020 at 3:12 AM Николай Ижиков wrote:
> Tests added.
> Please, review.
>
> Saikat, can you help with this PR [1]?
>
> I think it should be added as a separate module as we do with the flink
> integration.
> Can you help me with it?
> Do we have some how-to for it?
>
> [1] https://github.com/apache/ignite/pull/7237
>
> > 16 янв. 2020 г., в 16:51, Николай Ижиков
> > написал(а):
> >
> > Hello, Denis.
> >
> > Thanks, for the feedback.
> >
> > Alexey, it seems, PR is ready to be reviewed, but I need some time(a day or
> > two) to write tests.
> > You can start with the core code review if you wish.
> >
> > Here are autoconfigurer requirements:
> >
> > 1. Start usage of Ignite with minimal(or zero) configuration.
> > 2. Configure Ignite configuration properties with the standard spring boot
> > application properties.
> > 3. Configure Ignite SPI implementation and so on that can’t be configured
> > via #2.
> >
> > After some consultation with the Spring experts from the community(Maxim
> > Stepachev thanks for the idea)
> > I updated the PR with the logic described below:
> >
> > 1. To enable Ignite auto-configuration user should add
> > `org.apache.ignite:spring-boot-ignite-autoconfigure:2.9.0` to dependencies.
> >After it Ignite node will be started during spring-boot application
> > startup.
> >
> > 2. IgniteConfiguration initialization logic:
> >
> > 2.1 If {@link IgniteConfiguration} bean exists in {@link BeanFactory} it
> > will be used for the node start.
> > 2.2 If {@link IgniteConfiguration} bean doesn't exist following rules are
> > applied:
> > * Newly introducer IgniteConfigurer bean will be used to customize an
> > empty IgniteConfiguration instance.
> >If a user wants to set custom SPI instances or similar hardcoded values
> > one should do it IgniteConfigurer implementation.
> >
> > * Application properties will override config values. Prefix for
> > properties names is "ignite».
> >
> > PS. Similar logic applied for the second module -
> > `org.apache.ignite:spring-boot-ignite-client-autoconfigure:2.9.0`.
> > It provides the same features but for the autoconfiguration of the
> > IgniteClient
> >
> >
> >> 15 янв. 2020 г., в 03:03, Denis Magda написал(а):
> >>
> >> Nikolay,
> >>
> >> Thanks for contributing in this direction! That's one of the gaps on our
> >> end and the user community will be certainly thankful once we fill it in.
> >>
> >> *Alexey Kuznetsov*, as one of the Spring Boot experts, could you spend some
> >> time reviewing the changes?
> >>
> >> As for the extensions/modularization activities, please join Saikat in the
> >> discussions ([1] and [2]). He is contributing the foundation and moving our
> >> existing integrations to that new repository. The
Re: Internal classes are exposed in public API
Alexey. PR [1] is waiting for your review. Please, take a look. I think we should do the following before 2.8 release * Introduce new @IgniteExperimental annotation as discussed. * Mark Monitoring API with it. * merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8 * merge «[IEP-35] public Java metric API» to 2.8 [1] https://github.com/apache/ignite/pull/7269 > 20 янв. 2020 г., в 17:09, Alexey Goncharuk > написал(а): > > Nikolay, > > Should we wait for both of the tickets given that we agreed that we are > putting an experimental marker on the new APIs? I'm ok to fix only the > first one and add the experimental marker so that we do not delay 2.8 > release. > > пн, 20 янв. 2020 г. в 13:32, Николай Ижиков : > >> Andrey. >> >> Let’s move from the long letters to the code. >> If you want to change API - please, propose this changes. >> I think everybody wins if we make our API better. >> >> Please, describe proposed changes. >> It would be great if you have some examples or PR for it. >> >> As for this release, I have plans to contribute tickets >> «[IEP-35] Expose MetricRegistry to the public API» [1] and >> «[IEP-35] public Java metric API» [2] for it. >> >> Any objections on it? >> >> [1] https://github.com/apache/ignite/pull/7269 >> [2] https://issues.apache.org/jira/browse/IGNITE-12553 >> >> >>> 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): >>> >>> It solves problem. >>> >>> On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk >>> wrote: After giving it some thought, I agree with Denis - there is nothing >> wrong with exposing the new APIs, we just need to make it clear that we are >> still going to change it. Should we Introduce something like @IgniteExperimental annotation (I believe it has been discussed a dozen of times on the dev-list)? пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > +1 to mark feature or whole release as EA. > > пт, 17 янв. 2020 г., 23:00 Denis Magda : > >> Folks, if you don't mind I'll share some thoughts/suggestions as an >> observer who was not involved in the feature development. >> >> It's absolutely 'ok' to deprecate an API that is replaced with a much >> better version. However, we should do this only when the new APIs are >> production-ready. If there are still many limitations or open items >> then >> don't deprecate anything that exists and release the new APIs >> labeling as >> early access. What if release the improvements labeling as EA instead >> of >> hiding them completely? >> >> I would also encourage us to put aside emotions, don't blame or point >> fingers. This IEP is a great initiative and you both have already >> done a >> tremendous job by developing, architecting and reviewing changes. >> Just be >> respectful. Nobody is trying to block the feature from being released. >> Everyone would be glad to tap into improvements and start using them >> in >> prod. But if more time is needed for the GA let's reiterate a bit. >> >> - >> Denis >> >> >> On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков >> wrote: >> Also I agree with Alexey about introducing public IgniteMonitoring >> facade >>> >>> This is not an issue with the API. >>> Just the new feature that doesn’t affects API. >>> Moreover, I create a ticket to fix it, already. >>> It's right. But if you add checking of statisticsEnabling property > then >>> test will fail. It's just not good tests. >>> >>> My changes doesn’t affect any `staticticsEnabled` property. >>> I don’ understand your point here. >>> Redundant ReadOnlyMetricRegistry. >>> >>> It’s not redundant. >>> It required for exporters and provide read only access to > MetricRegistry >>> existing in the node. >>> >>> MetricExporterSpi that requires ReadOnlyMetricRegistry. >>> Absence of newly created metrics in old MBeans that forces user use exporter SPI while his code base uses old MBeans. >>> >>> Why this is issue? >>> Inconsistent MetricRegistry API. >>> >>> It’s consistent. >>> Metrics lookups from map instead of using direct reference (performance problem). >>> >>> 1. We(You and I) did this choice together to simplify creation of the > new >>> metrics. >>> 2. This is not public API issue. >>> >>> Ignoring of statisticsEnabled flag. >>> >>> I don’t ignore this flag. >>> It just doesn’t exists in new framework(because of scope). >>> I don’t think it’s an issue. >>> JmxExporterSpi creates beans that doesn't satisfy best MBeans >> practices. >>> >>> Please, clarify your statement. >>> What is best MBeans practices you are talking about? >>> Not finished
Re: Master compilation error
Ok, now I'm confused: what is a kosher command to check the build locally? пн, 20 янв. 2020 г. в 15:38, Alexey Goncharuk : > Master is fixed. > > пн, 20 янв. 2020 г. в 15:08, Alexey Goncharuk >: > >> Will fix the compilation shortly, apologies for not checking locally. >> >> An additional compilation attempt is a good idea, but: first, I believe, >> there is still an option to merge a PR directly to apache git, second - >> when running a check, we need to make sure that master gets fast-forwarded >> exactly to the revision that was checked (though, it will help to avoid a >> lot of concurrent merge failures). I have no enough experience with Github, >> so I am not sure if this is possible. >> >> пн, 20 янв. 2020 г. в 14:40, Anton Vinogradov : >> >>> Also, is it possible to perform the same check on the merge attempt? >>> >>> Each PR can be merged from GitHub page, can we append check to the "megre >>> button" flow? >>> Can we restrict merges bypassing this button? >>> >>> On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov wrote: >>> >>> > Should we perform an additional compilation attempt on pull/xxx/merge >>> at >>> > each visa request? >>> > >>> > On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn >>> > wrote: >>> > >>> >> > Main question is "how this may happen in case fix got the Visa [2] >>> ?". >>> >> This can happen because of other changes in master. >>> >> "Visa" truly works only when master is in the same state during the >>> merge >>> >> as it was during TC run. >>> >> >>> >> On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov >>> wrote: >>> >> >>> >> > It seems, this because of IGNITE-12227 fix [1]. >>> >> > Main question is "how this may happen in case fix got the Visa [2] >>> ?". >>> >> > >>> >> > [1] >>> >> > >>> >> > >>> >> >>> https://ci.ignite.apache.org/viewModification.html?modId=895719=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles >>> >> > [2] >>> >> > >>> >> > >>> >> >>> https://issues.apache.org/jira/browse/IGNITE-12227?focusedCommentId=17018135=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17018135 >>> >> > >>> >> > On Mon, Jan 20, 2020 at 1:43 PM Николай Ижиков >> > >>> >> > wrote: >>> >> > >>> >> > > Hello. Igniters. >>> >> > > >>> >> > > Master build fails: >>> >> > > >>> >> > > >>> >> > > >>> >> > >>> >> >>> https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead >>> >> > > >>> >> > > [13:37:02][Step 3/4] [ERROR] Failed to execute goal >>> >> > > org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile >>> >> > > (default-testCompile) on project ignite-core: Compilation failure: >>> >> > > Compilation failure: >>> >> > > [13:37:02][Step 3/4] [ERROR] >>> >> > > >>> >> > >>> >> >>> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[25,1] >>> >> > > cannot find symbol >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: static >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class >>> >> > > [13:37:02][Step 3/4] [ERROR] >>> >> > > >>> >> > >>> >> >>> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateAbstractTest.java:[162,28] >>> >> > > cannot find symbol >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class >>> >> > > >>> >> > >>> >> >>> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateAbstractTest >>> >> > > [13:37:02][Step 3/4] [ERROR] >>> >> > > >>> >> > >>> >> >>> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[40,28] >>> >> > > cannot find symbol >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class >>> >> > > >>> >> > >>> >> >>> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest >>> >> > > [13:37:02][Step 3/4] [ERROR] >>> >> > > >>> >> > >>> >> >>> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/transactions/TxPartitionCounterStateConsistencyVolatileRebalanceTest.java:[47,30] >>> >> > > cannot find symbol >>> >> > > [13:37:02][Step 3/4] [ERROR] symbol: variable >>> >> > > IGNITE_BASELINE_AUTO_ADJUST_ENABLED >>> >> > > [13:37:02][Step 3/4] [ERROR] location: class >>> >> > > >>> >> > >>> >> >>> org.apache.ignite.internal.processors.cache.transactions.TxPartitionCounterStateConsistencyVolatileRebalanceTest >>> >> > > >>> >> > > >>> >> > >>> >> >>> > >>> >>
[jira] [Created] (IGNITE-12556) Online Dev Tools
Stephen created IGNITE-12556: Summary: Online Dev Tools Key: IGNITE-12556 URL: https://issues.apache.org/jira/browse/IGNITE-12556 Project: Ignite Issue Type: Bug Environment: https://onlinedevtools.in check this link useful web developer tools link https://onlinedevtools.in/lodash_underscore_alternative https://onlinedevtools.in/online/sqlformatter https://onlinedevtools.in/online/npmpackageanalyzer https://onlinedevtools.in/curl https://onlinedevtools.in/crontab https://onlinedevtools.in/devnews https://diffviewer.onlinedevtools.in Reporter: Stephen https://onlinedevtools.in check this link useful web developer tools link https://onlinedevtools.in/lodash_underscore_alternative https://onlinedevtools.in/online/sqlformatter https://onlinedevtools.in/online/npmpackageanalyzer https://onlinedevtools.in/curl https://onlinedevtools.in/crontab https://onlinedevtools.in/devnews https://diffviewer.onlinedevtools.in -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Thin client: compute support
Sorry for the late reply. Approach with taskId will require a lot of changes in protocol and thus more "heavy" for implementation, but it definitely looks to me less hacky than reqId-approach. Moreover, as was mentioned, server notifications mechanism will be required in a future anyway with high probability. So from this point of view I like taskId-approach. On the other hand, what we should also consider here is performance. Speaking of latency, it looks like reqId will have better results in case of small and fast tasks. The only question here, if we want to optimize thin clients for this case. Also, what are you talking about mostly involves clients on platforms that already have Compute API for thick clients. Let me mention one more point of view here and another concern here. The changes you propose are going to change protocol version for sure. In case with taskId approach and server notifications - even more so. But such clients as Python, Node.js, PHP, Go most probably won't have support for this API, at least for now. Or never. But current backward-compatibility mechanism implies protocol versions where we imply that client that supports version 1.5 also supports all the features introduced in all the previous versions of the protocol. Thus implementing Compute API in any of the proposed ways *may* force mentioned clients to support changes in protocol which they not necessarily need in order to introduce new features in the future. So, maybe it's a good time for us to change our backward compatibility mechanism from protocol versioning to feature masks? WDYT? Best Regards, Igor On Fri, Jan 17, 2020 at 9:37 AM Alex Plehanov wrote: > Looks like we didn't rich consensus here. > > Igor, as thin client maintainer, can you please share your opinion? > > Everyone else also welcome, please share your thoughts about options to > implement operations for compute. > > > чт, 28 нояб. 2019 г. в 10:02, Alex Plehanov : > > > > Since all thin client operations are inherently async, we should be > able > > to cancel any of them > > It's illogical to have such ability. What should do cancel operation of > > cancel operation? Moreover, sometimes it's dangerous, for example, create > > cache operation should never be canceled. There should be an explicit set > > of processes that we can cancel: queries, transactions, tasks, services. > > The lifecycle of services is more complex than the lifecycle of tasks. > With > > services, I suppose, we can't use request cancelation, so tasks will be > the > > only process with an exceptional pattern. > > > > > The request would be "execute task with specified node filter" - simple > > and efficient. > > It's not simple: every compute or service request should contain complex > > node filtering logic, which duplicates the same logic for cluster API. > > It's not efficient: for example, we can't implement forPredicate() > > filtering in this case. > > > > > > ср, 27 нояб. 2019 г. в 19:25, Pavel Tupitsyn : > > > >> > The request is already processed (task is started), we can't cancel > the > >> request > >> The request is not "start a task". It is "execute task" (and get > result). > >> Same as "cache get" - you get a result in the end, we don't "start cache > >> get" then "end cache get". > >> > >> Since all thin client operations are inherently async, we should be able > >> to > >> cancel any of them > >> by sending another request with an id of prior request to be cancelled. > >> That's why I'm advocating for this approach - it will work for anything, > >> no > >> special cases. > >> And it keeps "happy path" as simple as it is right now. > >> > >> Queries are different because we retrieve results in pages, we can't do > >> them as one request. > >> Transactions are also different because client controls when they should > >> end. > >> There is no reason for task execution to be a special case like queries > or > >> transactions. > >> > >> > we always need to send 2 requests to server to execute the task > >> Nope. We don't need to get nodes on client at all. > >> The request would be "execute task with specified node filter" - simple > >> and > >> efficient. > >> > >> > >> On Wed, Nov 27, 2019 at 4:31 PM Alex Plehanov > >> wrote: > >> > >> > > We do cancel a request to perform a task. We may and should use > this > >> to > >> > cancel any other request in future. > >> > The request is already processed (task is started), we can't cancel > the > >> > request. As you mentioned before, we already do almost the same for > >> queries > >> > (close the cursor, but not cancel the request to run a query), it's > >> better > >> > to do such things in a common way. We have a pattern: start some > process > >> > (query, transaction), get id of this process, end process by this id. > >> The > >> > "Execute task" process should match the same pattern. In my opinion, > >> > implementation with two-way requests is the best option to match this > >> > pattern (we can even
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, There is an issue [1] caused by page list caching [2], which also affects 2.8 release. IgniteOutOfMemoryException can be thrown in some cases (data region is small, a checkpoint is triggered by "too many dirty pages" reason and pages list cache is rather big). The fix is ready and merged to master, I suggest to include this fix to 2.8 release. What do you think? [1]: https://issues.apache.org/jira/browse/IGNITE-12530 [2]: https://issues.apache.org/jira/browse/IGNITE-6930 пн, 20 янв. 2020 г. в 12:57, Alexey Goncharuk : > Maxim, > > I took a quick look at IGNITE-12456 and I am not sure it's about data > corruption. In the attached logs blocked system threads are reported, > however, there is no enough information to investigate the issue (the full > thread dump was not attached). I asked the ticket creator to attach missing > pieces. > > Should we consider moving this ticket to a next release? > > пн, 20 янв. 2020 г. в 08:54, Zhenya Stanilovsky >: > > > > > Maxim, performance fix issue [1] already in master, if no objections, can > > u merge it into 2.8 ? Thanks ! > > [1] https://issues.apache.org/jira/browse/IGNITE-12547 > > > > >Igniters, > > > > > > > > >Here is the actual list of BLOCKER release issues: > > > > > >IGNITE-12456 Cluster Data Store grid gets Corrupted for Load test > > >*[Unassigned]* OPEN > > >IGNITE-12489 Error during purges by expiration: Unknown page type* > > >[Unassigned]* OPEN > > >IGNITE-8641 SpringDataExample should use example-ignite.xml config > > >*[Unassigned]* OPEN > > > > > >IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes > > getting > > >down [Emmanouil Gkatziouras] OPEN > > >IGNITE-9184 Cluster hangs during concurrent node client and server nodes > > >restart [Dmitriy Sorokin] IN PROGRESS > > >IGNITE-12553 [IEP-35] public Java metric API Improvement [Nikolay > Izhikov] > > >Blocker IN PROGRESS > > > > > >IGNITE-12227 Default auto-adjust baseline enabled flag calculated > > >incorrectly [Anton Kalashnikov] PATCH AVAILABLE > > >IGNITE-12470 Pme-free switch feature should be deactivatable [Sergei > > >Ryzhov] PATCH AVAILABLE > > >IGNITE-12552 [IEP-35] Expose MetricRegistry to the public API > Improvement > > >[Nikolay Izhikov] PATCH AVAILABLE > > > > > > > > >[1] https://issues.apache.org/jira/browse/IGNITE-12456 > > >[2] https://issues.apache.org/jira/browse/IGNITE-12489 > > >[3] https://issues.apache.org/jira/browse/IGNITE-8641 > > >[8] https://issues.apache.org/jira/browse/IGNITE-12398 > > >[3] https://issues.apache.org/jira/browse/IGNITE-9184 > > >[6] https://issues.apache.org/jira/browse/IGNITE-12553 > > >[7] https://issues.apache.org/jira/browse/IGNITE-12227 > > >[9] https://issues.apache.org/jira/browse/IGNITE-12470 > > >[5] https://issues.apache.org/jira/browse/IGNITE-12552 > > > > > > > > >On Sat, 18 Jan 2020 at 19:11, Sergey Antonov < > antonovserge...@gmail.com > > > > > >wrote: > > > > > >> Maxim, > > >> > > >> Conflicts in pr [1] are resolved. TC Run all is started. > > >> > > >> [1] https://github.com/apache/ignite/pull/7238 > > >> > > >> пт, 17 янв. 2020 г. в 16:04, Sergey Antonov < > antonovserge...@gmail.com > > >: > > >> > > >>> Maxim, > > >>> > > >>> I will do that on monday (20/01). > > >>> > > >>> пт, 17 янв. 2020 г. в 13:08, Maxim Muzafarov < mmu...@apache.org >: > > >>> > > Sergey, > > > > > > Can you, please, resolve the PR conflicts [1] [2]? > > > > [1] https://github.com/apache/ignite/pull/7238 > > [2] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > On Thu, 16 Jan 2020 at 16:59, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > wrote: > > > > > > Hello! > > > > > > I have bumped beanutils and re-ran Cassandra Store tests. Can you > > please > > > comment on the ticket? > > > > > > I think that fixing ZooKeeper is too much effort (there's chaos > with > > > jackson vs. jackson-asl), maybe it should be split up as a > separate > > ticket > > > to be done later. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > ср, 15 янв. 2020 г. в 18:31, Vladimir Pligin < > vova199...@yandex.ru > > >: > > > > > > > Thanks, Ilya. It would be really great to have your patch > included > > into 2.8 > > > > scope. > > > > I'd like to give my two cent as well. For example we have > > vulnerable > > > > dependencies here: > > > > modules/cassandra/store/pom.xml - commons-beanutils > > > > modules/zookeeper/pom.xml - transitive Jackson from Curator > > > > > > > > I'd suggest to uprgrade commons-beanutils:commons-beanutils to > > 1.9.4 > > and > > > > override com.fasterxml.jackson.core:jackson-databind to our > common > > jackson > > > > version from other modules. > > > > > > > > > > > > > > > > -- > > > > Sent from: > >
[MTCGA]: new failures in builds [4944095] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master [Javadoc] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Javadoc?branch=%3Cdefault%3E Changes may lead to failure were done by - anton kalashnikov https://ci.ignite.apache.org/viewModification.html?modId=895719 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 16:11:24 20-01-2020
Re: Internal classes are exposed in public API
Nikolay, Should we wait for both of the tickets given that we agreed that we are putting an experimental marker on the new APIs? I'm ok to fix only the first one and add the experimental marker so that we do not delay 2.8 release. пн, 20 янв. 2020 г. в 13:32, Николай Ижиков : > Andrey. > > Let’s move from the long letters to the code. > If you want to change API - please, propose this changes. > I think everybody wins if we make our API better. > > Please, describe proposed changes. > It would be great if you have some examples or PR for it. > > As for this release, I have plans to contribute tickets > «[IEP-35] Expose MetricRegistry to the public API» [1] and > «[IEP-35] public Java metric API» [2] for it. > > Any objections on it? > > [1] https://github.com/apache/ignite/pull/7269 > [2] https://issues.apache.org/jira/browse/IGNITE-12553 > > > > 20 янв. 2020 г., в 13:08, Andrey Gura написал(а): > > > > It solves problem. > > > > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk > > wrote: > >> > >> After giving it some thought, I agree with Denis - there is nothing > wrong > >> with exposing the new APIs, we just need to make it clear that we are > still > >> going to change it. > >> > >> Should we Introduce something like @IgniteExperimental annotation (I > >> believe it has been discussed a dozen of times on the dev-list)? > >> > >> пт, 17 янв. 2020 г. в 23:28, Nikolay Izhikov : > >> > >>> +1 to mark feature or whole release as EA. > >>> > >>> пт, 17 янв. 2020 г., 23:00 Denis Magda : > >>> > Folks, if you don't mind I'll share some thoughts/suggestions as an > observer who was not involved in the feature development. > > It's absolutely 'ok' to deprecate an API that is replaced with a much > better version. However, we should do this only when the new APIs are > production-ready. If there are still many limitations or open items > then > don't deprecate anything that exists and release the new APIs > labeling as > early access. What if release the improvements labeling as EA instead > of > hiding them completely? > > I would also encourage us to put aside emotions, don't blame or point > fingers. This IEP is a great initiative and you both have already > done a > tremendous job by developing, architecting and reviewing changes. > Just be > respectful. Nobody is trying to block the feature from being released. > Everyone would be glad to tap into improvements and start using them > in > prod. But if more time is needed for the GA let's reiterate a bit. > > - > Denis > > > On Fri, Jan 17, 2020 at 12:24 PM Николай Ижиков > wrote: > > >> Also I agree with Alexey about introducing public IgniteMonitoring > facade > > > > This is not an issue with the API. > > Just the new feature that doesn’t affects API. > > Moreover, I create a ticket to fix it, already. > > > >> It's right. But if you add checking of statisticsEnabling property > >>> then > > test will fail. It's just not good tests. > > > > My changes doesn’t affect any `staticticsEnabled` property. > > I don’ understand your point here. > > > >> Redundant ReadOnlyMetricRegistry. > > > > It’s not redundant. > > It required for exporters and provide read only access to > >>> MetricRegistry > > existing in the node. > > > > > >> MetricExporterSpi that requires ReadOnlyMetricRegistry. > > > >> Absence of newly created metrics in old MBeans that forces user use > >> exporter SPI while his code base uses old MBeans. > > > > Why this is issue? > > > >> Inconsistent MetricRegistry API. > > > > It’s consistent. > > > >> Metrics lookups from map instead of using direct reference > >> (performance problem). > > > > 1. We(You and I) did this choice together to simplify creation of the > >>> new > > metrics. > > 2. This is not public API issue. > > > > > >> Ignoring of statisticsEnabled flag. > > > > I don’t ignore this flag. > > It just doesn’t exists in new framework(because of scope). > > I don’t think it’s an issue. > > > >> JmxExporterSpi creates beans that doesn't satisfy best MBeans > practices. > > > > Please, clarify your statement. > > What is best MBeans practices you are talking about? > > > >> Not finished IGNITE-11927 > > > > > > How this can be API issue? > > > > > >> 17 янв. 2020 г., в 20:52, Andrey Gura > написал(а): > >> > All issues Alexey mentioned in starting letter are fixed with my > PR > > [1]. > I don’t think other issues you mentioned are blocker for the > >>> release. > >> > >> As I mentioned already IGNITE-11927 is part of IEP-35 and > >> implementation seriously affects API's. Also I agree with Alexey > >>> about > >> introducing public
