ipFinder configuration for Samples

[Alexey Popov]

Hi, Igniters

I wonder why Ignite examples have multicast ipFinder for DiscoverySpi at
their configuration?
It is a quite common case to try them locally and Vm ipFinder is the best
option for that.
Multicast ipFinder adds some instability when several persons try & debug
samples or evaluate a new Ignite version at the same local network.

It looks like default ipFinder could simplify cluster deployment with
default configs. However, I hardly believe that someone deploys the samples
into remote hosts without changing IPs.

I propose to change default configs for examples from multicast to vm
ipFinder.

Thank you,
Alexey




--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[Vladimir Ozerov]

Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
there will be no network clashes, second user will see almost correct IP
config right away. All he need to change for production usage is IP address.

On Tue, Oct 31, 2017 at 9:58 AM, Alexey Popov <[hidden email]> wrote:

> Hi, Igniters
>
> I wonder why Ignite examples have multicast ipFinder for DiscoverySpi at
> their configuration?
> It is a quite common case to try them locally and Vm ipFinder is the best
> option for that.
> Multicast ipFinder adds some instability when several persons try & debug
> samples or evaluate a new Ignite version at the same local network.
>
> It looks like default ipFinder could simplify cluster deployment with
> default configs. However, I hardly believe that someone deploys the samples
> into remote hosts without changing IPs.
>
> I propose to change default configs for examples from multicast to vm
> ipFinder.
>
> Thank you,
> Alexey
>
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[Sergey Kozlov]

+1

There's the significant slowdown for a node start under Windows if the
multicast discovery used.

On Tue, Oct 31, 2017 at 10:37 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
> there will be no network clashes, second user will see almost correct IP
> config right away. All he need to change for production usage is IP
> address.
>
> On Tue, Oct 31, 2017 at 9:58 AM, Alexey Popov <[hidden email]>
> wrote:
>
> > Hi, Igniters
> >
> > I wonder why Ignite examples have multicast ipFinder for DiscoverySpi at
> > their configuration?
> > It is a quite common case to try them locally and Vm ipFinder is the best
> > option for that.
> > Multicast ipFinder adds some instability when several persons try & debug
> > samples or evaluate a new Ignite version at the same local network.
> >
> > It looks like default ipFinder could simplify cluster deployment with
> > default configs. However, I hardly believe that someone deploys the
> samples
> > into remote hosts without changing IPs.
> >
> > I propose to change default configs for examples from multicast to vm
> > ipFinder.
> >
> > Thank you,
> > Alexey
> >
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>

--
Sergey Kozlov
GridGain Systems
www.gridgain.com

[Evgeniy Ignatiev]

Also, maybe include in the examples reference to the recommended
failureDetectionTimeout setting and a preset value of 200ms for the
local Ignite (current default is 10 seconds)? It should greatly improve
start-up time for the VM IP finder.


On 10/31/2017 12:37 PM, Sergey Kozlov wrote:

> +1
>
> There's the significant slowdown for a node start under Windows if the
> multicast discovery used.
>
> On Tue, Oct 31, 2017 at 10:37 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
>> Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
>> there will be no network clashes, second user will see almost correct IP
>> config right away. All he need to change for production usage is IP
>> address.
>>
>> On Tue, Oct 31, 2017 at 9:58 AM, Alexey Popov <[hidden email]>
>> wrote:
>>
>>> Hi, Igniters
>>>
>>> I wonder why Ignite examples have multicast ipFinder for DiscoverySpi at
>>> their configuration?
>>> It is a quite common case to try them locally and Vm ipFinder is the best
>>> option for that.
>>> Multicast ipFinder adds some instability when several persons try & debug
>>> samples or evaluate a new Ignite version at the same local network.
>>>
>>> It looks like default ipFinder could simplify cluster deployment with
>>> default configs. However, I hardly believe that someone deploys the
>> samples
>>> into remote hosts without changing IPs.
>>>
>>> I propose to change default configs for examples from multicast to vm
>>> ipFinder.
>>>
>>> Thank you,
>>> Alexey
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>>
>
>

[Pavel Tupitsyn]

+1 to this.

Should we go even further and change Ignite configuration defaults to vm ip
finder?
Starting a standalone node with default config never works for me,
multicast stuff hangs on my network for some reason.

Pavel

On Tue, Oct 31, 2017 at 12:00 PM, Evgeniy Ignatiev <
[hidden email]> wrote:

