TcpDiscoveryIpFinder - shared register/unregister addresses

classic Classic list List threaded Threaded
4 messages Options
kevin kevin
Reply | Threaded
Open this post in threaded view
|

TcpDiscoveryIpFinder - shared register/unregister addresses

This post has NOT been accepted by the mailing list yet.
Hi,

I'm trying to find out that these are for? I couldn't find much documentation about how they can be used.
As far as I understand, the addresses are only used when a node starts up initially to find other nodes in the cluster. Once it has joined the cluster, why does it matter that the ip finder is shared or not? Or what would registering/unregistering an address do?

I'm trying to figure out if I can unregister a node from the cluster, and restart that node so that it starts a new cluster, and that the old cluster can't discover it. I'm wondering if these settings in TcpDiscoveryIpFinder will help.

Thanks
vkulichenko vkulichenko
Reply | Threaded
Open this post in threaded view
|

Re: TcpDiscoveryIpFinder - shared register/unregister addresses

kevin wrote
Hi,

I'm trying to find out that these are for? I couldn't find much documentation about how they can be used.
As far as I understand, the addresses are only used when a node starts up initially to find other nodes in the cluster. Once it has joined the cluster, why does it matter that the ip finder is shared or not? Or what would registering/unregistering an address do?

I'm trying to figure out if I can unregister a node from the cluster, and restart that node so that it starts a new cluster, and that the old cluster can't discover it. I'm wondering if these settings in TcpDiscoveryIpFinder will help.

Thanks
Any shared IP finder uses some kind of shared storage (S3, shared FS, etc.) to store coordinates of alive nodes. These coordinates are then used by nodes that are trying to join topology. So when a node joins, it reads available IPs from this storage, uses one of them to connect to topology and writes its own IP and port to the storage. When a node leaves, it removes its record.

In your scenario you will have to start the node with different configuration (different S3 bucket, different shared FS folder, etc., depending on what type of IP finder you're using).

Makes sense?

-Val
kevin kevin
Reply | Threaded
Open this post in threaded view
|

Re: TcpDiscoveryIpFinder - shared register/unregister addresses

This post has NOT been accepted by the mailing list yet.
Sorry, I meant to ask specifically about the TcpDiscoveryVmIpFinder. In this case, where would the shared storage be (in memory in the grid?) The list of IP addresses are pre-configured on the IP Finder, so a new node would have the list of IPs already before trying to join the topology. Is the shared flag and the registerAddresses/unregisterAddresses in the TcpDiscoveryVmIpFinder not really used for anything then?
vkulichenko vkulichenko
Reply | Threaded
Open this post in threaded view
|

Re: TcpDiscoveryIpFinder - shared register/unregister addresses

kevin wrote
Sorry, I meant to ask specifically about the TcpDiscoveryVmIpFinder. In this case, where would the shared storage be (in memory in the grid?) The list of IP addresses are pre-configured on the IP Finder, so a new node would have the list of IPs already before trying to join the topology. Is the shared flag and the registerAddresses/unregisterAddresses in the TcpDiscoveryVmIpFinder not really used for anything then?
TcpDiscoveryVmIpFinder in shared mode can be used only to start several nodes within one JVM. By default it's not shared and simply uses the list of addresses provided locally in the configuration, so it doesn't actually registers or unregisters addresses.

-Val