I am 100% sure, cause "*telnet <public-ip> 11211*" works just perfect.
Igor On Mon, Jun 26, 2017 at 3:32 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Igor, > > Are you sure these connections are not blocked by firewall? If you provide > addresses explicitly in static IP finder, then it doesn't matter what is > published in shared IP finder. Is it possible that public addresses are > actually published and connectivity issue is caused by something else? > > -Val > > On Mon, Jun 26, 2017 at 3:01 PM, Igor Rudyak <irud...@gmail.com> wrote: > > > Val, > > > > Regarding resolver it makes sense. > > > > Actually as of now, Option 2 doesn't work to connect Ignite clients to > > cluster using private-to-public IPs mapping. It just falls into infinite > > connection loop and periodically reports something like this: > > > > *[14:42:15] Failed to connect to any address from IP finder (will retry > to > > join topology every 2 secs): [/0:0:0:0:0:0:0:1%1:47500, /127.0.0.1:47500 > > <http://127.0.0.1:47500>, /<server-1-private-ip>:47500, > > /<server-2-private-ip>:47500, /<server-3-private-ip>:47500]* > > > > Even if I manually specify all public IPs for discovery, like this: > > > > *<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">* > > * <property name="ipFinder">* > > * <bean > > class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast. > > TcpDiscoveryMulticastIpFinder">* > > * <property name="addresses">* > > * <list>* > > * <value><server-1-public-ip></value>* > > * <value><server-2-public-ip></value>* > > * <value><server-3-public-ip></value>* > > * </list>* > > * </property>* > > * </bean>* > > * </property>* > > *</bean>* > > > > It still can't connect to cluster and just periodically reports the same > > error. > > > > Does actually cluster membership protocol support the case when node > > available through multiple IP addresses and treats <ip-address-1>, > > <ip-address-2> and etc. as just different IPs corresponding to the same > > node? > > > > > > Igor > > > > On Mon, Jun 26, 2017 at 1:55 PM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Igor, > > > > > > It depends on how address resolver works. But I agree, in general case > > it's > > > possible that a node can only resolve public address for itself. In > such > > > scenario we must publish public addresses in IP finder. > > > > > > -Val > > > > > > On Mon, Jun 26, 2017 at 1:02 PM, Igor Rudyak <irud...@gmail.com> > wrote: > > > > > > > Option 2 also will not work for IaaS environments, where node can > > > > dynamically join or leave cluster. > > > > > > > > Igor > > > > > > > > On Jun 26, 2017 12:12 PM, "Valentin Kulichenko" < > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > Yakov, > > > > > > > > > > Nodes that join outside of the network (usually these are clients) > > need > > > > to > > > > > know public addresses to connect. To make it work either of these > > must > > > > > happen: > > > > > > > > > > 1. Server nodes publish their public addresses in IP finder so that > > > > clients > > > > > can use them to connect. > > > > > 2. Client nodes use address resolver to map published internal > > > addresses > > > > to > > > > > public addresses. > > > > > > > > > > Both will work, but frankly I like option 1 more. First of all, > it's > > > just > > > > > more intuitive that IP finder contains all possible addresses that > > can > > > be > > > > > used to join. Second of all, option 2 introduces requirement to > have > > > > > address resolver for server addresses configured on client nodes - > > this > > > > is > > > > > not very good from usability standpoint. > > > > > > > > > > -Val > > > > > > > > > > On Mon, Jun 26, 2017 at 3:17 AM, Yakov Zhdanov < > yzhda...@apache.org> > > > > > wrote: > > > > > > > > > > > Guys, I don't get the point. > > > > > > > > > > > > 1. Why addresses processed by address resolver should appear in > > > shared > > > > > > finder? In my understanding finders contain only internal IPs > which > > > > > should > > > > > > be processed by a resolver. > > > > > > > > > > > > 2. This one is very critical. Nikolay and Anton, how can I review > > the > > > > > > changes?! Please update the ticket with PR or commit hash. > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > >
