ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Kovalenko <jokse...@gmail.com>
Subject Re: IP finder in tests
Date Wed, 01 Aug 2018 12:20:42 GMT
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.spb@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 <dmekhanikov@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message