> > > Andrey Mashenkov, at first sight, I have not seen any problems with
> > > > > .NET platform.
> > > > >
> > > > > I believe we need carefully configure ports in platform's examples,
> > > > > additional actions shou
problems with
> > > > .NET platform.
> > > >
> > > > I believe we need carefully configure ports in platform's examples,
> > > > additional actions should not be required.
> > > >
> > > > On Mon, Dec 17, 2018 at 2:35 PM Vyac
> I believe we need carefully configure ports in platform's examples,
> > > additional actions should not be required.
> > >
> > > On Mon, Dec 17, 2018 at 2:35 PM Vyacheslav Daradur <
> daradu...@gmail.com>
> > > wrote:
> > > >
> > &g
wrote:
> > >
> > > The task [1] is done.
> > >
> > > 'TcpDiscoveryVmIpFinder' is default IP finder in tests now.
> > >
> > > The IP finder is initialized on per tests class level to avoid hidden
> > > affecting among tests, it means t
n platform's examples,
> additional actions should not be required.
>
> On Mon, Dec 17, 2018 at 2:35 PM Vyacheslav Daradur
> wrote:
> >
> > The task [1] is done.
> >
> > 'TcpDiscoveryVmIpFinder' is default IP finder in tests now.
> >
> > The IP fi
The task [1] is done.
'TcpDiscoveryVmIpFinder' is default IP finder in tests now.
The IP finder is initialized on per tests class level to avoid hidden
affecting among tests, it means the test methods in the common test
class will use the same IP finder.
You don't need to set up
s done.
>
> 'TcpDiscoveryVmIpFinder' is default IP finder in tests now.
>
> The IP finder is initialized on per tests class level to avoid hidden
> affecting among tests, it means the test methods in the common test
> class will use the same IP finder.
>
> You don't need to set up 'TcpDisc
> > Slava,
> > > +1 for your proposal.
> > > Is there any ticket for this?
> > >
> > > Denis,
> > > I've just read in nabble thread you suggest to allow multicast finder
> for
> > > multiJVM tests
> > > and I'd think we
nder for
> > multiJVM tests
> > and I'd think we shouldn't use multicast in test at all (excepts
> multicast
> > Ip finder self tests of course),
> > but e.g. add an assertion to force user to create ipfinder properly.
> >
> >
> > Also, we have a ticket
think we shouldn't use multicast in test at all (excepts multicast
> Ip finder self tests of course),
> but e.g. add an assertion to force user to create ipfinder properly.
>
>
> Also, we have a ticket for similar issue in 'examples' module.
> Seems, there are some issues with
Slava,
+1 for your proposal.
Is there any ticket for this?
Denis,
I've just read in nabble thread you suggest to allow multicast finder for
multiJVM tests
and I'd think we shouldn't use multicast in test at all (excepts multicast
Ip finder self tests of course),
but e.g. add an assertion to force
Vyacheslav Daradur created IGNITE-10555:
---
Summary: Set 'TcpDiscoveryVmIpFinder' as default IP finder for
tests instead of 'TcpDiscoveryMulticastIpFinder'
Key: IGNITE-10555
URL: https://issues.apache.org
++1
On Wed, Dec 5, 2018 at 5:55 PM Denis Mekhanikov
wrote:
> Slava,
>
> These are exactly my thoughts, so I fully support you here.
> I already wrote about it:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
> But I kind of abandone
Slava,
These are exactly my thoughts, so I fully support you here.
I already wrote about it:
http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
But I kind of abandoned this activity. Feel free to take over it.
Denis
ср, 5 дек. 2018 г. в 17:22, Vladimir Ozerov
Huge +1
On Wed, Dec 5, 2018 at 5:09 PM Vyacheslav Daradur
wrote:
> Igniters,
>
> I've found that the project's test framework uses
> 'TcpDiscoveryMulticastIpFinder' as default IP finder for tests and
> there are a lot of tests written by Ignite's expert
Igniters,
I've found that the project's test framework uses
'TcpDiscoveryMulticastIpFinder' as default IP finder for tests and
there are a lot of tests written by Ignite's experts that override it
to 'TcpDiscoveryVmIpFinder'.
Most of our tests starting Ignite nodes in the same JVM, that allows
problems and return back to this conversation.
> > I'm voting for simplifying and speeding up testing process. It will also
> > reduce the number of copy-paste in ton of tests, where Vm Ip Finder is
> used
> > explicitly. As developer I'm confusing when I see in a te
fying and speeding up testing process. It will also
> reduce the number of copy-paste in ton of tests, where Vm Ip Finder is used
> explicitly. As developer I'm confusing when I see in a test VmIpFinder and
> in other test Multicast without any reason or comment.
> If you care about test
to this conversation.
I'm voting for simplifying and speeding up testing process. It will also
reduce the number of copy-paste in ton of tests, where Vm Ip Finder is used
explicitly. As developer I'm confusing when I see in a test VmIpFinder and
in other test Multicast without any reason or comment.
If you care
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
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 sh
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 obje
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 wou
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
30 matches
Mail list logo