> Also, maybe include in the examples reference to the recommended
> failureDetectionTimeout setting and a preset value of 200ms for the local
> Ignite (current default is 10 seconds)? It should greatly improve start-up
> time for the VM IP finder.
>
>
>
> On 10/31/2017 12:37 PM, Sergey Kozlov wrote:
>
>> +1
>>
>> There's the significant slowdown for a node start under Windows if the
>> multicast discovery used.
>>
>> On Tue, Oct 31, 2017 at 10:37 AM, Vladimir Ozerov <[hidden email]>
>> wrote:
>>
>> Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
>>> there will be no network clashes, second user will see almost correct IP
>>> config right away. All he need to change for production usage is IP
>>> address.
>>>
>>> On Tue, Oct 31, 2017 at 9:58 AM, Alexey Popov <[hidden email]>
>>> wrote:
>>>
>>> Hi, Igniters
>>>>
>>>> I wonder why Ignite examples have multicast ipFinder for DiscoverySpi at
>>>> their configuration?
>>>> It is a quite common case to try them locally and Vm ipFinder is the
>>>> best
>>>> option for that.
>>>> Multicast ipFinder adds some instability when several persons try &
>>>> debug
>>>> samples or evaluate a new Ignite version at the same local network.
>>>>
>>>> It looks like default ipFinder could simplify cluster deployment with
>>>> default configs. However, I hardly believe that someone deploys the
>>>>
>>> samples
>>>
>>>> into remote hosts without changing IPs.
>>>>
>>>> I propose to change default configs for examples from multicast to vm
>>>> ipFinder.
>>>>
>>>> Thank you,
>>>> Alexey
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>>>
>>>>
>>
>>
>

[Vladimir Ozerov]

Changing failureDetectionTimeout is bad idea, because if used in practice
it will increase probability of node failures due to GC or short network
glitches. We should not change it.

вт, 31 окт. 2017 г. в 12:54, Pavel Tupitsyn <[hidden email]>:

> +1 to this.
>
> Should we go even further and change Ignite configuration defaults to vm ip
> finder?
> Starting a standalone node with default config never works for me,
> multicast stuff hangs on my network for some reason.
>
> Pavel
>
> On Tue, Oct 31, 2017 at 12:00 PM, Evgeniy Ignatiev <
> [hidden email]> wrote:
>
> > Also, maybe include in the examples reference to the recommended
> > failureDetectionTimeout setting and a preset value of 200ms for the local
> > Ignite (current default is 10 seconds)? It should greatly improve
> start-up
> > time for the VM IP finder.
> >
> >
> >
> > On 10/31/2017 12:37 PM, Sergey Kozlov wrote:
> >
> >> +1
> >>
> >> There's the significant slowdown for a node start under Windows if the
> >> multicast discovery used.
> >>
> >> On Tue, Oct 31, 2017 at 10:37 AM, Vladimir Ozerov <[hidden email]
> >
> >> wrote:
> >>
> >> Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
> >>> there will be no network clashes, second user will see almost correct
> IP
> >>> config right away. All he need to change for production usage is IP
> >>> address.
> >>>
> >>> On Tue, Oct 31, 2017 at 9:58 AM, Alexey Popov <[hidden email]>
> >>> wrote:
> >>>
> >>> Hi, Igniters
> >>>>
> >>>> I wonder why Ignite examples have multicast ipFinder for DiscoverySpi
> at
> >>>> their configuration?
> >>>> It is a quite common case to try them locally and Vm ipFinder is the
> >>>> best
> >>>> option for that.
> >>>> Multicast ipFinder adds some instability when several persons try &
> >>>> debug
> >>>> samples or evaluate a new Ignite version at the same local network.
> >>>>
> >>>> It looks like default ipFinder could simplify cluster deployment with
> >>>> default configs. However, I hardly believe that someone deploys the
> >>>>
> >>> samples
> >>>
> >>>> into remote hosts without changing IPs.
> >>>>
> >>>> I propose to change default configs for examples from multicast to vm
> >>>> ipFinder.
> >>>>
> >>>> Thank you,
> >>>> Alexey
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >>>>
> >>>>
> >>
> >>
> >
>

[Evgeniy Ignatiev]

If having reduced timeout in example seems like a bad idea - then maybe
just add it with a safe value of 10s and a comment with a reference to
the documentation of tuning it -
https://apacheignite.readme.io/docs/cluster-config#failure-detection-timeout 
?

 From my experience people tend to judge Ignite startup time without
actually ever looking at that property. At least this will encourage
users to think if they can tune it.


On 10/31/2017 2:30 PM, Vladimir Ozerov wrote:

