David,
Skipping connection to an address that is declared as local by the local
node is an absolutely valid idea. Though, will it be always the case that
nodes will have the same IP for this bogus interface? We have a similar
check for loopback addresses, I see nothing wrong with adding the same
c
David,
This is a problem, that many people encounter. And I think, it's about time
to deal with it.
We have the following method, that collects all local addresses, that will
be sent with node
attributes: *IgniteUtils#resolveLocalAddresses()*. And it iterates over all
local interfaces, that
the m
What we prototyped was configuring via spring the list of IPs to ignore,
because a given installation seemed to have a constant address for the
bridge network, and this approach was reliable, once you know the bridge
IPs. It is also a more general solution.
When the container starts, you get a l
What we prototyped was configuring via spring the list of IPs to ignore,
because a given installation seemed to have a constant address for the
bridge network, and this approach was reliable, once you know the bridge
IPs.
When the container starts, you get a list of IP addresses from the kernel.
Hi David,
This is something we have also encountered recently and I was wondering how
this can be mitigated in a general case. Do you know if an application can
detect that it is being run in a docker container and add the corresponding
list of bridge IPs automatically on start? If so, I this we c
We see some annoying behavior with S3 discovery because Ignite will push to
the discovery S3 bucket the IP address of the local docker bridge network
(172.17.0.1) in our case. Basically, each node when coming online tries
that address first, and has to go through a network timeout to recover.
To
