Hi Denis, I also definitely support this change. As an engineer who tightly working with MakeTeamCityGreenAgain activity, I notice several test suites hanging related with MulticastIpFinder infinite loops on datagram receiving. Here is last recorded fail - https://ci.ignite.apache.org/viewLog.html?buildId=1544659&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic .
Changing default ipFinder in tests to VM will help with TeamCity stability. 2018-08-01 14:20 GMT+03:00 Dmitriy Pavlov <dpavlov....@gmail.com>: > Hi Denis, > > Thank you for bringing the question here. > > I totally support this change. > > Sincerely, > Dmitriy Pavlov > > ср, 1 авг. 2018 г. в 13:23, Denis Mekhanikov <dmekhani...@gmail.com>: > > > Igniters, > > > > Almost every test in Ignite project has the following pattern: shared > > *TcpDiscoveryVmIpFinder > > *is defined as a field of a test class, which is then used in discovery > > configuration in *getConfiguration(...)* method. There are more than 700 > > test classes with this setup. > > > > But for some reason *TcpDiscoveryMulticastIpFinder *is used in tests by > > default. I don't think, that it should be used in tests at all, since > > external nodes may accidentally affect test results. > > > > The only case, where it makes sense is multi JVM tests. Shared static IP > > finder is not applicable there, since nodes are run in different JVMs and > > cannot share the same IP finder object. > > > > I would like to change the default IP finder to a shared > > *TcpDiscoveryVmIpFinder. > > *In cases, when *GridAbstractTest#isMultiJvm() *returns *true*, we could > > fall back to multicast. > > > > What do you think? > > > > Denis > > >