> Changing failureDetectionTimeout is bad idea, because if used in practice
> it will increase probability of node failures due to GC or short network
> glitches. We should not change it.
>
> вт, 31 окт. 2017 г. в 12:54, Pavel Tupitsyn <[hidden email]>:
>
>> +1 to this.
>>
>> Should we go even further and change Ignite configuration defaults to vm ip
>> finder?
>> Starting a standalone node with default config never works for me,
>> multicast stuff hangs on my network for some reason.
>>
>> Pavel
>>
>> On Tue, Oct 31, 2017 at 12:00 PM, Evgeniy Ignatiev <
>> [hidden email]> wrote:
>>
>>> Also, maybe include in the examples reference to the recommended
>>> failureDetectionTimeout setting and a preset value of 200ms for the local
>>> Ignite (current default is 10 seconds)? It should greatly improve
>> start-up
>>> time for the VM IP finder.
>>>
>>>
>>>
>>> On 10/31/2017 12:37 PM, Sergey Kozlov wrote:
>>>
>>>> +1
>>>>
>>>> There's the significant slowdown for a node start under Windows if the
>>>> multicast discovery used.
>>>>
>>>> On Tue, Oct 31, 2017 at 10:37 AM, Vladimir Ozerov <[hidden email]
>>>> wrote:
>>>>
>>>> Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
>>>>> there will be no network clashes, second user will see almost correct
>> IP
>>>>> config right away. All he need to change for production usage is IP
>>>>> address.
>>>>>
>>>>> On Tue, Oct 31, 2017 at 9:58 AM, Alexey Popov <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> Hi, Igniters
>>>>>> I wonder why Ignite examples have multicast ipFinder for DiscoverySpi
>> at
>>>>>> their configuration?
>>>>>> It is a quite common case to try them locally and Vm ipFinder is the
>>>>>> best
>>>>>> option for that.
>>>>>> Multicast ipFinder adds some instability when several persons try &
>>>>>> debug
>>>>>> samples or evaluate a new Ignite version at the same local network.
>>>>>>
>>>>>> It looks like default ipFinder could simplify cluster deployment with
>>>>>> default configs. However, I hardly believe that someone deploys the
>>>>>>
>>>>> samples
>>>>>
>>>>>> into remote hosts without changing IPs.
>>>>>>
>>>>>> I propose to change default configs for examples from multicast to vm
>>>>>> ipFinder.
>>>>>>
>>>>>> Thank you,
>>>>>> Alexey
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>>>>>
>>>>>>
>>>>

[Alexey Popov]

I've created https://issues.apache.org/jira/browse/IGNITE-6826

Thanks,
Alexey



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[Dmitrii Ryabov]

Hello, Igniters!

Code is ready and reviewed, tests are passed.

Can we make final decision about this change? Do we really need it? [1]

Pros:

* Multicast ipFinder adds some instability when several persons try & debug
samples or evaluate a new Ignite version at the same local network.
* Speedup for node start.
* Same change was made for test framework [2].

[1]
https://issues.apache.org/jira/browse/IGNITE-6826?focusedCommentId=16752473&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16752473
[2] https://issues.apache.org/jira/browse/IGNITE-10555

пт, 3 нояб. 2017 г., 11:14 Alexey Popov <[hidden email]>:

> I've created https://issues.apache.org/jira/browse/IGNITE-6826
>
> Thanks,
> Alexey
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[yzhdanov]

Guys, I remember we did this to
--Yakov


ср, 27 февр. 2019 г. в 14:46, Dmitrii Ryabov <[hidden email]>:

> Hello, Igniters!
>
> Code is ready and reviewed, tests are passed.
>
> Can we make final decision about this change? Do we really need it? [1]
>
> Pros:
>
> * Multicast ipFinder adds some instability when several persons try & debug
> samples or evaluate a new Ignite version at the same local network.
> * Speedup for node start.
> * Same change was made for test framework [2].
>
> [1]
>
> https://issues.apache.org/jira/browse/IGNITE-6826?focusedCommentId=16752473&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16752473
> [2] https://issues.apache.org/jira/browse/IGNITE-10555
>
> пт, 3 нояб. 2017 г., 11:14 Alexey Popov <[hidden email]>:
>
> > I've created https://issues.apache.org/jira/browse/IGNITE-6826
> >
> > Thanks,
> > Alexey
> >
> >
> >
> > --
> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> >
>

[yzhdanov]

Guys,

I remember we did the opposite change some time ago - switched VM IP finder
to multicast. That was done for user being able to start cluster spanning
multiple machines using examples configuration. With this change you
removed all the working samples for starting really distributed environment.

