Re: Test naming on TC JUnit 5
Also, according to IGNITE-10973 [1] (in nutshell: maven dependencies + migration Examples module), we are ready for JUnit 5. What is a strategy for massive migration? [1] https://issues.apache.org/jira/browse/IGNITE-10973 чт, 25 июл. 2019 г. в 14:33, Ivan Fedotov : > Hi Dmitriy. > > Thank you for your reply, re-running concrete test cases, not a suite, is > another one utility of JUnit 5. > > I want to pay your (and other Igniters) attention on .net tests. I faced > with failure "The filename or extension is too long" in ExecutableTest [1]. > The problem is in jvmClasspath because other args are hardcoded. After > comparison log files from my branch [2] and master [3] I found that > jvmClasspath variable contains all maven dependencies. I added more > dependencies to parent/pom file and mentioned string becomes too long for > system .net function. > > I think that the problem is in Classpath.cs#CreateClasspath method: if we > want to add more dependencies to Ignite project (not necessary JUnit, any > dependency) it will lead to the same problem. Furthermore, jvmClasspath > variable contains an enumeration of all jar files. > > Is it correct behavior of CreateClasspath method or we need to change its > implementation? > > [1] > https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148 > [2] > https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning > [3] > https://ci.ignite.apache.org/viewLog.html?buildId=4394312=IgniteTests24Java8_PlatformNetLongRunning=testsInfo > > > чт, 25 июл. 2019 г. в 10:11, Dmitriy Pavlov : > >> Hi Ivan. >> >> Yes, test name changes (reported by TC), would be a short term issue, but >> TC bot will accumulate statistics quite fast. >> >> We can consider applying changes before a weekend, so the maximum number >> of >> re-runs occur; so the maximum statistic is the outcome. >> >> Moreover, the test name change may have a positive effect in long-term, >> because of a re-run of a particular suite on TC has exactly the same >> impact >> on test name. It will be a path to test case wihtout suite. >> So for now, Re-run possible blockers activate the whole suite, but when >> all >> tests change their names, TC bot could activate only some test case(s) >> with >> a test(s) failure to rerun. It could also bring faster detection of master >> failures. >> >> Sincerely, >> Dmitriy Pavlov >> >> пн, 22 июл. 2019 г. в 20:10, Ivan Fedotov : >> >> > Hi, igniters! >> > >> > In the context of IEP-30 and IGNITE-10958 in particular [1], the JUnit5 >> > tests are going to appear in master. >> > >> > During migration Ignite on JUnit5 I faced that the test naming will be >> > changed. >> > The names are different, in the version before path consists from "path >> to >> > suite: path to test" [2] and in the version after just "path to test" >> [3]. >> > I want to inform you that it will lead to obsolete current history for >> some >> > tests: see tests with label "History for base branch is absent" [4]. It >> > means that TC bot shows those tests as blockers because of a different >> > name, but indeed tests were red on JUnit 4 version also. After some >> time in >> > the new version of JUnit we will get a history for mentioned tests >> again. >> > >> > Do have some of us have questions/comments according to migration? >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-10973 >> > [2] >> > >> > >> https://ci.ignite.apache.org/project.html?tab=testDetails_IgniteTests24Java8=%3Cdefault%3E=IgniteTests24Java8=680055112352967935=1 >> > [3] >> > >> > >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8375541702052870683=%3Cdefault%3E=testDetails_IgniteTests24Java8=__all_branches__ >> > [4] >> > >> > >> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest >> > -- >> > Ivan Fedotov. >> > >> > ivanan...@gmail.com >> > >> > > > -- > Ivan Fedotov. > > ivanan...@gmail.com > -- Ivan Fedotov. ivanan...@gmail.com
Re: Test naming on TC JUnit 5
Hi Dmitriy. Thank you for your reply, re-running concrete test cases, not a suite, is another one utility of JUnit 5. I want to pay your (and other Igniters) attention on .net tests. I faced with failure "The filename or extension is too long" in ExecutableTest [1]. The problem is in jvmClasspath because other args are hardcoded. After comparison log files from my branch [2] and master [3] I found that jvmClasspath variable contains all maven dependencies. I added more dependencies to parent/pom file and mentioned string becomes too long for system .net function. I think that the problem is in Classpath.cs#CreateClasspath method: if we want to add more dependencies to Ignite project (not necessary JUnit, any dependency) it will lead to the same problem. Furthermore, jvmClasspath variable contains an enumeration of all jar files. Is it correct behavior of CreateClasspath method or we need to change its implementation? [1] https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148 [2] https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning [3] https://ci.ignite.apache.org/viewLog.html?buildId=4394312=IgniteTests24Java8_PlatformNetLongRunning=testsInfo чт, 25 июл. 2019 г. в 10:11, Dmitriy Pavlov : > Hi Ivan. > > Yes, test name changes (reported by TC), would be a short term issue, but > TC bot will accumulate statistics quite fast. > > We can consider applying changes before a weekend, so the maximum number of > re-runs occur; so the maximum statistic is the outcome. > > Moreover, the test name change may have a positive effect in long-term, > because of a re-run of a particular suite on TC has exactly the same impact > on test name. It will be a path to test case wihtout suite. > So for now, Re-run possible blockers activate the whole suite, but when all > tests change their names, TC bot could activate only some test case(s) with > a test(s) failure to rerun. It could also bring faster detection of master > failures. > > Sincerely, > Dmitriy Pavlov > > пн, 22 июл. 2019 г. в 20:10, Ivan Fedotov : > > > Hi, igniters! > > > > In the context of IEP-30 and IGNITE-10958 in particular [1], the JUnit5 > > tests are going to appear in master. > > > > During migration Ignite on JUnit5 I faced that the test naming will be > > changed. > > The names are different, in the version before path consists from "path > to > > suite: path to test" [2] and in the version after just "path to test" > [3]. > > I want to inform you that it will lead to obsolete current history for > some > > tests: see tests with label "History for base branch is absent" [4]. It > > means that TC bot shows those tests as blockers because of a different > > name, but indeed tests were red on JUnit 4 version also. After some time > in > > the new version of JUnit we will get a history for mentioned tests again. > > > > Do have some of us have questions/comments according to migration? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10973 > > [2] > > > > > https://ci.ignite.apache.org/project.html?tab=testDetails_IgniteTests24Java8=%3Cdefault%3E=IgniteTests24Java8=680055112352967935=1 > > [3] > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8375541702052870683=%3Cdefault%3E=testDetails_IgniteTests24Java8=__all_branches__ > > [4] > > > > > https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest > > -- > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > -- Ivan Fedotov. ivanan...@gmail.com
Test naming on TC JUnit 5
Hi, igniters! In the context of IEP-30 and IGNITE-10958 in particular [1], the JUnit5 tests are going to appear in master. During migration Ignite on JUnit5 I faced that the test naming will be changed. The names are different, in the version before path consists from "path to suite: path to test" [2] and in the version after just "path to test" [3]. I want to inform you that it will lead to obsolete current history for some tests: see tests with label "History for base branch is absent" [4]. It means that TC bot shows those tests as blockers because of a different name, but indeed tests were red on JUnit 4 version also. After some time in the new version of JUnit we will get a history for mentioned tests again. Do have some of us have questions/comments according to migration? [1] https://issues.apache.org/jira/browse/IGNITE-10973 [2] https://ci.ignite.apache.org/project.html?tab=testDetails_IgniteTests24Java8=%3Cdefault%3E=IgniteTests24Java8=680055112352967935=1 [3] https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8375541702052870683=%3Cdefault%3E=testDetails_IgniteTests24Java8=__all_branches__ [4] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest -- Ivan Fedotov. ivanan...@gmail.com
Re: Migration to JUnit 5
Ivan, thank you for clarification. If nobody is against I can uncomment them in the context of IGNITE-711. пт, 5 июл. 2019 г. в 11:33, Павлухин Иван : > Ivan, > > I think that it is a really good that you found those not tested > examples. Thank you! > > пт, 5 июл. 2019 г. в 11:31, Павлухин Иван : > > > > Ivan, > > > > I uncommented all tests referring to IGNITE-711 [1] in > > BasicExamplesSelfTest and all they passed. > > > > Generally, example tests are needed to be sure that our examples > > launch. And commented tests refer to existing examples. So, an ideal > > way here is to uncomment them in scope of IGNITE-711 [1], removal is > > not a good option. And I do not expect much problems here because we > > fully support Java 8 for a long time. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-711 > > > > пн, 1 июл. 2019 г. в 17:10, Ivan Fedotov : > > > > > > Hi, Igniters > > > > > > During work on IEP-30, which is about JUnit migration, I found that > some > > > tests in examples module were commented [1] with the remark, that they > > > should be fixed in the ticket IGNITE-711 [2] which is about the > > > implementation of Java 8 examples. > > > > > > In the context of the ticket IGNITE-10973 [3] I want to uncomment them > and > > > mark as @Disabled. Is it really need to disable mentioned tests or I > can > > > just remove them as outdated? > > > > > > [1] > > > > https://github.com/apache/ignite/pull/6606/files#diff-ed48193d25d777a2c30c187fa20a1a65L65 > > > [2] https://issues.apache.org/jira/browse/IGNITE-711 > > > [3] https://issues.apache.org/jira/browse/IGNITE-10973 > > > > > > > > > вт, 26 февр. 2019 г. в 18:51, Ivan Fedotov : > > > > > > > Ivan, > > > > I will investigate GridAbstractTest refactoring issue more precisely > when > > > > I finish with JUnit3Legacy classes. Anyway, I will keep in touch > with you > > > > and the community on the most significant moments. > > > > > > > > JUnit5 docs say that functionality is not full "especially with > regard to > > > > reporting". On the other hand, I also agree with docs that it is the > > > > easiest way that does not require to touch CI infrastructure. I am > going to > > > > try @RunWith(JUnitPlatform.class) construction with features from > IEP to > > > > make sure that we will have the full support of them. The > alternative way > > > > is dynamic tests [1], but the problem is that we add methods to > suites > > > > manually, not via @Test annotation. It is some kind of rollback to > JUnit3 > > > > syntax. > > > > > > > > Anton, > > > > thank you for the reminder, I will update IEP according to the > > > > conversation. > > > > > > > > [1] https://www.baeldung.com/junit5-dynamic-tests > > > > > > > > вт, 26 февр. 2019 г. в 17:56, Anton Vinogradov : > > > > > > > >> Folks, > > > >> > > > >> Please make sure you keep IEP updated and each issue mentioned. > > > >> > > > >> On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван > > > >> wrote: > > > >> > > > >> > Ivan, > > > >> > > > > >> > Thank you for detailed answers! I would put a great care to > > > >> > @RunWith(JUnitPlatform.class) construction. As stated in junit5 > docs > > > >> > [1] it does not support all features and unfortunately it is not > clear > > > >> > how limited it is. Also, it is some kind of transitional mechanism > > > >> > which was not designed for being a long term solution. > > > >> > > > > >> > And I fully support an idea of refactoring GridAbstractTest. I > think > > > >> > it is possible to make a significant improvement here. > > > >> > > > > >> > [1] > > > >> > > > > >> > https://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner > > > >> > > > > >> > пн, 25 февр. 2019 г. в 17:41, Ivan Fedotov : > > > >> > > > > > >> > > Hello Nikolay. > > > >> > > > > > >> > > The prime benefits are more comfortable work with flaky tests, > Java 8 > > > &
Re: Migration to JUnit 5
Hi, Igniters
During work on IEP-30, which is about JUnit migration, I found that some
tests in examples module were commented [1] with the remark, that they
should be fixed in the ticket IGNITE-711 [2] which is about the
implementation of Java 8 examples.
In the context of the ticket IGNITE-10973 [3] I want to uncomment them and
mark as @Disabled. Is it really need to disable mentioned tests or I can
just remove them as outdated?
[1]
https://github.com/apache/ignite/pull/6606/files#diff-ed48193d25d777a2c30c187fa20a1a65L65
[2] https://issues.apache.org/jira/browse/IGNITE-711
[3] https://issues.apache.org/jira/browse/IGNITE-10973
вт, 26 февр. 2019 г. в 18:51, Ivan Fedotov :
> Ivan,
> I will investigate GridAbstractTest refactoring issue more precisely when
> I finish with JUnit3Legacy classes. Anyway, I will keep in touch with you
> and the community on the most significant moments.
>
> JUnit5 docs say that functionality is not full "especially with regard to
> reporting". On the other hand, I also agree with docs that it is the
> easiest way that does not require to touch CI infrastructure. I am going to
> try @RunWith(JUnitPlatform.class) construction with features from IEP to
> make sure that we will have the full support of them. The alternative way
> is dynamic tests [1], but the problem is that we add methods to suites
> manually, not via @Test annotation. It is some kind of rollback to JUnit3
> syntax.
>
> Anton,
> thank you for the reminder, I will update IEP according to the
> conversation.
>
> [1] https://www.baeldung.com/junit5-dynamic-tests
>
> вт, 26 февр. 2019 г. в 17:56, Anton Vinogradov :
>
>> Folks,
>>
>> Please make sure you keep IEP updated and each issue mentioned.
>>
>> On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван
>> wrote:
>>
>> > Ivan,
>> >
>> > Thank you for detailed answers! I would put a great care to
>> > @RunWith(JUnitPlatform.class) construction. As stated in junit5 docs
>> > [1] it does not support all features and unfortunately it is not clear
>> > how limited it is. Also, it is some kind of transitional mechanism
>> > which was not designed for being a long term solution.
>> >
>> > And I fully support an idea of refactoring GridAbstractTest. I think
>> > it is possible to make a significant improvement here.
>> >
>> > [1]
>> >
>> https://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner
>> >
>> > пн, 25 февр. 2019 г. в 17:41, Ivan Fedotov :
>> > >
>> > > Hello Nikolay.
>> > >
>> > > The prime benefits are more comfortable work with flaky tests, Java 8
>> > tests
>> > > compatibility, user-friendly syntaxis in parametrized tests and
>> others.
>> > > The most significant features list you can find in IEP-30 Motivation
>> > > section.
>> > >
>> > > If you have any specific questions about JUnit5 feel free to ask me.
>> > >
>> > > пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov :
>> > >
>> > > > Hello, Ivan.
>> > > >
>> > > > May be I miss some mail - if yes, can you repeat it.
>> > > > What is advantages of migration from junit 4 to 5?
>> > > > Why we should do it?
>> > > >
>> > > >
>> > > > пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
>> > > >
>> > > > > Ivan,
>> > > > > That is my thoughts according to your questions.
>> > > > >
>> > > > > 1. I tried to implement test suits with JUnit4 compatibility
>> layer.
>> > The
>> > > > > basic concept is to use @RunWith(JUnitPlatform.class)
>> @SelectClasses
>> > > > > ({...})[1] and on
>> > > > > CI Ignite it works fine.
>> > > > >
>> > > > > 2. According to @Rules, there are several ways to solve it:
>> > > > > 2.1 Leave JUnit4 code without changes. It will work because of
>> > > > Vintage
>> > > > > module
>> > > > > 2.2 Rewrite the @Rule as an Extension. The work of extension
>> is
>> > > > similar
>> > > > > to the @Rules work, but it is extracted in an Extension class.
>> > > > > For more information about extensions, please, follow the IEP
>> > [2].
>> > > > > In my opinion, the easiest and the most understandable way is to
>> > leave
>> > > > > GridAbstractTest in current f
Re: [DISCUSSION][IEP-35] Metrics configuration
Nikolay, I also agree with your approach thank, you for the explanation. One minor remark: maybe it will be better to explicitly indicate in config the type of the metric? In nutshell: HistrogramMetric: cache.my-cahe.GetLatency=50,100,250,500 HitRateMetric: cache.my-cache.RebalancingKeysRate=6 It will simplify work for administrators and let us possibility do not write additional comments for each config and go to metric docs for clarifying - the most information about metric is clear from config. Moreover, it will be easier to order metrics in the config file by type. чт, 27 июн. 2019 г. в 13:55, Nikolay Izhikov : > Hello, Anton. > > Thanks for an answer! > > > Let's just make sure this syntax is extendable. > > Yes, I ~can~ will! > > > I'd like to count only latency greater than 37ms (0-37 - > > ignored, 37-52, 52-infinity - recorded), it should be possible to skip > some > > values. > > Currently, histogram metric don't support this feature. > I have no plans to add it. > > Your contribution are welcome, as always. > > > Another case is to specify 2+ windows for same metric > > AFAIK you are talking about HitRateMetrics. > I have no plans to improve this legacy metric somehow. > > Can you file a ticket with the features you want to add? > > В Чт, 27/06/2019 в 12:56 +0300, Anton Vinogradov пишет: > > Nikolay, > > > > The approach looks good to me. > > Let's just make sure this syntax is extendable. > > For example, I'd like to count only latency greater than 37ms (0-37 - > > ignored, 37-52, 52-infinity - recorded), it should be possible to skip > some > > values. > > Another case is to specify 2+ windows for same metric, eg. puts for last > > hour, minute, 5 seconds. > > > > On Thu, Jun 27, 2019 at 12:30 PM Nikolay Izhikov > > wrote: > > > > > Hello, Igniters. > > > > > > As you may know, I've contributed Phase1 [1] for IEP-35 [2]. > > > Now we have metrics subsystem and can create and export any metrics > from > > > Ignite. > > > > > > I think user(administrator of Ignite) should be able to configure some > > > metrics params in a common way [3] > > > > > > I propose to use the same way from logging frameworks. > > > We should define some file format Ignite can understand. > > > An administrator fills configuration file to configure one or several > > > metrics. > > > Ignite will analyze the file and use provided params during metrics > > > creation. > > > > > > For now, we have 2 types of metrics that should be configured: > > > > > > * HistrogramMetric [4] > > > This metric is a count of measurement that falls into > > > predefined intervals. > > > An example is "Request processing time distribution". > > > We want to calculate a count of requests processed > quicker > > > then 50ms, 50-100, 100-250, 250-500 and slower. > > > > > > * HitRateMetric [5] > > > This metric is a count of events in the last time > interval. > > > An example is the "Count of requests processed in the > last > > > 5 seconds". > > > > > > Example of file content: > > > > > > > > > cache.my-cahe.GetLatency=50,100,250,500 #Params for the histogram > metric > > > with the name `cache.my-cahe.get` > > > cache.my-cache.RebalancingKeysRate=6 #Param for existing > HitRateMetric > > > that hold "Estimated rebalancing speed in keys". > > > > > > > > > Please, share your vision. > > > > > > [1] > > > > https://github.com/apache/ignite/commit/fdaa310430aefff07994eb35510d3416886b5bbe > > > [2] > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=112820392 > > > [3] https://issues.apache.org/jira/browse/IGNITE-11927 > > > [4] > > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/metric/impl/HistogramMetric.java > > > [5] > > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/metric/impl/HitRateMetric.java > > > > -- Ivan Fedotov. ivanan...@gmail.com
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Igniters, I created corresponding tickets [1][2][3][4] in Jira and outlined description of problems in a nutshell. In the context of the current ticket (IGNITE-11708), I ignored them. If some of us have a comprehension of the problem why tests are failed, please let know here or in the tickets. [1] https://issues.apache.org/jira/browse/IGNITE-11883 [2] https://issues.apache.org/jira/browse/IGNITE-11884 [3] https://issues.apache.org/jira/browse/IGNITE-11885 [4] https://issues.apache.org/jira/browse/IGNITE-11886 чт, 30 мая 2019 г. в 14:55, Ivan Fedotov : > Hi Igniters! > > I found the solution for how to run IgniteConfigVariationsAbstractTest. I > removed garbage injection [1] and static variable [2]. > Now assigning of VariationsTestsConfig proceeds in constructor class which > is created dynamically [3]. > > But I faced with the problem that a certain amount of tests are failed. It > seems that they failed because of the real reasons, not because > of the test workflow. Despite those fact that a big amount of tests on TC > became red, really failed tests are not so much. Derivatives tests appear > from > different configs. > > Could some of us take a look on failed tests? I am going to ignore them in > the context of the current ticket [5] and create separate > issues. > > [1] > https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L102 > [2] > https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L84 > [3] > https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R434 > [4] > https://ci.ignite.apache.org/viewLog.html?buildId=3978807=IgniteTests24Java8_RunAllNightly > [5]https://issues.apache.org/jira/browse/IGNITE-11708 > > вт, 14 мая 2019 г. в 16:31, Ivan Pavlukhina : > >> Ivan F., >> >> Agree with referring tickets in @Ignore annotation. >> >> Currently I have no access to a computer. Will be able to look at updated >> PR next week. >> >> Sent from my iPhone >> >> > On 14 May 2019, at 10:55, Ivan Fedotov wrote: >> > >> > Ivan P., >> > I managed with IgniteConfigVariationsAbstractTest - now subclasses >> enable >> > [1]. >> > I ignored all the failed tests that were mentioned in our conversation. >> If >> > you don't mind, I can create appropriate tickets and mention them in >> Ignore >> > annotation. >> > >> > [1] https://github.com/apache/ignite/pull/6434/files >> > >> > ср, 1 мая 2019 г. в 15:29, Павлухин Иван : >> > >> >> Ivan F., >> >> >> >> I think that it is better to enable IgniteConfigVariationsAbstractTest >> >> subclasses first, so no new broken tests will appear. After that we >> >> can fix IgniteConfigVariationsAbstractTest subclasses one by one in >> >> separate ticket(s). >> >> >> >> вт, 30 апр. 2019 г. в 13:23, Ivan Fedotov : >> >>> >> >>> Ivan R., Ivan P., thank you for the suggestions, I took a look at >> them. >> >>> >> >>> According to checking CacheAtomicityMode on null in >> >>> IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure >> >>> that checking should proceed on test level? May be it will be better >> to >> >>> make default cache value in case if cc.getAtomicityMode() == null >> >>> in CacheConfiguration constructor [1]? >> >>> >> >>> Also let me suggest one minor change according cache specification in >> >>> IgniteCacheReadThroughEvictionSelfTest. The same logic is used in >> >>> GridCacheAbstractSelfTest#cacheConfiguration [2]. >> >>> I think we can excract this code block in a separate static methods >> >>> (initCacheConfig, for example) in >> IgniteCacheReadThroughEvictionSelfTest >> >> and >> >>> invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig >> and >> >>> GridCacheAbstractSelfTest#cacheConfiguration methods. >> >>> >> >>> In addition, I want to draw your attention to >> >>> IgniteContinuousQueryConfigVariationsSuite test runs [3]. >> >>> CacheContinuousQueryVariationsTest are generated dynamically. >> >>> The first batch (12 tests) works fine, but on the next runs we got >> NPE in >> >>> IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does >> >> not >> >>> exist and we can not >> >>> invoke unwrap() on this [4].
[jira] [Created] (IGNITE-11886) Unable to check query result in IgniteCacheConfigVariationsQueryTest
Ivan Fedotov created IGNITE-11886: - Summary: Unable to check query result in IgniteCacheConfigVariationsQueryTest Key: IGNITE-11886 URL: https://issues.apache.org/jira/browse/IGNITE-11886 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest IgniteCacheConfigVariationsQueryTest #testLocalScanQuery and testScanQueryLocalFilter became failed [1]. Not all predicates were executed during query - failed to check execEvtLatch. [1] https://ci.ignite.apache.org/viewLog.html?buildId=3978709=IgniteTests24Java8_QueriesConfigVariations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11885) Tests from IgniteCacheConfigVariationsFullApiTest failed on TC
Ivan Fedotov created IGNITE-11885: - Summary: Tests from IgniteCacheConfigVariationsFullApiTest failed on TC Key: IGNITE-11885 URL: https://issues.apache.org/jira/browse/IGNITE-11885 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest multiple tests in IgniteCacheConfigVariationsFullApiTest became failed [1]. The reason is that the expected value was not found in the cache, but deeper reason for each test can be different - this issue must be investigated. [1] https://ci.ignite.apache.org/viewLog.html?buildId=3978681=IgniteTests24Java8_CacheFullApiBasicConfigVariations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11884) Time outed invokeAll tests in WithKeepBinaryCacheFullApiTest
Ivan Fedotov created IGNITE-11884: - Summary: Time outed invokeAll tests in WithKeepBinaryCacheFullApiTest Key: IGNITE-11884 URL: https://issues.apache.org/jira/browse/IGNITE-11884 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest 2 tests in WithKeepBinaryCacheFullApiTest became failed: testInvokeAll and testInvokeAllAsync. Tests failed because of time out [1]. [1] https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_CacheFullApiConfigVariations=3978682 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy
Ivan Fedotov created IGNITE-11883: - Summary: Unable to find keys in testKeyAffinityDeploy Key: IGNITE-11883 URL: https://issues.apache.org/jira/browse/IGNITE-11883 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov After turn on IgniteConfigVariationsAbstractTest IgniteServiceConfigVariationsFullApiTest#testKeyAffinityDeploy became failed - "Unable to find 1 required keys" [1]. It is necessary to investigate the reason and fix the test. [1] https://ci.ignite.apache.org/viewLog.html?buildId=3978784=buildResultsDiv=IgniteTests24Java8_ServiceGridLegacyMode#testNameId5798659135386117314 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Hi Igniters! I found the solution for how to run IgniteConfigVariationsAbstractTest. I removed garbage injection [1] and static variable [2]. Now assigning of VariationsTestsConfig proceeds in constructor class which is created dynamically [3]. But I faced with the problem that a certain amount of tests are failed. It seems that they failed because of the real reasons, not because of the test workflow. Despite those fact that a big amount of tests on TC became red, really failed tests are not so much. Derivatives tests appear from different configs. Could some of us take a look on failed tests? I am going to ignore them in the context of the current ticket [5] and create separate issues. [1] https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L102 [2] https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L84 [3] https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R434 [4] https://ci.ignite.apache.org/viewLog.html?buildId=3978807=IgniteTests24Java8_RunAllNightly [5]https://issues.apache.org/jira/browse/IGNITE-11708 вт, 14 мая 2019 г. в 16:31, Ivan Pavlukhina : > Ivan F., > > Agree with referring tickets in @Ignore annotation. > > Currently I have no access to a computer. Will be able to look at updated > PR next week. > > Sent from my iPhone > > > On 14 May 2019, at 10:55, Ivan Fedotov wrote: > > > > Ivan P., > > I managed with IgniteConfigVariationsAbstractTest - now subclasses enable > > [1]. > > I ignored all the failed tests that were mentioned in our conversation. > If > > you don't mind, I can create appropriate tickets and mention them in > Ignore > > annotation. > > > > [1] https://github.com/apache/ignite/pull/6434/files > > > > ср, 1 мая 2019 г. в 15:29, Павлухин Иван : > > > >> Ivan F., > >> > >> I think that it is better to enable IgniteConfigVariationsAbstractTest > >> subclasses first, so no new broken tests will appear. After that we > >> can fix IgniteConfigVariationsAbstractTest subclasses one by one in > >> separate ticket(s). > >> > >> вт, 30 апр. 2019 г. в 13:23, Ivan Fedotov : > >>> > >>> Ivan R., Ivan P., thank you for the suggestions, I took a look at them. > >>> > >>> According to checking CacheAtomicityMode on null in > >>> IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure > >>> that checking should proceed on test level? May be it will be better to > >>> make default cache value in case if cc.getAtomicityMode() == null > >>> in CacheConfiguration constructor [1]? > >>> > >>> Also let me suggest one minor change according cache specification in > >>> IgniteCacheReadThroughEvictionSelfTest. The same logic is used in > >>> GridCacheAbstractSelfTest#cacheConfiguration [2]. > >>> I think we can excract this code block in a separate static methods > >>> (initCacheConfig, for example) in > IgniteCacheReadThroughEvictionSelfTest > >> and > >>> invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig and > >>> GridCacheAbstractSelfTest#cacheConfiguration methods. > >>> > >>> In addition, I want to draw your attention to > >>> IgniteContinuousQueryConfigVariationsSuite test runs [3]. > >>> CacheContinuousQueryVariationsTest are generated dynamically. > >>> The first batch (12 tests) works fine, but on the next runs we got NPE > in > >>> IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does > >> not > >>> exist and we can not > >>> invoke unwrap() on this [4]. > >>> Seems that the problem is in > >>> > >> > IgniteCacheConfigVariationsAbstractTest#beforeTestsStarted/afterTestsStopped > >>> methods, cache is not properly created (or already existed cache is > >>> destroyed). > >>> > >>> By the way, should I resolve these issues in the context of > IGNITE-11708 > >> or > >>> create a separate ticket(s)? > >>> > >>> [1] > >>> > >> > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java#L434 > >>> [2] > >>> > >> > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheAbstractSelfTest.java#L235 > >>> [3] > >>> > >> > https://ci.ignite.apache.org/viewLog.html?buildId=3701865=Ignite
[jira] [Created] (IGNITE-11851) Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch
Ivan Fedotov created IGNITE-11851: - Summary: Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch Key: IGNITE-11851 URL: https://issues.apache.org/jira/browse/IGNITE-11851 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov IgniteContinuousQueryConfigVariationsSuite tests are generated dynamically. The first batch (12 tests) runs without problems, but on next batches we got an exception - default cache does not exist and we can not invoke unrwap() method on it [1]. It seems that cache is destroyed after the first batch and is not created on the next one. [1] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11850) Missing check atomicity mode on null
Ivan Fedotov created IGNITE-11850: - Summary: Missing check atomicity mode on null Key: IGNITE-11850 URL: https://issues.apache.org/jira/browse/IGNITE-11850 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov In IgniteCacheConfigVariationsFullApiTest#testGetOutTx test fail occurs. getAtomicityMode() method can return null, but test scenario does not take it into consideration. Default cache atomicity mode must be used in case if getAtomicityMode() returns null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
Ivan Fedotov created IGNITE-11849: - Summary: Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest Key: IGNITE-11849 URL: https://issues.apache.org/jira/browse/IGNITE-11849 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov According to the test scenario after expiration entry must be present in IgniteCache - it will be loaded from CacheStore. It is necessary to specify CacheStore in node config. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan P., I managed with IgniteConfigVariationsAbstractTest - now subclasses enable [1]. I ignored all the failed tests that were mentioned in our conversation. If you don't mind, I can create appropriate tickets and mention them in Ignore annotation. [1] https://github.com/apache/ignite/pull/6434/files ср, 1 мая 2019 г. в 15:29, Павлухин Иван : > Ivan F., > > I think that it is better to enable IgniteConfigVariationsAbstractTest > subclasses first, so no new broken tests will appear. After that we > can fix IgniteConfigVariationsAbstractTest subclasses one by one in > separate ticket(s). > > вт, 30 апр. 2019 г. в 13:23, Ivan Fedotov : > > > > Ivan R., Ivan P., thank you for the suggestions, I took a look at them. > > > > According to checking CacheAtomicityMode on null in > > IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure > > that checking should proceed on test level? May be it will be better to > > make default cache value in case if cc.getAtomicityMode() == null > > in CacheConfiguration constructor [1]? > > > > Also let me suggest one minor change according cache specification in > > IgniteCacheReadThroughEvictionSelfTest. The same logic is used in > > GridCacheAbstractSelfTest#cacheConfiguration [2]. > > I think we can excract this code block in a separate static methods > > (initCacheConfig, for example) in IgniteCacheReadThroughEvictionSelfTest > and > > invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig and > > GridCacheAbstractSelfTest#cacheConfiguration methods. > > > > In addition, I want to draw your attention to > > IgniteContinuousQueryConfigVariationsSuite test runs [3]. > > CacheContinuousQueryVariationsTest are generated dynamically. > > The first batch (12 tests) works fine, but on the next runs we got NPE in > > IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does > not > > exist and we can not > > invoke unwrap() on this [4]. > > Seems that the problem is in > > > IgniteCacheConfigVariationsAbstractTest#beforeTestsStarted/afterTestsStopped > > methods, cache is not properly created (or already existed cache is > > destroyed). > > > > By the way, should I resolve these issues in the context of IGNITE-11708 > or > > create a separate ticket(s)? > > > > [1] > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java#L434 > > [2] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheAbstractSelfTest.java#L235 > > [3] > > > https://ci.ignite.apache.org/viewLog.html?buildId=3701865=IgniteTests24Java8_RunAllNightly > > [4] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212 > > > > пт, 26 апр. 2019 г. в 18:01, Ivan Rakov : > > > > > Ivan P., > > > > > > Good catch, thanks. > > > > > > I was wrong, test scenario is correct. The problem was in > > > atomicityMode() method - it could have returned null (which was okay > for > > > config generation, but wasn't expected in the test code). > > > Please take a look at tx_out_test_fixed.patch (attached to > > > IGNITE-11708). To sum it up, both issues should be fixed now. > > > > > > Best Regards, > > > Ivan Rakov > > > > > > On 26.04.2019 14:40, Павлухин Иван wrote: > > > > Ivan R., > > > > > > > > As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does > > > > not expect lock/unlock events due to line: > > > > if (atomicityMode() == ATOMIC) > > > > return lockEvtCnt.get() == 0; > > > > > > > > Could you please elaborate? > > > > > > > > пт, 26 апр. 2019 г. в 13:32, Ivan Rakov : > > > >> Ivan, > > > >> > > > >> Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test > > > >> scenario assumes that even after expiration entry will be present in > > > >> IgniteCache as per it will be loaded from CacheStore. However, > > > >> CacheStore is not specified in node config. I've added patch that > > > >> enables cache store factory, please check IGNITE-11708 attachments. > > > >> Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* > tests: > > > >> from my point of view, test scenarios make no sense. We perform
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan R., Ivan P., thank you for the suggestions, I took a look at them. According to checking CacheAtomicityMode on null in IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure that checking should proceed on test level? May be it will be better to make default cache value in case if cc.getAtomicityMode() == null in CacheConfiguration constructor [1]? Also let me suggest one minor change according cache specification in IgniteCacheReadThroughEvictionSelfTest. The same logic is used in GridCacheAbstractSelfTest#cacheConfiguration [2]. I think we can excract this code block in a separate static methods (initCacheConfig, for example) in IgniteCacheReadThroughEvictionSelfTest and invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig and GridCacheAbstractSelfTest#cacheConfiguration methods. In addition, I want to draw your attention to IgniteContinuousQueryConfigVariationsSuite test runs [3]. CacheContinuousQueryVariationsTest are generated dynamically. The first batch (12 tests) works fine, but on the next runs we got NPE in IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does not exist and we can not invoke unwrap() on this [4]. Seems that the problem is in IgniteCacheConfigVariationsAbstractTest#beforeTestsStarted/afterTestsStopped methods, cache is not properly created (or already existed cache is destroyed). By the way, should I resolve these issues in the context of IGNITE-11708 or create a separate ticket(s)? [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java#L434 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheAbstractSelfTest.java#L235 [3] https://ci.ignite.apache.org/viewLog.html?buildId=3701865=IgniteTests24Java8_RunAllNightly [4] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212 пт, 26 апр. 2019 г. в 18:01, Ivan Rakov : > Ivan P., > > Good catch, thanks. > > I was wrong, test scenario is correct. The problem was in > atomicityMode() method - it could have returned null (which was okay for > config generation, but wasn't expected in the test code). > Please take a look at tx_out_test_fixed.patch (attached to > IGNITE-11708). To sum it up, both issues should be fixed now. > > Best Regards, > Ivan Rakov > > On 26.04.2019 14:40, Павлухин Иван wrote: > > Ivan R., > > > > As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does > > not expect lock/unlock events due to line: > > if (atomicityMode() == ATOMIC) > > return lockEvtCnt.get() == 0; > > > > Could you please elaborate? > > > > пт, 26 апр. 2019 г. в 13:32, Ivan Rakov : > >> Ivan, > >> > >> Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test > >> scenario assumes that even after expiration entry will be present in > >> IgniteCache as per it will be loaded from CacheStore. However, > >> CacheStore is not specified in node config. I've added patch that > >> enables cache store factory, please check IGNITE-11708 attachments. > >> Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* tests: > >> from my point of view, test scenarios make no sense. We perform get() > >> operation from ATOMIC caches and expect that entries will be locked. I > >> don't understand why we should lock entries on ATOMIC get, therefore I > >> suppose to remove part of code where we listen and check > >> EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. > >> > >> Best Regards, > >> Ivan Rakov > >> > >> On 17.04.2019 22:05, Ivan Rakov wrote: > >>> Hi Ivan, > >>> > >>> I've checked your branch. Seems like these tests fail due to real > >>> issue in functionality. > >>> I'll take a look. > >>> > >>> Best Regards, > >>> Ivan Rakov > >>> > >>> On 17.04.2019 13:54, Ivan Fedotov wrote: > >>>> Hi, Igniters! > >>>> > >>>> During work on iep-30[1] I discovered that > >>>> IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 > >>>> tests[2] > >>>> - do not work. > >>>> You can check it just run one of the tests with log output, for > example > >>>> ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. > >>>> There is no warning notification in the console. The same situation > with > >>>> other IgniteConfigVariationsAbstractTest subclasses - tests run, but > >>>&
Re: [MTCGA]: new failures in builds [3681058, 3680965] needs to be handled
Ok, I created a ticket [1]. After TC Bot visa I'll let you know that ticket is ready for review in Jira. [1] https://issues.apache.org/jira/browse/IGNITE-11802 ср, 24 апр. 2019 г. в 11:08, Павлухин Иван : > Hi Ivan, > > Thank you for a quick response! Looks like that > keepSerializedObjects() is the cause. Yes, please create a ticket. Do > not hesitate to ping me if any assistance is needed. > > ср, 24 апр. 2019 г. в 10:54, Ivan Fedotov : > > > > Hi, Dmitry > > > > I took a look at failures and it could be caused by changes in > > tearDown/clearTestEnviroment method. In the latest master version before > > IGNITE-11412 serializedObj.clear(); will be invoked only if > > (!keepSerializedObjects()) condition will be satisfied [1]. > > > > So the insertion of this condition back can repair tests. If you don't > mind > > I'll create a ticket on this issue. > > > > [1] https://github.com/apache/ignite/pull/6267/files > > > > ср, 24 апр. 2019 г. в 10:47, Dmitriy Pavlov : > > > > > Ivan Fedotov & Ivan Pavluchin could you please take a look at these > > > failures? > > > > > > ср, 24 апр. 2019 г. в 02:05, : > > > > > > > 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 test failure in master-nightly > > > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5548468340600994272=%3Cdefault%3E=testDetails > > > > > > > > *New test failure in master-nightly > > > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-382088580357428313=%3Cdefault%3E=testDetails > > > > Changes may lead to failure were done by > > > > - fedotov > > > > https://ci.ignite.apache.org/viewModification.html?modId=882000 > > > > > > > > *New test failure in master-nightly > > > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4388210921121324153=%3Cdefault%3E=testDetails > > > > > > > > *New test failure in master-nightly > > > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5896795211740970480=%3Cdefault%3E=testDetails > > > > Changes may lead to failure were done by > > > > - fedotov > > > > https://ci.ignite.apache.org/viewModification.html?modId=882000 > > > > > > > > - 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 02:05:36 24-04-2019 > > > > > > > > > > > > > -- > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > > -- > Best regards, > Ivan Pavlukhin > -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-11802) Check keepSerializedObjects() condition after each test
Ivan Fedotov created IGNITE-11802:
-
Summary: Check keepSerializedObjects() condition after each test
Key: IGNITE-11802
URL: https://issues.apache.org/jira/browse/IGNITE-11802
Project: Ignite
Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov
After some changes in GridAbstractTest class [1] condition on
{{serializedObj.clear()}} invocation was removed [2].
In the previous master version {{serializedObj.clear()}} will be invoked only
if {{(!keepSerializedObjects())}} condition will be satisfied.
Due to this reason, some tests became failed [3], so it is necessary to return
such check.
[1] https://issues.apache.org/jira/browse/IGNITE-11412
[2]
https://github.com/apache/ignite/pull/6267/files#diff7a554fa780cd51aae79479d6e9dfcc96L2152
[3]
http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-3681058-3680965-needs-to-be-handled-td41859.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [MTCGA]: new failures in builds [3681058, 3680965] needs to be handled
Hi, Dmitry I took a look at failures and it could be caused by changes in tearDown/clearTestEnviroment method. In the latest master version before IGNITE-11412 serializedObj.clear(); will be invoked only if (!keepSerializedObjects()) condition will be satisfied [1]. So the insertion of this condition back can repair tests. If you don't mind I'll create a ticket on this issue. [1] https://github.com/apache/ignite/pull/6267/files ср, 24 апр. 2019 г. в 10:47, Dmitriy Pavlov : > Ivan Fedotov & Ivan Pavluchin could you please take a look at these > failures? > > ср, 24 апр. 2019 г. в 02:05, : > > > 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 test failure in master-nightly > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5548468340600994272=%3Cdefault%3E=testDetails > > > > *New test failure in master-nightly > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-382088580357428313=%3Cdefault%3E=testDetails > > Changes may lead to failure were done by > > - fedotov > > https://ci.ignite.apache.org/viewModification.html?modId=882000 > > > > *New test failure in master-nightly > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4388210921121324153=%3Cdefault%3E=testDetails > > > > *New test failure in master-nightly > > IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5896795211740970480=%3Cdefault%3E=testDetails > > Changes may lead to failure were done by > > - fedotov > > https://ci.ignite.apache.org/viewModification.html?modId=882000 > > > > - 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 02:05:36 24-04-2019 > > > -- Ivan Fedotov. ivanan...@gmail.com
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Hi Dmitry, Maybe if it will turn out that all tests fail because of functionality we should ignore or mute these tests in the context of the ticket IGNITE-11708? ср, 17 апр. 2019 г. в 23:20, Dmitriy Pavlov : > Hi Ivan F. > > Thank you for finding it and bringing it here. > > Please feel free to fix test to run (and fail) if the code it tests is > faulty now. If the community knows the moment when tests run will be > enabled, it is absolutely not an issue, that TeamCity Bot will complain > about new failures. I strongly believe that we should see a true picture of > tests output rather than having these tests not running. > > Sincerely, > Dmitriy Pavlov > > ср, 17 апр. 2019 г. в 22:05, Ivan Rakov : > > > Hi Ivan, > > > > I've checked your branch. Seems like these tests fail due to real issue > > in functionality. > > I'll take a look. > > > > Best Regards, > > Ivan Rakov > > > > On 17.04.2019 13:54, Ivan Fedotov wrote: > > > Hi, Igniters! > > > > > > During work on iep-30[1] I discovered that > > > IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 > > tests[2] > > > - do not work. > > > You can check it just run one of the tests with log output, for example > > > ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. > > > There is no warning notification in the console. The same situation > with > > > other IgniteConfigVariationsAbstractTest subclasses - tests run, but > they > > > simply represent empty code. > > > > > > So, I created a ticket on such issue [4] and it turned out that the > > problem > > > is with ruleChain in IgniteConfigVariationsAbstractTest [5]. > > > The rule that is responsible for running a test statement does not > start > > > indeed [6] under ruleChain runRule. I suggested a solution - move > > testsCfg > > > initialization to > > > IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After > such > > > changes ruleChain becomes not necessary. > > > > > > But I faced another problem - multiple failures on TeamCity [7]. From > > logs, > > > it seems that failures are related to what tests check, but not JUnit > > error. > > > I can not track TeamCity history on that fact were tests failed or not > on > > > the previous JUnit version - the oldest log is dated the start of the > > March > > > when JUnit4 > > > already was implemented (for example, this [8] test). > > > Moreover, there are not so much failed tests, but because of running > with > > > multiple configurations > > (InterceptorCacheConfigVariationsFullApiTestSuite_0 > > > ..._95) it turns out about 400 failed tests. TeamCity results also > > confirm > > > that tests do not work in the master branch - duration time is less > than > > > 1ms. Now all tests are green and that is not surprising - under @Test > > > annotation, nothing happens. > > > > > > Could some of us confirm or disprove my guess that tests are red > because > > of > > > its functionality, but not JUnit implementation? > > > And if it is true, how should I take such fact into account in this > > ticket? > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > > [2] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java > > > [3] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 > > > [4] https://issues.apache.org/jira/browse/IGNITE-11708 > > > [5] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 > > > [6] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 > > > [7] > > > > > > https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest > > > [8] > > > > > > https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8 > > > > > > -- Ivan Fedotov. ivanan...@gmail.com
IgniteConfigVariationsAbstractTest subclasses do not run
Hi, Igniters! During work on iep-30[1] I discovered that IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 tests[2] - do not work. You can check it just run one of the tests with log output, for example ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. There is no warning notification in the console. The same situation with other IgniteConfigVariationsAbstractTest subclasses - tests run, but they simply represent empty code. So, I created a ticket on such issue [4] and it turned out that the problem is with ruleChain in IgniteConfigVariationsAbstractTest [5]. The rule that is responsible for running a test statement does not start indeed [6] under ruleChain runRule. I suggested a solution - move testsCfg initialization to IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such changes ruleChain becomes not necessary. But I faced another problem - multiple failures on TeamCity [7]. From logs, it seems that failures are related to what tests check, but not JUnit error. I can not track TeamCity history on that fact were tests failed or not on the previous JUnit version - the oldest log is dated the start of the March when JUnit4 already was implemented (for example, this [8] test). Moreover, there are not so much failed tests, but because of running with multiple configurations (InterceptorCacheConfigVariationsFullApiTestSuite_0 ..._95) it turns out about 400 failed tests. TeamCity results also confirm that tests do not work in the master branch - duration time is less than 1ms. Now all tests are green and that is not surprising - under @Test annotation, nothing happens. Could some of us confirm or disprove my guess that tests are red because of its functionality, but not JUnit implementation? And if it is true, how should I take such fact into account in this ticket? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java [3] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 [4] https://issues.apache.org/jira/browse/IGNITE-11708 [5] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 [6] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 [7] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest [8] https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8 -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-11708) Unable to run tests under IgniteConfigVariationsAbstractTest class
Ivan Fedotov created IGNITE-11708: - Summary: Unable to run tests under IgniteConfigVariationsAbstractTest class Key: IGNITE-11708 URL: https://issues.apache.org/jira/browse/IGNITE-11708 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov It seems that test classes that extend from IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test annotation. It is easy to check: if throw exception in any test methods, nothing will happen. Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], maybe it destroys existing test workflow. [1] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11637) Remove class loader initilization in GridSpiAbstractTest
Ivan Fedotov created IGNITE-11637: - Summary: Remove class loader initilization in GridSpiAbstractTest Key: IGNITE-11637 URL: https://issues.apache.org/jira/browse/IGNITE-11637 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov Investigate necessity of secondary class loader initilization in GridSpiAbstractTest. Initilization is secondary because the first is in GridAbstractTest. Now it seems that setting class loader in GridSpiAbstractTest should be removed. [1] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/spi/GridSpiAbstractTest.java#L151] [2] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L558] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: beforeTest, afterTest JUnit scenario implementation
Hi Ivan, Thank you for your response. In this way, I will finish IGNITE-11411-13 tickets with Rule annotation and minimal changes. чт, 21 мар. 2019 г. в 21:19, Павлухин Иван : > Hi Ivan, > > During migration from junit 3 to 4 multiple options was discussed [1]. > And the main decision about before/after test method was making as > less as possible changes in already existing tests with adding an > ability to write new tests using common junit 4 style (i.e. using > annotations in new tests). > > And it seems that mentioned above correlates with your approach. > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html > > ср, 20 мар. 2019 г. в 17:38, Ivan Fedotov : > > > > Hi Igniters! > > > > I have a questions according to beforeTest(s)/afterTest(s) methods. I > tried > > to make them correspond to JUnit 4+ semantics in the context of iep30 > [1]. > > And I see there two solutions: > > > > 1. Place test scenario under the Rule annotation as it has already done > in > > GridAbstractTest [2]. It is a built-in opportunity to extend JUnit > > framework. Such case already implemented and demands minimal changes. To > > add before and after test logic in the other classes, it is necessary to > > override corresponding methods. > > > > 2. Write before and after test logic with annotations in GridAbstractTest > > and all other classes. Such solution is less flexible in comparison with > > rules. Moreover, under annotation, a code will be less readable than > under > > rule. But such approach decreases coupling between classes. > > > > The main argumentation in favor of the first approach is that there are > > minimal changes in code. According to this during migration on other > JUnit > > versions, there is no need to fix all test files to change imports and > > annotations (for instance, in JUnit5 Before/BeforeClass, After/AfterClass > > annotations were changed). Changes will affect only GridAbstractTest > > class. At the same time, the possibility to use annotations remains. > > > > Now I started to implement the first approach [3] - specify test scenario > > under the Rule annotation and override methods if it is necessary. > > Such functionality is similar to the third version, but with 4+ semantics > > and with minimal changes during migration. > > > > What do you think, which approach will be better for the community? > > > > [1] > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > [2] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 > > [3]https://github.com/apache/ignite/pull/6227/files > > > > -- > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > > -- > Best regards, > Ivan Pavlukhin > -- Ivan Fedotov. ivanan...@gmail.com
beforeTest, afterTest JUnit scenario implementation
Hi Igniters! I have a questions according to beforeTest(s)/afterTest(s) methods. I tried to make them correspond to JUnit 4+ semantics in the context of iep30 [1]. And I see there two solutions: 1. Place test scenario under the Rule annotation as it has already done in GridAbstractTest [2]. It is a built-in opportunity to extend JUnit framework. Such case already implemented and demands minimal changes. To add before and after test logic in the other classes, it is necessary to override corresponding methods. 2. Write before and after test logic with annotations in GridAbstractTest and all other classes. Such solution is less flexible in comparison with rules. Moreover, under annotation, a code will be less readable than under rule. But such approach decreases coupling between classes. The main argumentation in favor of the first approach is that there are minimal changes in code. According to this during migration on other JUnit versions, there is no need to fix all test files to change imports and annotations (for instance, in JUnit5 Before/BeforeClass, After/AfterClass annotations were changed). Changes will affect only GridAbstractTest class. At the same time, the possibility to use annotations remains. Now I started to implement the first approach [3] - specify test scenario under the Rule annotation and override methods if it is necessary. Such functionality is similar to the third version, but with 4+ semantics and with minimal changes during migration. What do you think, which approach will be better for the community? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 [3]https://github.com/apache/ignite/pull/6227/files -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest
Ivan Fedotov created IGNITE-11568: - Summary: Change afterTest() annotation in TcpDiscoveryFailedJoinTest Key: IGNITE-11568 URL: https://issues.apache.org/jira/browse/IGNITE-11568 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by after. Meanwhile, it is under prohibition because afterTest will be executed before test afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest usage in GridAbstractTest). So, it is necessary to change after annotation on override. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Review IGNITE-11411 'Remove tearDown, setUp from JUnit3TestLegacySupport'
Hi Eduard. Thank you for your participation in the review. In case of any questions feel free to ask me. вт, 19 мар. 2019 г. в 11:04, Eduard Shangareev : > Hi. > > I am interested in. If nobody did it I would do it next week. > > On Tue, Mar 19, 2019 at 10:20 AM Ivan Fedotov wrote: > > > Hi Igniters! > > > > Now I am working on iep-30[1] which is about fully 4->5 migration and > > includes some moments according to JUnit 3->4 migration. > > I am on the first stage and finishing ticket about removing tearDown, > setUp > > from JUnit3TestLegacySupport [2]. > > > > In nutshell: I removed setUp, tearDown from JUnit3TestLegacySupport and > > replaced them by beforeTest, afterTest in tests where they are used. That > > brings us to the JUnit5 test scenario because setUp and tearDown are used > > under Rule annotation in GridAbstractTest. > > > > Could somebody review this ticket, please? > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > [2] https://issues.apache.org/jira/browse/IGNITE-11411 > > > > -- > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > -- Ivan Fedotov. ivanan...@gmail.com
Review IGNITE-11411 'Remove tearDown, setUp from JUnit3TestLegacySupport'
Hi Igniters! Now I am working on iep-30[1] which is about fully 4->5 migration and includes some moments according to JUnit 3->4 migration. I am on the first stage and finishing ticket about removing tearDown, setUp from JUnit3TestLegacySupport [2]. In nutshell: I removed setUp, tearDown from JUnit3TestLegacySupport and replaced them by beforeTest, afterTest in tests where they are used. That brings us to the JUnit5 test scenario because setUp and tearDown are used under Rule annotation in GridAbstractTest. Could somebody review this ticket, please? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://issues.apache.org/jira/browse/IGNITE-11411 -- Ivan Fedotov. ivanan...@gmail.com
Re: Migration to JUnit 5
Ivan,
I will investigate GridAbstractTest refactoring issue more precisely when I
finish with JUnit3Legacy classes. Anyway, I will keep in touch with you and
the community on the most significant moments.
JUnit5 docs say that functionality is not full "especially with regard to
reporting". On the other hand, I also agree with docs that it is the
easiest way that does not require to touch CI infrastructure. I am going to
try @RunWith(JUnitPlatform.class) construction with features from IEP to
make sure that we will have the full support of them. The alternative way
is dynamic tests [1], but the problem is that we add methods to suites
manually, not via @Test annotation. It is some kind of rollback to JUnit3
syntax.
Anton,
thank you for the reminder, I will update IEP according to the conversation.
[1] https://www.baeldung.com/junit5-dynamic-tests
вт, 26 февр. 2019 г. в 17:56, Anton Vinogradov :
> Folks,
>
> Please make sure you keep IEP updated and each issue mentioned.
>
> On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван wrote:
>
> > Ivan,
> >
> > Thank you for detailed answers! I would put a great care to
> > @RunWith(JUnitPlatform.class) construction. As stated in junit5 docs
> > [1] it does not support all features and unfortunately it is not clear
> > how limited it is. Also, it is some kind of transitional mechanism
> > which was not designed for being a long term solution.
> >
> > And I fully support an idea of refactoring GridAbstractTest. I think
> > it is possible to make a significant improvement here.
> >
> > [1]
> >
> https://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner
> >
> > пн, 25 февр. 2019 г. в 17:41, Ivan Fedotov :
> > >
> > > Hello Nikolay.
> > >
> > > The prime benefits are more comfortable work with flaky tests, Java 8
> > tests
> > > compatibility, user-friendly syntaxis in parametrized tests and others.
> > > The most significant features list you can find in IEP-30 Motivation
> > > section.
> > >
> > > If you have any specific questions about JUnit5 feel free to ask me.
> > >
> > > пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov :
> > >
> > > > Hello, Ivan.
> > > >
> > > > May be I miss some mail - if yes, can you repeat it.
> > > > What is advantages of migration from junit 4 to 5?
> > > > Why we should do it?
> > > >
> > > >
> > > > пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
> > > >
> > > > > Ivan,
> > > > > That is my thoughts according to your questions.
> > > > >
> > > > > 1. I tried to implement test suits with JUnit4 compatibility layer.
> > The
> > > > > basic concept is to use @RunWith(JUnitPlatform.class)
> @SelectClasses
> > > > > ({...})[1] and on
> > > > > CI Ignite it works fine.
> > > > >
> > > > > 2. According to @Rules, there are several ways to solve it:
> > > > > 2.1 Leave JUnit4 code without changes. It will work because of
> > > > Vintage
> > > > > module
> > > > > 2.2 Rewrite the @Rule as an Extension. The work of extension is
> > > > similar
> > > > > to the @Rules work, but it is extracted in an Extension class.
> > > > > For more information about extensions, please, follow the IEP
> > [2].
> > > > > In my opinion, the easiest and the most understandable way is to
> > leave
> > > > > GridAbstractTest in current form. It will work with JUnit5
> > > > > syntaxis and abilities.
> > > > >
> > > > > 3. I faced a couple of problems during dealing with dynamic and
> > static
> > > > > tests in one project with JUnit5. The problem occurs with surefire
> > > > version:
> > > > > static tests work fine with 2.21x and earlier and with dynamic
> > tests, the
> > > > > situation is vice versa, it works with > 2.21x surefire version.
> > > > > We can use helpful surefire dependency to use static tests with the
> > > > newest
> > > > > surefire version [3], but dynamic tests become unavailable from
> pure
> > > > > Maven and accordingly from CI Ignite (from IDE all is fine).
> > > > > I can suggest leaving this type of tests on JUnit4 on the current
> > stage -
> > > > > they are in the vast minority.
> > > > >
> > > > > Let me comment on your side notes.
> > >
[jira] [Created] (IGNITE-11414) Remove JUnit3LegacySupport
Ivan Fedotov created IGNITE-11414: - Summary: Remove JUnit3LegacySupport Key: IGNITE-11414 URL: https://issues.apache.org/jira/browse/IGNITE-11414 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest class or remove if it is possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
Ivan Fedotov created IGNITE-11413: - Summary: Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport Key: IGNITE-11413 URL: https://issues.apache.org/jira/browse/IGNITE-11413 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov beforeTestsStarted and afterTestsStarted methods are deprecated in context of JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass annotations for such purposes. Methods must be moved in corresponded classes and marked by annotations. It could require changes in start/stop nodes process because methods under @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11412) Remove beforeTest, afterTest from JUnit3TestLegacySupport
Ivan Fedotov created IGNITE-11412: - Summary: Remove beforeTest, afterTest from JUnit3TestLegacySupport Key: IGNITE-11412 URL: https://issues.apache.org/jira/browse/IGNITE-11412 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov Replace beforeTest, afterTest methods in JUnit3TestLegacySupport by annotations @Before, @After in corresponding classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Migration to JUnit 5
Hello Nikolay.
The prime benefits are more comfortable work with flaky tests, Java 8 tests
compatibility, user-friendly syntaxis in parametrized tests and others.
The most significant features list you can find in IEP-30 Motivation
section.
If you have any specific questions about JUnit5 feel free to ask me.
пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov :
> Hello, Ivan.
>
> May be I miss some mail - if yes, can you repeat it.
> What is advantages of migration from junit 4 to 5?
> Why we should do it?
>
>
> пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
>
> > Ivan,
> > That is my thoughts according to your questions.
> >
> > 1. I tried to implement test suits with JUnit4 compatibility layer. The
> > basic concept is to use @RunWith(JUnitPlatform.class) @SelectClasses
> > ({...})[1] and on
> > CI Ignite it works fine.
> >
> > 2. According to @Rules, there are several ways to solve it:
> > 2.1 Leave JUnit4 code without changes. It will work because of
> Vintage
> > module
> > 2.2 Rewrite the @Rule as an Extension. The work of extension is
> similar
> > to the @Rules work, but it is extracted in an Extension class.
> > For more information about extensions, please, follow the IEP [2].
> > In my opinion, the easiest and the most understandable way is to leave
> > GridAbstractTest in current form. It will work with JUnit5
> > syntaxis and abilities.
> >
> > 3. I faced a couple of problems during dealing with dynamic and static
> > tests in one project with JUnit5. The problem occurs with surefire
> version:
> > static tests work fine with 2.21x and earlier and with dynamic tests, the
> > situation is vice versa, it works with > 2.21x surefire version.
> > We can use helpful surefire dependency to use static tests with the
> newest
> > surefire version [3], but dynamic tests become unavailable from pure
> > Maven and accordingly from CI Ignite (from IDE all is fine).
> > I can suggest leaving this type of tests on JUnit4 on the current stage -
> > they are in the vast minority.
> >
> > Let me comment on your side notes.
> >
> > I am not against the stable and widely-used test library usage. All I
> want
> > to say that it is not necessary in case of the main testing Ignite
> > framework (Junit) already provides the mentioned features.
> >
> > At the initial stage of improvements 3->4 I am planning to remove
> > JUnit3TestLegacyAssert, JUnit3TestLegacySupport classes. I guess that
> > during this work
> > I will face with an issue that you are mentioned - turning instance
> methods
> > to static. It is because of beforeTestsStarted and afterTestsStarted
> > methods - I want to replace them by methods with BeforeAll, AfterAll
> > annotations. But the point is that methods under such annotations must be
> > static. Just now I am not sure about fully removing
> > GridCommonAbstractTest class, but the need for static methods is a fact.
> >
> > [1]
> >
> >
> https://github.com/apache/ignite/blob/85ba3a88d661bb05bbb749bd1feaf60cd9099ddc/examples/src/test/java/org/apache/ignite/testsuites/IgniteExamplesSelfTestSuite.java#L59
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> > [3] https://github.com/junit-team/junit5/issues/1778
> >
> > вс, 24 февр. 2019 г. в 10:15, Павлухин Иван :
> >
> > > Ivan,
> > >
> > > Indeed junit5 has a lot of powerful features which can improve testing
> > > process.
> > >
> > > But first we should go through a migration process. There are several
> > > items which looks quite challenging.
> > > 1. Test suites support. Correct me if I am missed it, but I have not
> > > found a concept of test suites similar to junit3/4 ones. CI in Ignite
> > > heavily depends on test suites. Is there an alternative in junit5?
> > > 2. The majority of our tests extend GridAbstractTest which in fact is
> > > a core class in Ignite testing. Writing a test without extending it is
> > > not a good idea. Currently it employs number of junit4 concepts, e.g.
> > > test rules which as I saw are not supported in junit5. So, it sounds
> > > that some changes in GridAbstractTest need to be done. During
> > > migration from junit 3 to 4 GridAbstractTest used kind of mimicry, it
> > > can be used as a base class for junit3 and junit4 tests at the same
> > > time. How can we address transitional period now?
> > > 3. Also we have bunch of tests using our home-brewed parametrization.
> > > You can find them by se
[jira] [Created] (IGNITE-11411) Remove tearDown, setUp from GridAbstractTest
Ivan Fedotov created IGNITE-11411: - Summary: Remove tearDown, setUp from GridAbstractTest Key: IGNITE-11411 URL: https://issues.apache.org/jira/browse/IGNITE-11411 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov TearDown and setUp methods are deprecated for JUnit 4+ version. It is necessary to replace them with appropriate methods, marked by @Before and @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Migration to JUnit 5
Ivan,
That is my thoughts according to your questions.
1. I tried to implement test suits with JUnit4 compatibility layer. The
basic concept is to use @RunWith(JUnitPlatform.class) @SelectClasses
({...})[1] and on
CI Ignite it works fine.
2. According to @Rules, there are several ways to solve it:
2.1 Leave JUnit4 code without changes. It will work because of Vintage
module
2.2 Rewrite the @Rule as an Extension. The work of extension is similar
to the @Rules work, but it is extracted in an Extension class.
For more information about extensions, please, follow the IEP [2].
In my opinion, the easiest and the most understandable way is to leave
GridAbstractTest in current form. It will work with JUnit5
syntaxis and abilities.
3. I faced a couple of problems during dealing with dynamic and static
tests in one project with JUnit5. The problem occurs with surefire version:
static tests work fine with 2.21x and earlier and with dynamic tests, the
situation is vice versa, it works with > 2.21x surefire version.
We can use helpful surefire dependency to use static tests with the newest
surefire version [3], but dynamic tests become unavailable from pure
Maven and accordingly from CI Ignite (from IDE all is fine).
I can suggest leaving this type of tests on JUnit4 on the current stage -
they are in the vast minority.
Let me comment on your side notes.
I am not against the stable and widely-used test library usage. All I want
to say that it is not necessary in case of the main testing Ignite
framework (Junit) already provides the mentioned features.
At the initial stage of improvements 3->4 I am planning to remove
JUnit3TestLegacyAssert, JUnit3TestLegacySupport classes. I guess that
during this work
I will face with an issue that you are mentioned - turning instance methods
to static. It is because of beforeTestsStarted and afterTestsStarted
methods - I want to replace them by methods with BeforeAll, AfterAll
annotations. But the point is that methods under such annotations must be
static. Just now I am not sure about fully removing
GridCommonAbstractTest class, but the need for static methods is a fact.
[1]
https://github.com/apache/ignite/blob/85ba3a88d661bb05bbb749bd1feaf60cd9099ddc/examples/src/test/java/org/apache/ignite/testsuites/IgniteExamplesSelfTestSuite.java#L59
[2]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
[3] https://github.com/junit-team/junit5/issues/1778
вс, 24 февр. 2019 г. в 10:15, Павлухин Иван :
> Ivan,
>
> Indeed junit5 has a lot of powerful features which can improve testing
> process.
>
> But first we should go through a migration process. There are several
> items which looks quite challenging.
> 1. Test suites support. Correct me if I am missed it, but I have not
> found a concept of test suites similar to junit3/4 ones. CI in Ignite
> heavily depends on test suites. Is there an alternative in junit5?
> 2. The majority of our tests extend GridAbstractTest which in fact is
> a core class in Ignite testing. Writing a test without extending it is
> not a good idea. Currently it employs number of junit4 concepts, e.g.
> test rules which as I saw are not supported in junit5. So, it sounds
> that some changes in GridAbstractTest need to be done. During
> migration from junit 3 to 4 GridAbstractTest used kind of mimicry, it
> can be used as a base class for junit3 and junit4 tests at the same
> time. How can we address transitional period now?
> 3. Also we have bunch of tests using our home-brewed parametrization.
> You can find them by searching usages of
> ConfigVariationsTestSuiteBuilder. This part was rather tricky during
> migration to junit4.
>
> Do we have a plan for all these items?
>
>
> Couple of side notes.
>
> Regarding dependencies minimization. Actually, I think it is important
> for junit itself as a library. Many libraries try to minimize
> dependency. In Ignite we do so as well. But in my opinion it is not
> the case in context of libraries used during testing. If we have
> useful, stable and widely-used test library which can improve our
> processes why should not we use it?
>
> Regarding removing leftovers left after junit 3->4 migration.
> Actually, I think that GridAbstractTest and GridCommonAbstractTest can
> be refactored in order to simplify further development and migration
> to new testing framework. For example, there are a lot of instance
> methods which can be turned to static methods. Various start/stopGrid
> methods fall into this category. They can be extracted into some
> utility class and imported statically. Perhaps, after number of such
> refactoring we will be able to write tests without extending
> GridCommonAbstractTest.
>
> пт, 22 февр. 2019 г. в 18:33, Ivan Fedotov :
> >
> > Hi Ivan!
> >
> > Junit5 differs from JUnit4 not
[jira] [Created] (IGNITE-11396) Remove JUnit3TestLeggriacyAssert
Ivan Fedotov created IGNITE-11396: - Summary: Remove JUnit3TestLeggriacyAssert Key: IGNITE-11396 URL: https://issues.apache.org/jira/browse/IGNITE-11396 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov Replace assert methods by imports. That will lead to full remove JUnit3TestLeggriacyAssert class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Migration to JUnit 5
Hi Ivan! Junit5 differs from JUnit4 not so strong as 4 from 3 version. Of course, we can use AssertJ and other libraries, but it is more comfortable to use functionality from the box. Moreover, the JUnit team provides strong support for its products and it is the core JUnit principle - minimize third-party dependency [1]. According to Parameterized tests, it has several cons in JUnit4: 1. Test classes use fields and constructors to define parameters, which make tests more verbose 2. It requires a separate test class for each method being tested. In JUnit5 it has a simplified parameter syntax and supports multiple data-set source types, including CSV and annotation Impact on daily test development does not so differ from development on JUnit4. We also can use annotations to mark methods as tests, but some main annotations have different names - you can see it in the ticket description [2]. You have to use those annotations and different import, but these are minor changes. We can change suites from static to dynamic tests [3], but I am not sure that it is necessary. If you have any arguments in favor of dynamic tests, I am ready to discuss them. Now I see that changes in GridAbstractTest are not required. Only improvements in JUnit 3->4 migration, which were given in IEP. Other JUnit5 features we can use with additional imports. The problem can appear with dynamic tests because we can not launch static and dynamic under one surefire version. I made a preliminary migration on examples module, you can take a look on it [4], but now it is still in work. I tried to find some other JUnit5 features and added them to IEP. If I miss something, please, let me now, we will also take it into account. [1] https://github.com/junit-team/junit5/wiki/Core-Principles [2] https://issues.apache.org/jira/browse/IGNITE-10958 [3] https://www.baeldung.com/junit5-dynamic-tests [4] https://github.com/apache/ignite/pull/5888 чт, 21 февр. 2019 г. в 18:45, Павлухин Иван : > Hi Ivan, > > Thank you for your efforts! > > I checked a section "Motivation" in IEP and I think that we should add > more details there. You provided mostly examples of more convenient > assertions. But there are other options to deal with it. E.g. AssertJ > library [1] (I think that we can consider it even after migration to > junit5). It would be great if we can describe some junit5 features > which can make our life simpler and there is no alternative in junit4. > E.g. we have the similar Parameterized concept in junit4, so it does > not look as a big win here. > > Also, an impact on everyday development should be estimated. As I > know, junit5 has a compatibility layer which allows to migrate from > junit4 seamlessly. But as I understood you would like to use new > junit5 features. And we have well-known GridAbstractTest which > historically was bound to junit3, now is bound to junit4. Should we > change it significantly for junit5? Should we change other existing > tests? Suites? > > Could you please address my concerns? > > Let's discuss pros and cons. I will be happy to help there. > > [1] http://joel-costigliola.github.io/assertj/ > > чт, 21 февр. 2019 г. в 18:07, Ivan Fedotov : > > > > Dmitriy, thank you, access is fine. > > > > I have created the corresponding IEP [1]. > > > > Now I am going to continue work on this. If somebody has any suggestions > or > > additions I am ready to discuss them. > > > > [1] > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > > > чт, 21 февр. 2019 г. в 01:42, Dmitriy Pavlov : > > > > > Done, please check access now. > > > > > > ср, 20 февр. 2019 г. в 21:49, Ivan Fedotov : > > > > > > > Dmitriy, thank you for the response. > > > > > > > > My wiki username is "ivanan", the related mailbox is > ivanan...@gmail.com > > > . > > > > > > > > ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov : > > > > > > > > > Hi Ivan, > > > > > > > > > > Now admin service is unavailable (gives error 503). I'll add rights > > > once > > > > it > > > > > is up and running. > > > > > > > > > > Could you share your wiki username? I can't find any users who > signed > > > up > > > > in > > > > > the wiki with any similar email/username > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov : > > > > > > > > > > > Hi, Igniters. > > > > >
Re: Migration to JUnit 5
Dmitriy, thank you, access is fine. I have created the corresponding IEP [1]. Now I am going to continue work on this. If somebody has any suggestions or additions I am ready to discuss them. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 чт, 21 февр. 2019 г. в 01:42, Dmitriy Pavlov : > Done, please check access now. > > ср, 20 февр. 2019 г. в 21:49, Ivan Fedotov : > > > Dmitriy, thank you for the response. > > > > My wiki username is "ivanan", the related mailbox is ivanan...@gmail.com > . > > > > ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov : > > > > > Hi Ivan, > > > > > > Now admin service is unavailable (gives error 503). I'll add rights > once > > it > > > is up and running. > > > > > > Could you share your wiki username? I can't find any users who signed > up > > in > > > the wiki with any similar email/username > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov : > > > > > > > Hi, Igniters. > > > > > > > > I am planning to formalize migration to JUnit5 and create IEP which > > will > > > > include related issues. > > > > > > > > I already started to work on one of the issues [1] and created a > draft > > > for > > > > the corresponding IEP [2]. > > > > > > > > Please, give me rights for confluence to create IEP. > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10973 > > > > [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759 > > > > > > > > Sincerely, > > > > Ivan Fedotov. > > > > > > > > ivanan...@gmail.com > > > > > > > > > > > > > -- > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > -- Ivan Fedotov. ivanan...@gmail.com
Re: Migration to JUnit 5
Dmitriy, thank you for the response. My wiki username is "ivanan", the related mailbox is ivanan...@gmail.com. ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov : > Hi Ivan, > > Now admin service is unavailable (gives error 503). I'll add rights once it > is up and running. > > Could you share your wiki username? I can't find any users who signed up in > the wiki with any similar email/username > > Sincerely, > Dmitriy Pavlov > > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov : > > > Hi, Igniters. > > > > I am planning to formalize migration to JUnit5 and create IEP which will > > include related issues. > > > > I already started to work on one of the issues [1] and created a draft > for > > the corresponding IEP [2]. > > > > Please, give me rights for confluence to create IEP. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10973 > > [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759 > > > > Sincerely, > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > -- Ivan Fedotov. ivanan...@gmail.com
Migration to JUnit 5
Hi, Igniters. I am planning to formalize migration to JUnit5 and create IEP which will include related issues. I already started to work on one of the issues [1] and created a draft for the corresponding IEP [2]. Please, give me rights for confluence to create IEP. [1] https://issues.apache.org/jira/browse/IGNITE-10973 [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759 Sincerely, Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-10973) Migrate example module tests from Junit 3 to 4
Ivan Fedotov created IGNITE-10973: - Summary: Migrate example module tests from Junit 3 to 4 Key: IGNITE-10973 URL: https://issues.apache.org/jira/browse/IGNITE-10973 Project: Ignite Issue Type: Sub-task Reporter: Ivan Fedotov Assignee: Ivan Fedotov For more information refer parent task for more details. Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10958) Migrate from Junit 4 to 5
Ivan Fedotov created IGNITE-10958: - Summary: Migrate from Junit 4 to 5 Key: IGNITE-10958 URL: https://issues.apache.org/jira/browse/IGNITE-10958 Project: Ignite Issue Type: Task Reporter: Ivan Fedotov Assignee: Ivan Fedotov Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 was in ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10588) Fail clean internal structure in test on Zookeeper Discovery Spi
Ivan Fedotov created IGNITE-10588: - Summary: Fail clean internal structure in test on Zookeeper Discovery Spi Key: IGNITE-10588 URL: https://issues.apache.org/jira/browse/IGNITE-10588 Project: Ignite Issue Type: Task Affects Versions: 2.8 Reporter: Ivan Fedotov Assignee: Ivan Fedotov In ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk and ZookeeperDiscoverySpiTest#testTopologyChangeMultithreaded_RestartZk_CloseClients sometimes fails check on clean internal structure [1]. It seems that it is too small timeout on corresponding future. [1] https://github.com/apache/ignite/blob/master/modules/zookeeper/src/test/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoverySpiTest.java#L552 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Apache Ignite 2.7. Last Mile
Vyacheslav, thank you for remark. I've tried to launch test on the 2.7 version and it is fine. I changed priority of the ticket from "Blocker" to "Major" and fix version to 2.8. пн, 3 дек. 2018 г. в 13:53, Vladimir Ozerov : > Confirming. Test never failed in AI 2.7 even though it contains mentioned > MVCC commit. > > On Mon, Dec 3, 2018 at 1:36 PM Vyacheslav Daradur > wrote: > > > Guys, I checked that `testAtomicOnheapTwoBackupAsyncFullSync` failed > > in the master (as described Ivan), but it passes in branch ignite-2.7 > > (tag 2.7.0-rc2), so this shouldn't block the release. > > > > Ivan, were you able to reproduce this issue in ignite-2.7 branch? > > > > > > On Mon, Dec 3, 2018 at 1:03 PM Ivan Fedotov wrote: > > > > > > Nikolay, > > > > > > I think that end-user may face the problem during call > IgniteCache#invoke > > > on a cache with registered continious query if cache's configuration is > > as > > > in the failed test: [PARTITIONED, ATOMIC, FULL_SYNCH, 2 backups]. > > > > > > I've found that failure has been introduced by MVCC commit [1]. As I > > > understand the issue relates to the process of updating metadata, when > > the > > > future of binary metadata registration hangs because of an unclear > > reason. > > > > > > I don't know if the issue the blocker, but seems it's regression > because > > > the test has been passed on Ignite 2.6 > > > > > > What do you think? > > > > > > [1] > > > > > > https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8 > > > > > > пн, 3 дек. 2018 г. в 11:14, Nikolay Izhikov : > > > > > > > Ivan, please, clarify. > > > > > > > > How your investigation are related to 2.7 release? > > > > Do you think it's a release blocker? > > > > If yes, please, describe impact to users and how users can reproduce > > this > > > > issue. > > > > > > > > пн, 3 дек. 2018 г., 9:30 Ivan Fedotov ivanan...@gmail.com: > > > > > > > > > I've created the PR <https://github.com/apache/ignite/pull/5550> > > which > > > > > includes changes < > > https://github.com/1vanan/ignite/commits/before-MVCC> > > > > > just before integration MVCC with Continuous Query and from the > > TeamCity > > > > > < > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=2434057=buildResultsDiv=IgniteTests24Java8_ContinuousQuery1 > > > > > > > > > > > it is clear that before this changes the > > > > > test testAtomicOnheapTwoBackupAsyncFullSync is green. > > > > > > > > > > Also Roman Kondakov gave his view on this problem in the comments > > > > > <https://issues.apache.org/jira/browse/IGNITE-10376>. Now the > > problem > > > > > becomes more understandable, but the root reason is still unclear. > > > > > > > > > > May be a few of you have any suggestions why hang of threads on the > > > > binary > > > > > metadata registration future appears? > > > > > > > > > > пт, 30 нояб. 2018 г. в 13:48, Ivan Fedotov : > > > > > > > > > > > Igor, thank you for explanation. > > > > > > > > > > > > Now it seems that when the one thread tries to invoke > > > > > > GridCacheMapEntry#touch, the another one makes > > > > > > GridCacheProcessor#stopCache. If I am wrong, please feel free to > > > > correct > > > > > me. > > > > > > > > > > > > But it still does not clear for me why this fail appears after > > commit > > > > > > < > > > > > > > > > > > > https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8 > > > > > > > > > > which > > > > > > is about MVCC. Moreover, NPE appears only with > > BinaryObjectException, > > > > and > > > > > > when the test is green, I can not find NPE in the log. > > > > > > > > > > > > Now I tried to run test locally 1000 times on the version before > > MVCC > > > > and > > > > > > could not find error on this concretely case (but it exists the > > another > > > > > > on
Re: Apache Ignite 2.7. Last Mile
Nikolay, I think that end-user may face the problem during call IgniteCache#invoke on a cache with registered continious query if cache's configuration is as in the failed test: [PARTITIONED, ATOMIC, FULL_SYNCH, 2 backups]. I've found that failure has been introduced by MVCC commit [1]. As I understand the issue relates to the process of updating metadata, when the future of binary metadata registration hangs because of an unclear reason. I don't know if the issue the blocker, but seems it's regression because the test has been passed on Ignite 2.6 What do you think? [1] https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8 пн, 3 дек. 2018 г. в 11:14, Nikolay Izhikov : > Ivan, please, clarify. > > How your investigation are related to 2.7 release? > Do you think it's a release blocker? > If yes, please, describe impact to users and how users can reproduce this > issue. > > пн, 3 дек. 2018 г., 9:30 Ivan Fedotov ivanan...@gmail.com: > > > I've created the PR <https://github.com/apache/ignite/pull/5550> which > > includes changes <https://github.com/1vanan/ignite/commits/before-MVCC> > > just before integration MVCC with Continuous Query and from the TeamCity > > < > > > https://ci.ignite.apache.org/viewLog.html?buildId=2434057=buildResultsDiv=IgniteTests24Java8_ContinuousQuery1 > > > > > it is clear that before this changes the > > test testAtomicOnheapTwoBackupAsyncFullSync is green. > > > > Also Roman Kondakov gave his view on this problem in the comments > > <https://issues.apache.org/jira/browse/IGNITE-10376>. Now the problem > > becomes more understandable, but the root reason is still unclear. > > > > May be a few of you have any suggestions why hang of threads on the > binary > > metadata registration future appears? > > > > пт, 30 нояб. 2018 г. в 13:48, Ivan Fedotov : > > > > > Igor, thank you for explanation. > > > > > > Now it seems that when the one thread tries to invoke > > > GridCacheMapEntry#touch, the another one makes > > > GridCacheProcessor#stopCache. If I am wrong, please feel free to > correct > > me. > > > > > > But it still does not clear for me why this fail appears after commit > > > < > > > https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8 > > > > which > > > is about MVCC. Moreover, NPE appears only with BinaryObjectException, > and > > > when the test is green, I can not find NPE in the log. > > > > > > Now I tried to run test locally 1000 times on the version before MVCC > and > > > could not find error on this concretely case (but it exists the another > > > one > > > < > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L426 > > > > which > > > is about assertion on received events). > > > > > > пт, 30 нояб. 2018 г. в 13:37, Roman Kondakov > > >: > > > > > >> Nikolay, > > >> > > >> I couldn't quickly find the root cause of this problem because I'm not > > >> an expert in the binary metadata flow. I think community should decide > > >> whether this is a release blocker or not. > > >> > > >> > > >> -- > > >> Kind Regards > > >> Roman Kondakov > > >> > > >> On 30.11.2018 13:23, Nikolay Izhikov wrote: > > >> > Hello, Roman. > > >> > > > >> > Is this issue blocks the 2.7 release? > > >> > > > >> > пт, 30 нояб. 2018 г., 13:19 Roman Kondakov > kondako...@mail.ru.invalid > > : > > >> > > > >> >> Hi all! > > >> >> > > >> >> I've reproduced this problem locally and attached the log to the > > ticket > > >> >> in my comment [1]. > > >> >> > > >> >> As Igor noted, NPE there is caused by node stop in the end of the > > test. > > >> >> The real problem here seems to be in the binary metadata > registration > > >> flow. > > >> >> > > >> >> > > >> >> [1] > > >> >> > > >> >> > > >> > > > https://issues.apache.org/jira/browse/IGNITE-10376?focusedCommentId=16704510=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16704510 > > >> >> > > >&
Re: Apache Ignite 2.7. Last Mile
I've created the PR <https://github.com/apache/ignite/pull/5550> which includes changes <https://github.com/1vanan/ignite/commits/before-MVCC> just before integration MVCC with Continuous Query and from the TeamCity <https://ci.ignite.apache.org/viewLog.html?buildId=2434057=buildResultsDiv=IgniteTests24Java8_ContinuousQuery1> it is clear that before this changes the test testAtomicOnheapTwoBackupAsyncFullSync is green. Also Roman Kondakov gave his view on this problem in the comments <https://issues.apache.org/jira/browse/IGNITE-10376>. Now the problem becomes more understandable, but the root reason is still unclear. May be a few of you have any suggestions why hang of threads on the binary metadata registration future appears? пт, 30 нояб. 2018 г. в 13:48, Ivan Fedotov : > Igor, thank you for explanation. > > Now it seems that when the one thread tries to invoke > GridCacheMapEntry#touch, the another one makes > GridCacheProcessor#stopCache. If I am wrong, please feel free to correct me. > > But it still does not clear for me why this fail appears after commit > <https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8> > which > is about MVCC. Moreover, NPE appears only with BinaryObjectException, and > when the test is green, I can not find NPE in the log. > > Now I tried to run test locally 1000 times on the version before MVCC and > could not find error on this concretely case (but it exists the another > one > <https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L426> > which > is about assertion on received events). > > пт, 30 нояб. 2018 г. в 13:37, Roman Kondakov : > >> Nikolay, >> >> I couldn't quickly find the root cause of this problem because I'm not >> an expert in the binary metadata flow. I think community should decide >> whether this is a release blocker or not. >> >> >> -- >> Kind Regards >> Roman Kondakov >> >> On 30.11.2018 13:23, Nikolay Izhikov wrote: >> > Hello, Roman. >> > >> > Is this issue blocks the 2.7 release? >> > >> > пт, 30 нояб. 2018 г., 13:19 Roman Kondakov kondako...@mail.ru.invalid: >> > >> >> Hi all! >> >> >> >> I've reproduced this problem locally and attached the log to the ticket >> >> in my comment [1]. >> >> >> >> As Igor noted, NPE there is caused by node stop in the end of the test. >> >> The real problem here seems to be in the binary metadata registration >> flow. >> >> >> >> >> >> [1] >> >> >> >> >> https://issues.apache.org/jira/browse/IGNITE-10376?focusedCommentId=16704510=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16704510 >> >> >> >> -- >> >> Kind Regards >> >> Roman Kondakov >> >> >> >> On 30.11.2018 11:56, Seliverstov Igor wrote: >> >>> Null pointer there due to cache stop. Look at GridCacheContext#cleanup >> >>> (GridCacheContext.java:2050) >> >>> which is called by GridCacheProcessor#stopCache >> >>> (GridCacheProcessor.java:1372) >> >>> >> >>> That's why at the time GridCacheMapEntry#touch >> >> (GridCacheMapEntry.java:5063) >> >>>invoked there is no eviction manager. >> >>> >> >>> This is a result of "normal" flow because message processing doesn't >> >> enter >> >>> cache gate like user API does. >> >>> >> >>> пт, 30 нояб. 2018 г. в 10:26, Nikolay Izhikov : >> >>> >> >>>> Ivan. Please, provide a link for a ticket with NPE stack trace >> attached. >> >>>> >> >>>> I've looked at IGNITE-10376 and can't see any attachments. >> >>>> >> >>>> пт, 30 нояб. 2018 г., 10:14 Ivan Fedotov ivanan...@gmail.com: >> >>>> >> >>>>> Igor, >> >>>>> NPE is available in a full log, now I also attached it in the >> ticket. >> >>>>> >> >>>>> IGNITE-7953 >> >>>>> < >> >>>>> >> >> >> https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8 >> >>>>> was commited on the 15 October. I could not take a look on the >> >>>>> testAtomicOnheapTwoBackupAsyncFullSync before this
Re: Apache Ignite 2.7. Last Mile
Igor, thank you for explanation. Now it seems that when the one thread tries to invoke GridCacheMapEntry#touch, the another one makes GridCacheProcessor#stopCache. If I am wrong, please feel free to correct me. But it still does not clear for me why this fail appears after commit <https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8> which is about MVCC. Moreover, NPE appears only with BinaryObjectException, and when the test is green, I can not find NPE in the log. Now I tried to run test locally 1000 times on the version before MVCC and could not find error on this concretely case (but it exists the another one <https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L426> which is about assertion on received events). пт, 30 нояб. 2018 г. в 13:37, Roman Kondakov : > Nikolay, > > I couldn't quickly find the root cause of this problem because I'm not > an expert in the binary metadata flow. I think community should decide > whether this is a release blocker or not. > > > -- > Kind Regards > Roman Kondakov > > On 30.11.2018 13:23, Nikolay Izhikov wrote: > > Hello, Roman. > > > > Is this issue blocks the 2.7 release? > > > > пт, 30 нояб. 2018 г., 13:19 Roman Kondakov kondako...@mail.ru.invalid: > > > >> Hi all! > >> > >> I've reproduced this problem locally and attached the log to the ticket > >> in my comment [1]. > >> > >> As Igor noted, NPE there is caused by node stop in the end of the test. > >> The real problem here seems to be in the binary metadata registration > flow. > >> > >> > >> [1] > >> > >> > https://issues.apache.org/jira/browse/IGNITE-10376?focusedCommentId=16704510=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16704510 > >> > >> -- > >> Kind Regards > >> Roman Kondakov > >> > >> On 30.11.2018 11:56, Seliverstov Igor wrote: > >>> Null pointer there due to cache stop. Look at GridCacheContext#cleanup > >>> (GridCacheContext.java:2050) > >>> which is called by GridCacheProcessor#stopCache > >>> (GridCacheProcessor.java:1372) > >>> > >>> That's why at the time GridCacheMapEntry#touch > >> (GridCacheMapEntry.java:5063) > >>>invoked there is no eviction manager. > >>> > >>> This is a result of "normal" flow because message processing doesn't > >> enter > >>> cache gate like user API does. > >>> > >>> пт, 30 нояб. 2018 г. в 10:26, Nikolay Izhikov : > >>> > >>>> Ivan. Please, provide a link for a ticket with NPE stack trace > attached. > >>>> > >>>> I've looked at IGNITE-10376 and can't see any attachments. > >>>> > >>>> пт, 30 нояб. 2018 г., 10:14 Ivan Fedotov ivanan...@gmail.com: > >>>> > >>>>> Igor, > >>>>> NPE is available in a full log, now I also attached it in the ticket. > >>>>> > >>>>> IGNITE-7953 > >>>>> < > >>>>> > >> > https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8 > >>>>> was commited on the 15 October. I could not take a look on the > >>>>> testAtomicOnheapTwoBackupAsyncFullSync before this date, because the > >>>> oldest > >>>>> test in the history on TC dates 12 November. > >>>>> > >>>>> So, I tested it locally and could not reproduce mentioned error. > >>>>> > >>>>> чт, 29 нояб. 2018 г. в 20:07, Seliverstov Igor >: > >>>>> > >>>>>> Ivan, > >>>>>> > >>>>>> Could you provide a bit more details? > >>>>>> > >>>>>> I don't see any NPE among all available logs. > >>>>>> > >>>>>> I don't think the issue is caused by changes in scope of > IGNITE-7953. > >>>>>> The test fails both before > >>>>>> < > >>>>>> > >> > https://ci.ignite.apache.org/viewLog.html?buildId=2318582=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025 > >>>>>>and after > >>>>>> < > >>>>>> > >> > https://ci.ignite.apache.org/viewLog.html?buildId=2345403=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025 > >>>>>> the > >>>>>> commit was merged to master with almost the same stack trace. > >>>>>> > >>>>>> Regards, > >>>>>> Igor > >>>>>> > >>>>>> чт, 29 нояб. 2018 г. в 18:43, Yakov Zhdanov : > >>>>>> > >>>>>>> Vladimir, can you please take a look at > >>>>>>> https://issues.apache.org/jira/browse/IGNITE-10376? > >>>>>>> > >>>>>>> --Yakov > >>>>>>> > >>>>> -- > >>>>> Ivan Fedotov. > >>>>> > >>>>> ivanan...@gmail.com > >>>>> > -- Ivan Fedotov. ivanan...@gmail.com
Re: Apache Ignite 2.7. Last Mile
Igor, NPE is available in a full log, now I also attached it in the ticket. IGNITE-7953 <https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8> was commited on the 15 October. I could not take a look on the testAtomicOnheapTwoBackupAsyncFullSync before this date, because the oldest test in the history on TC dates 12 November. So, I tested it locally and could not reproduce mentioned error. чт, 29 нояб. 2018 г. в 20:07, Seliverstov Igor : > Ivan, > > Could you provide a bit more details? > > I don't see any NPE among all available logs. > > I don't think the issue is caused by changes in scope of IGNITE-7953. > The test fails both before > < > https://ci.ignite.apache.org/viewLog.html?buildId=2318582=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025 > > > and after > < > https://ci.ignite.apache.org/viewLog.html?buildId=2345403=buildResultsDiv=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025 > > > the > commit was merged to master with almost the same stack trace. > > Regards, > Igor > > чт, 29 нояб. 2018 г. в 18:43, Yakov Zhdanov : > > > Vladimir, can you please take a look at > > https://issues.apache.org/jira/browse/IGNITE-10376? > > > > --Yakov > > > -- Ivan Fedotov. ivanan...@gmail.com
Re: Apache Ignite 2.7. Last Mile
Hello Igniters. During my work at the ticket IGNITE-10376 <https://issues.apache.org/jira/browse/IGNITE-10376> I found that it started to fail after integration Continuous Query with MVCC. I launched CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync before corresponding commit <https://github.com/apache/ignite/commit/51a202a4c48220fa919f47147bd4889033cd35a8> and it works correctly more that 500 times. So, I think it is regression test, because in testAtomicOnheapTwoBackupAsyncFullSync atomic cache mode is used. What do you think, how does such problem relate with MVCC? What could be a possible way to resolve it? ср, 28 нояб. 2018 г. в 12:19, Vladimir Ozerov : > Fixed. Thank you for noting it. > > On Wed, Nov 28, 2018 at 6:22 AM Alexey Kuznetsov > wrote: > > > Hi, > > > > We found a regression https://issues.apache.org/jira/browse/IGNITE-10432 > > > > Please take a look. > > > > -- > > Alexey Kuznetsov > > > -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-10456) Lost data in cache after restart node
Ivan Fedotov created IGNITE-10456: - Summary: Lost data in cache after restart node Key: IGNITE-10456 URL: https://issues.apache.org/jira/browse/IGNITE-10456 Project: Ignite Issue Type: Test Reporter: Ivan Fedotov Assertion error arrises in [testGetRestartPartitioned2|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5440530939858694701=testDetails] during restart nodes. It seems that some data [was lost|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/IgniteCacheGetRestartTest.java#L188]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10442) Failed checks on successful tasks canceling
Ivan Fedotov created IGNITE-10442: - Summary: Failed checks on successful tasks canceling Key: IGNITE-10442 URL: https://issues.apache.org/jira/browse/IGNITE-10442 Project: Ignite Issue Type: Test Reporter: Ivan Fedotov Assignee: Ivan Fedotov [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] seems flaky. On of the reason - "Possible thread pool starvation detected". It is necessary to investigate test and fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10376) NPE during invocation from cache
Ivan Fedotov created IGNITE-10376: - Summary: NPE during invocation from cache Key: IGNITE-10376 URL: https://issues.apache.org/jira/browse/IGNITE-10376 Project: Ignite Issue Type: Test Reporter: Ivan Fedotov Assignee: Ivan Fedotov Null pointer exception sometimes appears in [ testAtomicOnheapTwoBackupAsyncFullSync|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3300126853696550025=testDetails]] at the [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371] of CacheEntryProcessor invocation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9051) Remove unnecessary ssh tests
Ivan Fedotov created IGNITE-9051: Summary: Remove unnecessary ssh tests Key: IGNITE-9051 URL: https://issues.apache.org/jira/browse/IGNITE-9051 Project: Ignite Issue Type: Test Reporter: Ivan Fedotov Assignee: Ivan Fedotov Now in IgniteProjectionStartStopRestartSelfTest there are two unnecessary tests [1], [2] that duplicate other tests. Its duplicate testStopNodesByIds and testRestartNodesByIds respectively because order of ids is not important: if we go deeper in ignite.cluster().stopNodes() method, we can see that in ClusterIgniteImpl [3] all nodes id will be collected in HashSet in forNodesIds method [4]. So testStopNodesByIdsC and testRestartNodesByIdsC should be removed. [1][https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L701] [2][https://github.com/apache/ignite/blob/master/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L917] [3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/cluster/IgniteClusterImpl.java#L250] [4][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/cluster/ClusterGroupAdapter.java#L454] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8919) Wrong documentation of exec methods in StartNodeCallableImpl class
Ivan Fedotov created IGNITE-8919: Summary: Wrong documentation of exec methods in StartNodeCallableImpl class Key: IGNITE-8919 URL: https://issues.apache.org/jira/browse/IGNITE-8919 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov It seems that in StartNodeCallableImpl class methods private String exec() have wrong documentation [1]. It's necessary to change documentation to more appropriate. [1]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L393 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8619) 'Remote node could not start' in ssh connection
Ivan Fedotov created IGNITE-8619: Summary: 'Remote node could not start' in ssh connection Key: IGNITE-8619 URL: https://issues.apache.org/jira/browse/IGNITE-8619 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Now there is a problem with launch remote node via ssh. Initially was an assumption that it's due to remote process has not enough time to write information into log: [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this correction didn't fix [TeamCity |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. So now it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8462) DataStreamerImpl.close(true) should throw exception
Ivan Fedotov created IGNITE-8462: Summary: DataStreamerImpl.close(true) should throw exception Key: IGNITE-8462 URL: https://issues.apache.org/jira/browse/IGNITE-8462 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov DataStreamerImpl.close(true) should throw CacheException in case if there was addition data to DataStreamerImpl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8104) Proper toString() implementation for IgniteConfiguration properties
Ivan Fedotov created IGNITE-8104:
Summary: Proper toString() implementation for IgniteConfiguration
properties
Key: IGNITE-8104
URL: https://issues.apache.org/jira/browse/IGNITE-8104
Project: Ignite
Issue Type: Improvement
Environment: In continuing of ticket Ignite-5798 'Logging Ignite
configuration at startup' [1] it's necessary to make proper {{toString()}}
implementation for every every logged configuration component, such the every
meaningful property should be properly logged.
[1]https://issues.apache.org/jira/browse/IGNITE-5798
Reporter: Ivan Fedotov
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8084) Unlock write lock in DataStreamerImpl
Ivan Fedotov created IGNITE-8084: Summary: Unlock write lock in DataStreamerImpl Key: IGNITE-8084 URL: https://issues.apache.org/jira/browse/IGNITE-8084 Project: Ignite Issue Type: Improvement Components: streaming Reporter: Ivan Fedotov Assignee: Ivan Fedotov Fix For: 2.5 In method DataStreamerImpl.CloseEx there is wrire lock without unlock [1]. I think this behavior is based on impossibility to call after closing other public method of DataStreamer, that use read lock. It's not correctly that after closing streamer we don't unlock writeLock: I think that we can use *closed* flag to throw exception if streamer will be used after closing. [1]https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1217 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7931) Wrong arguments for `keys` in DataStreamerImpl
Ivan Fedotov created IGNITE-7931:
Summary: Wrong arguments for `keys` in DataStreamerImpl
Key: IGNITE-7931
URL: https://issues.apache.org/jira/browse/IGNITE-7931
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov
When creating \{{keys=new (...);}} [1],[2] result of `U.capacity` is passed
as `loadfactor` value. When loadFactory == U.capacity, initial size of table is
1. This leads to performance penalty due to rehashing of internal map.
[1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L633]
[2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L574]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-6612) Wrap ack methods in their own class
Ivan Fedotov created IGNITE-6612: Summary: Wrap ack methods in their own class Key: IGNITE-6612 URL: https://issues.apache.org/jira/browse/IGNITE-6612 Project: Ignite Issue Type: Improvement Affects Versions: None Reporter: Ivan Fedotov Assignee: Ivan Fedotov Priority: Trivial Fix For: 2.3 Several methods in IgniteKernal implement similar functions: “ackAsciiLogo”, “ackConfigUrl”, “ackDaemon”, “ackOsInfo”, “ackLanguageRuntime”, “ackRemoteManagement”, “ackVmArguments”, “ackClassPaths”, “ackSystemProperties”, “ackEnviromentVariables”, “ackMemoryConfiguration”, “ackCacheConfiguration”, “ackP2PConfiguration”, “ackRebalanceConfiguration”. These methods should be placed in separate class “AckVariousInformation” and called from the class instance in IgniteKernal. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
