Well, I tend to agree. Can you try applying it on some suite and share the
results in terms of run time decrease and decreasing number of random
failures due to improper tests stop or cleanup?
--Yakov
2018-08-02 16:37 GMT+03:00 Denis Mekhanikov :
> Yakov,
>
> Almost every test in the project
Yakov,
Almost every test in the project uses the Vm IP finder anyway.
It has become a convention to use it in all tests.
So, I'm trying to reduce the amount of copy-pasted code and improve test's
isolation.
Also tests may be run outside TeamCity during development process.
Multicast Ip Finder
Hi Yakov,
Currently TC agents defended by Docker virtual network, that's why we don't
see intersection between several clusters, but in case of any step aside
(running several suites on one agent, running several tests on one machine
and so on) we will have problems and return back to this
It should be true, otherwise we would have nodes from all agents
intersecting. No?
And multicast IP finder is the defailt one, so I would not reduce its test
volume.
Yakov Zhdanov
www.gridgain.com
2018-08-02 0:32 GMT+03:00 Dmitriy Pavlov :
> Hi Yakov,
>
> Regarding Each TC agent use own
Hi Yakov,
Regarding Each TC agent use own multicast: I'm not sure it is true, TC
admins tried to do so, but not succeded.
One more reason is speed of tests run. Why do we need to scan something if
we always will connect localhost. TC tests do not use multicast in almost
every test.
Sincerely,
I disagree. Probably, no change required. Each TC agent use own multicast
group so nodes do not intersect. If any of the test does not properly clean
up and leaves nodes running this dhould be flagged as test fail which is
the case.
Please provide strong reasons to start with this.
--Yakov
ll) tests.
> > >
> > > Stan
> > >
> > > From: Dmitriy Pavlov
> > > Sent: 1 августа 2018 г. 14:21
> > > To: dev@ignite.apache.org
> > > Subject: Re: IP finder in tests
> > >
> > > Hi Denis,
> > >
>
Sent: 1 августа 2018 г. 14:21
> > To: dev@ignite.apache.org
> > Subject: Re: IP finder in tests
> >
> > Hi Denis,
> >
> > Thank you for bringing the question here.
> >
> > I totally support this change.
> >
> > Sincerely,
> >
it’ll be enough for most (if not all) tests.
>
> Stan
>
> From: Dmitriy Pavlov
> Sent: 1 августа 2018 г. 14:21
> To: dev@ignite.apache.org
> Subject: Re: IP finder in tests
>
> Hi Denis,
>
> Thank you for bringing the question here.
>
> I totally support this change.
+1.
I don’t see why do we need to fallback to multicast for multi-JVM – let’s just
set 127.0.0.1:47500..47509 by default,
it’ll be enough for most (if not all) tests.
Stan
From: Dmitriy Pavlov
Sent: 1 августа 2018 г. 14:21
To: dev@ignite.apache.org
Subject: Re: IP finder in tests
Hi Denis
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 -
Hi Denis,
Thank you for bringing the question here.
I totally support this change.
Sincerely,
Dmitriy Pavlov
ср, 1 авг. 2018 г. в 13:23, Denis Mekhanikov :
> Igniters,
>
> Almost every test in Ignite project has the following pattern: shared
> *TcpDiscoveryVmIpFinder
> *is defined as a field
Hello!
I think it's a sensible decision that is long overdue.
Regards,
--
Ilya Kasnacheev
2018-08-01 13:22 GMT+03:00 Denis Mekhanikov :
> Igniters,
>
> Almost every test in Ignite project has the following pattern: shared
> *TcpDiscoveryVmIpFinder
> *is defined as a field of a test class,
13 matches
Mail list logo
