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
>
> From: Yakov Zhdanov
> Sent: 28 февраля 2019 г. 12:53
> To: dev@ignite.apache.org
> 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 t
that off as well.
My 2 cents,
Stan
From: Yakov Zhdanov
Sent: 28 февраля 2019 г. 12:53
To: dev@ignite.apache.org
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
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
Guys, I remember we did this to
--Yakov
ср, 27 февр. 2019 г. в 14:46, 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
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
I've created https://issues.apache.org/jira/browse/IGNITE-6826
Thanks,
Alexey
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
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
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 :
> +1 to this.
>
> Should we go even further
+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 <
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
+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
wrote:
> Huge +1. We should have VM IP finder with localhost (127.0.0.1). First,
> there will be no network clashes,
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 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
14 matches
Mail list logo