What was the problem? Multicast IP finder has the list of addresses that we
try to connect to on start. As far as clashes - it seems it affects only
engineers sitting in one office, but they can set up env var to override
default mcast group. The primary goal for switching to multicast was to
allow people new to Ignite to quickly start the cluster.

As far as I remember hazelcast has multicast enabled by default. Can
anybody check this?

--Yakov

[Stanislav Lukyanov]

Yakov,

Our product is for engineers sitting in one office.
Companies which use Ignite have many engineers running Ignite on their laptops the same way
as companies that make changes to Ignite.
 “Could it be because of the multicast?” is one of the questions I ask every time I see a question on SO
or user list, and I would be happy not to.

The activity of changing the examples from multicast to local addresses was started and stopped multiple times,
but AFAIR most of the community was in favor of this change.

Moreover, our default configuration (when discoSpi is not set– such as in default-config.xml)
uses multicast. I’d change that to a localhost VmIPFinder.

If we want an easy start of the examples (even though I think each user would want to use examples with multicast
exactly once, if ever) let’s add multiple configs or a switch to ignite.sh. I believe it’s better than showing multicast as default.

Regarding the address list – AFAIR Ignite tries to scan the multicast group first. Only after that it
will try to connect to addresses from the list. So, the list is a bit misleading.

Finally, if Hazelcast uses multicast by default – well, probably they should turn that off as well.

My 2 cents,
Stan

From: Yakov Zhdanov
Sent: 28 февраля 2019 г. 12:53
To: [hidden email]
Subject: Re: ipFinder configuration for Samples

Guys,

I remember we did the opposite change some time ago - switched VM IP finder
to multicast. That was done for user being able to start cluster spanning
multiple machines using examples configuration. With this change you
removed all the working samples for starting really distributed environment.

What was the problem? Multicast IP finder has the list of addresses that we
try to connect to on start. As far as clashes - it seems it affects only
engineers sitting in one office, but they can set up env var to override
default mcast group. The primary goal for switching to multicast was to
allow people new to Ignite to quickly start the cluster.

As far as I remember hazelcast has multicast enabled by default. Can
anybody check this?

--Yakov

[Dmitrii Ryabov]

Yakov,

I checked hazelcast - it uses multicast by default.

чт, 28 февр. 2019 г., 14:31 Stanislav Lukyanov <[hidden email]>:

> Yakov,
>
> Our product is for engineers sitting in one office.
> Companies which use Ignite have many engineers running Ignite on their
> laptops the same way
> as companies that make changes to Ignite.
>  “Could it be because of the multicast?” is one of the questions I ask
> every time I see a question on SO
> or user list, and I would be happy not to.
>
> The activity of changing the examples from multicast to local addresses
> was started and stopped multiple times,
> but AFAIR most of the community was in favor of this change.
>
> Moreover, our default configuration (when discoSpi is not set– such as in
> default-config.xml)
> uses multicast. I’d change that to a localhost VmIPFinder.
>
> If we want an easy start of the examples (even though I think each user
> would want to use examples with multicast
> exactly once, if ever) let’s add multiple configs or a switch to
> ignite.sh. I believe it’s better than showing multicast as default.
>
> Regarding the address list – AFAIR Ignite tries to scan the multicast
> group first. Only after that it
> will try to connect to addresses from the list. So, the list is a bit
> misleading.
>
> Finally, if Hazelcast uses multicast by default – well, probably they
> should turn that off as well.
>
> My 2 cents,
> Stan
>
> From: Yakov Zhdanov
> Sent: 28 февраля 2019 г. 12:53
> To: [hidden email]
> Subject: Re: ipFinder configuration for Samples
>
> Guys,
>
> I remember we did the opposite change some time ago - switched VM IP finder
> to multicast. That was done for user being able to start cluster spanning
> multiple machines using examples configuration. With this change you
> removed all the working samples for starting really distributed
> environment.
>
> What was the problem? Multicast IP finder has the list of addresses that we
> try to connect to on start. As far as clashes - it seems it affects only
> engineers sitting in one office, but they can set up env var to override
> default mcast group. The primary goal for switching to multicast was to
> allow people new to Ignite to quickly start the cluster.
>
> As far as I remember hazelcast has multicast enabled by default. Can
> anybody check this?
>
> --Yakov
>
>

[yzhdanov]

Stan, I thnk we never know the truth here. Imagine you never dealed with
distributed systems. You just copy distibs to intended machines and startup
distributed cluster out of the box. Is not it good? If we do the change we
should expect many questions to user@ asking why nodes do not see each
other. Agree?

--Yakov