Thanks Gabor, I created a PR for it: https://github.com/apache/flink/pull/27284 If I understand correctly, there is no need for a new ticket or reopening the old one for this.
On Thu, Nov 27, 2025 at 6:33 PM Gabor Somogyi <[email protected]> wrote: > > 1.20 is an LTS version so go on. > > G > > > On Thu, Nov 27, 2025, 18:00 Gyula Komlossi <[email protected]> wrote: >> >> While trying to make the REST endpoints on my 1.20 Flink environment >> work with SSL, I discovered that the 0.0.0.0 bind-address solution >> won't work in this release. >> >> It is because in YarnEntrypointUtils, the bind address is overwritten >> with the hostname, before it was used for creating the endpoint :) >> https://github.com/apache/flink/blob/release-1.20/flink-yarn/src/main/java/org/apache/flink/yarn/entrypoint/YarnEntrypointUtils.java#L68 >> >> This commit should be cherry-picked to release-1.20. if we want to make it >> work: >> https://github.com/apache/flink/commit/b138d47adbed9fc1e5a73cebf649530bc5b89e6e >> >> Do you think it's worth a Jira and the effort? Will there be more 1.20 >> bugfix releases in the future? >> >> Thanks, >> Gyula >> >> On Thu, Nov 27, 2025 at 9:51 AM Gyula Komlossi <[email protected]> wrote: >> > >> > Hi Gabor, >> > >> > Thanks for the quick response. I was wondering how a third config >> > parameter cloud be avoided. There are two already (rest.address and >> > rest.bind-address) and a third one would make confusion, but I >> > understand, the existing behavior shouldn't be changed. >> > Also the rest.address is supposed to be "The address that should be >> > used by clients to connect to the server". Just like with the Kafka >> > advertised listeners. >> > >> > For my testing I just added an extra condition to this: >> > if (bindAddress.getAddress().isAnyLocalAddress() || isHttpsEnabled()) { >> > advertisedAddress = this.restAddress; >> > } else { >> > advertisedAddress = bindAddress.getAddress().getHostAddress(); >> > } >> > but it's far from ideal, it's just a workaround for now :) >> > >> > So I don't have a real alternative for this.. >> > >> > Best, >> > Gyula >> > >> > On Thu, Nov 27, 2025 at 9:04 AM Gabor Somogyi <[email protected]> >> > wrote: >> > > >> > > BTW if you have any alternative way just share it either in the jira or >> > > in PR 🙂 >> > > >> > > On Thu, Nov 27, 2025 at 9:02 AM Gabor Somogyi >> > > <[email protected]> wrote: >> > >> >> > >> Hi Gyula, >> > >> >> > >> We've discussed the issue but no PR available yet. >> > >> Feel free and cc me if you have time... >> > >> >> > >> BR, >> > >> G >> > >> >> > >> >> > >> On Thu, Nov 27, 2025 at 8:52 AM Gyula Komlossi <[email protected]> >> > >> wrote: >> > >>> >> > >>> Hi Yaroslav, Gabor, >> > >>> >> > >>> I just ran into this issue, when tried to configure SSL for the REST >> > >>> endpoint. I'm wondering what the preferred approach is with HTTPS on >> > >>> this REST endpoint or if there is any code change in progress. >> > >>> Have you been able to solve this one way or another, or started >> > >>> preparing a code change for it? >> > >>> >> > >>> I was able to make this work with a small code change in the >> > >>> RestServerEndpoint class to use the rest.address as the >> > >>> advertisedAddress with HTTPS, but I’m looking forward to the official >> > >>> improvement. >> > >>> Thank you both for taking care of this! >> > >>> >> > >>> Best, >> > >>> Gyula >> > >>> >> > >>> >> > >>> On 2025/08/19 20:34:06 Yaroslav Chernysh wrote: >> > >>> > https://issues.apache.org/jira/browse/FLINK-38269 >> > >>> > >> > >>> > On 2025/08/19 18:58:59 Gabor Somogyi wrote: >> > >>> > > You can file a jira and open a PR too so feel free. >> > >>> > > >> > >>> > > G >> > >>> > > >> > >>> > > On Tue, Aug 19, 2025, 19:51 Yaroslav Chernysh <[email protected]> >> > >>> > wrote: >> > >>> > > >> > >>> > > > Hi Gabor, >> > >>> > > > >> > >>> > > > >> > >>> > > > Just to avoid any misunderstanding, I've been waiting for the >> > >>> > ticket >> > >>> > > > from you. I assumed that you were going to do it. Please let me >> > >>> > know if >> > >>> > > > I got you wrong and I should create it myself. >> > >>> > > > >> > >>> > > > >> > >>> > > > Best regards, >> > >>> > > > >> > >>> > > > Yaroslav >> > >>> > > > >> > >>> > > > >> > >>> > > > On 2025/08/18 14:07:51 Gabor Somogyi wrote: >> > >>> > > > > Yeah, please read the how to contribute guide if you haven't >> > >>> > done >> > >>> > > > already. >> > >>> > > > > >> > >>> > > > > G >> > >>> > > > > >> > >>> > > > > On Mon, Aug 18, 2025 at 4:00 PM Yaroslav Chernysh >> > >>> > <[email protected]> >> > >>> > > > > wrote: >> > >>> > > > > >> > >>> > > > > > Hi Gabor, >> > >>> > > > > > >> > >>> > > > > > >> > >>> > > > > > Thanks, let's add a new option then to make advertised >> > >>> > address >> > >>> > > > > > configurable and document the default behavior. Would you >> > >>> > mind >> > >>> > filing >> > >>> > > > a >> > >>> > > > > > ticket for that? >> > >>> > > > > > >> > >>> > > > > > >> > >>> > > > > > Regards, >> > >>> > > > > > >> > >>> > > > > > Yaroslav >> > >>> > > > > > >> > >>> > > > > > >> > >>> > > > > > On 2025/08/18 13:41:54 Gabor Somogyi wrote: >> > >>> > > > > > > Hi Yaroslav, >> > >>> > > > > > > >> > >>> > > > > > > Having a config option to advertise something else is >> > >>> > what I can >> > >>> > > > > > support. >> > >>> > > > > > > Needless to say the actual behavior would remain as >> > >>> > default. >> > >>> > > > > > > >> > >>> > > > > > > G >> > >>> > > > > > > >> > >>> > > > > > > >> > >>> > > > > > > On Mon, Aug 18, 2025 at 3:28 PM Yaroslav Chernysh >> > >>> > <[email protected]> >> > >>> > > > > > > wrote: >> > >>> > > > > > > >> > >>> > > > > > > > Hi Gabor, >> > >>> > > > > > > > >> > >>> > > > > > > > I got your point on using `getHostName()`. Thank you >> > >>> > for such a >> > >>> > > > > > detailed >> > >>> > > > > > > > explanation. >> > >>> > > > > > > > >> > >>> > > > > > > > What do you think about advertising rest.address >> > >>> > instead? In >> > >>> > > > case of >> > >>> > > > > > > > YARN (at least on my environment), this is already set >> > >>> > by YARN >> > >>> > > > to a NM >> > >>> > > > > > > > hostname, so rDNS would be avoided. >> > >>> > > > > > > > >> > >>> > > > > > > > Thanks, >> > >>> > > > > > > > >> > >>> > > > > > > > Yaroslav >> > >>> > > > > > > > >> > >>> > > > > > > > >> > >>> > > > > > > > On 2025/08/15 21:12:58 Gabor Somogyi wrote: >> > >>> > > > > > > > > Hi Yaroslav, >> > >>> > > > > > > > > >> > >>> > > > > > > > > Thanks for your efforts in finding out all the >> > >>> > details. >> > >>> > > > > > > > > >> > >>> > > > > > > > > I think making `getHostName` possible with a config + >> > >>> > some >> > >>> > > > > > additional >> > >>> > > > > > > > > warnings in the documentation can be considered. >> > >>> > > > > > > > > You need to evaluate your security standards but you >> > >>> > win >> > >>> > > > something >> > >>> > > > > > on >> > >>> > > > > > > > one >> > >>> > > > > > > > > side and introduce new attack vector on the other >> > >>> > side. >> > >>> > > > > > > > > >> > >>> > > > > > > > > I would write something similar in the documentation, >> > >>> > and >> > >>> > I also >> > >>> > > > > > suggest >> > >>> > > > > > > > > you consider these for your own situation as well: >> > >>> > > > > > > > > - rDNS is not trustworthy for security decisions. >> > >>> > Attackers with >> > >>> > > > > > control >> > >>> > > > > > > > > over PTR (or via poisoning/misconfig) can return >> > >>> > arbitrary >> > >>> > > > names. >> > >>> > > > > > > > > MITRE tracks this as CWE-350 [1] (Reliance on Reverse >> > >>> > DNS for >> > >>> > > > > > > > Security). If >> > >>> > > > > > > > > you base TLS host checks on rDNS, it’s bypassable. >> > >>> > > > > > > > > - Slow or failing DNS causes blocking delays >> > >>> > (seconds) in JVM >> > >>> > > > > > lookups. >> > >>> > > > > > > > > OpenJDK issues document repeated timeouts and lack of >> > >>> > > > > > > > > effective caching paths for some rDNS calls. Putting >> > >>> > rDNS in >> > >>> > > > > > critical >> > >>> > > > > > > > paths >> > >>> > > > > > > > > (TLS, handshake, request handling) can amplify random >> > >>> > outages. >> > >>> > > > > > > > > >> > >>> > > > > > > > > All in all I'm not yet convinced that this issue >> > >>> > appears in >> > >>> > > > other >> > >>> > > > > > > > trending >> > >>> > > > > > > > > environments like k8s. >> > >>> > > > > > > > > Adding this together with the mentioned risks I >> > >>> > personally >> > >>> > > > wouldn't >> > >>> > > > > > > > merge >> > >>> > > > > > > > > it to the main repo. >> > >>> > > > > > > > > >> > >>> > > > > > > > > BR, >> > >>> > > > > > > > > G >> > >>> > > > > > > > > >> > >>> > > > > > > > > [1] https://cwe.mitre.org/data/definitions/350.html >> > >>> > > > > > > > > >> > >>> > > > > > > > > >> > >>> > > > > > > > > On Fri, Aug 15, 2025 at 7:44 PM Yaroslav Chernysh >> > >>> > > > <[email protected]> >> > >>> > > > > > > > > wrote: >> > >>> > > > > > > > > >> > >>> > > > > > > > > > Hi Gobor, >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Thank you for such a quick response, I appreciate >> > >>> > it. >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Actually, I'm not very good at all this security and >> > >>> > > > networking >> > >>> > > > > > > > stuff, so >> > >>> > > > > > > > > > I apologize in advance if I'm wrong in some >> > >>> > statement. >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > > Does YARN containers share the host’s network in >> > >>> > your >> > >>> > case? >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Yes, it does. And as far as I have researched, it >> > >>> > always does, >> > >>> > > > > > > > possibly >> > >>> > > > > > > > > > only unless you have configured YARN to use Docker >> > >>> > containers >> > >>> > > > > > > > > > >> > >>> > > > > > > > < >> > >>> > > > > > > > >> > >>> > > > > > >> > >>> > > > > > >> > >>> > > > >> > >>> > > > >> > >>> > https://hadoop.apache.org/docs/r3.4.1/hadoop-yarn/hadoop-yarn-site/DockerContainers.html >> > >>> > > > > > > > >, >> > >>> > > > > > > > > > which is definitely not my case. I have also done >> > >>> > some >> > >>> > > > testing on >> > >>> > > > > > > > my node, >> > >>> > > > > > > > > > which has 2 IP addresses: >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > - With default rest.bind-address (set by YARN to >> > >>> > Node >> > >>> > > > Manager's >> > >>> > > > > > > > hostname), >> > >>> > > > > > > > > > the only IP address that opens a port is the one >> > >>> > that NM >> > >>> > > > > > hostname is >> > >>> > > > > > > > > > resolved to. The other one (not sure where it comes >> > >>> > from, >> > >>> > > > this is >> > >>> > > > > > a >> > >>> > > > > > > > VM) >> > >>> > > > > > > > > > remains closed >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > - With rest.bind-address set to 0.0.0.0, the port is >> > >>> > open and >> > >>> > > > > > > > accessible >> > >>> > > > > > > > > > via both IP addresses >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > > However if you have a single IP then using >> > >>> > 0.0.0.0 and >> > >>> > > > > > binding it to >> > >>> > > > > > > > > > lo + eth0 is something what I wouldn't worry about. >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > I got the point and basically I agree here, but I'm >> > >>> > not >> > >>> > > > sure how >> > >>> > > > > > > > > > future-proof this approach is. How probable is a >> > >>> > scenario in >> > >>> > > > > > which the >> > >>> > > > > > > > > > environment (single IP node) is changed (to a >> > >>> > multi-homed >> > >>> > > > > > node), but >> > >>> > > > > > > > > > unchanged configuration (still listening on 0.0.0.0) >> > >>> > now leads >> > >>> > > > > > to an >> > >>> > > > > > > > > > excessive network exposure? Either way, that's not >> > >>> > my case. >> > >>> > > > And I >> > >>> > > > > > > > think >> > >>> > > > > > > > > > this is not restricted to YARN too: binding to all >> > >>> > > > interfaces in >> > >>> > > > > > > > Standalone >> > >>> > > > > > > > > > deployment might be too excessive as well. >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > > but you still have control on firewall, right? >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Probably yes (saying for an average user). This >> > >>> > would >> > >>> > probably >> > >>> > > > > > > > cover the >> > >>> > > > > > > > > > excessive binding leak, however only at the >> > >>> > firewall level >> > >>> > > > and not >> > >>> > > > > > > > at the >> > >>> > > > > > > > > > "core". This adds a dependency on firewall. I'm not >> > >>> > saying >> > >>> > > > it's >> > >>> > > > > > > > bad, but >> > >>> > > > > > > > > > rather that using the defense-in-depth approach and >> > >>> > doing both >> > >>> > > > > > limited >> > >>> > > > > > > > > > binding and adding firewall would be even better >> > >>> > than >> > >>> > > > relying on >> > >>> > > > > > > > firewall >> > >>> > > > > > > > > > only. >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > I hope all the above proves the point that even >> > >>> > with good >> > >>> > > > enough >> > >>> > > > > > > > > > environment (number of IP address + firewall) it >> > >>> > still does >> > >>> > > > make >> > >>> > > > > > > > sense to >> > >>> > > > > > > > > > restrict the binding. At least that's how I see >> > >>> > this, >> > >>> > please >> > >>> > > > > > > > correct me if >> > >>> > > > > > > > > > I'm wrong. >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > > introduce reverse DNS lookup as a must have >> > >>> > feature >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Could we make it optional and disabled by default? >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Thanks, >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > Yaroslav >> > >>> > > > > > > > > > >> > >>> > > > > > > > > > On 2025/08/14 21:32:40 Gabor Somogyi wrote: >> > >>> > > > > > > > > > > Hi Yaroslav, >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > First of all I would like to understand why you >> > >>> > think >> > >>> > > > binding to >> > >>> > > > > > > > 0.0.0.0 >> > >>> > > > > > > > > > is >> > >>> > > > > > > > > > > less secure in your case. Correct me if I'm wrong: >> > >>> > > > > > > > > > > Does YARN containers share the host’s network in >> > >>> > your >> > >>> > > > case? On a >> > >>> > > > > > > > > > > multi-homed node, 0.0.0.0 exposes on every host >> > >>> > interface, >> > >>> > > > > > > > > > > which can be less secure than binding to a >> > >>> > specific host >> > >>> > > > IP. So >> > >>> > > > > > > > this case >> > >>> > > > > > > > > > > pinning can matter. >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > However if you have a single IP then using >> > >>> > 0.0.0.0 and >> > >>> > > > binding >> > >>> > > > > > it >> > >>> > > > > > > > to lo + >> > >>> > > > > > > > > > > eth0 is something what I wouldn't worry about. >> > >>> > > > > > > > > > > Like a "normal" kubernetes pod (default >> > >>> > networking, >> > >>> > single >> > >>> > > > > > > > interface, no >> > >>> > > > > > > > > > > hostNetwork) has no such issue. >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > As a general remark. Let's say you expose the REST >> > >>> > endpoint >> > >>> > > > > > on 2 IP >> > >>> > > > > > > > > > > addresses but you still have control on firewall, >> > >>> > right? >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > The main reason why I'm asking these questions is >> > >>> > because >> > >>> > > > using >> > >>> > > > > > > > > > > `getHostName` would introduce reverse DNS lookup >> > >>> > as a >> > >>> > > > must have >> > >>> > > > > > > > feature. >> > >>> > > > > > > > > > > That could cause quite some turbulences at heavy >> > >>> > users by >> > >>> > > > > > additional >> > >>> > > > > > > > > > > traffic, PTR records can be wrong or spoofed, >> > >>> > etc... >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > BR, >> > >>> > > > > > > > > > > G >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > On Thu, Aug 14, 2025 at 8:13 PM Yaroslav Chernysh >> > >>> > > > > > <[email protected]> >> > >>> > > > > > > > > > <[email protected]> >> > >>> > > > > > > > > > > wrote: >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > > > Hi Flink community, >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > Is there a particular reason to advertise Job >> > >>> > Manager's >> > >>> > > > REST >> > >>> > > > > > > > endpoint >> > >>> > > > > > > > > > > > address in a form of IP address instead of >> > >>> > hostname? More >> > >>> > > > > > > > precisely, >> > >>> > > > > > > > > > I'm >> > >>> > > > > > > > > > > > talking about this code block >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > >>> > > > > > > > < >> > >>> > > > > > > > >> > >>> > > > > > >> > >>> > > > > > >> > >>> > > > >> > >>> > > > >> > >>> > https://github.com/apache/flink/blob/release-2.0.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/RestServerEndpoint.java#L298-L304 >> > >>> > > > > > > > > >> > >>> > > > > > > > > > >> > >>> > > > > > > > < >> > >>> > > > > > > > >> > >>> > > > > > >> > >>> > > > > > >> > >>> > > > >> > >>> > > > >> > >>> > https://github.com/apache/flink/blob/release-2.0.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/RestServerEndpoint.java#L298-L304 >> > >>> > > > > > > > > >> > >>> > > > > > > > > > in >> > >>> > > > > > > > > > > > RestServerEndpoint.java: >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > final InetSocketAddress bindAddress = >> > >>> > (InetSocketAddress) >> > >>> > > > > > > > > > > > serverChannel.localAddress(); >> > >>> > > > > > > > > > > > final String advertisedAddress; >> > >>> > > > > > > > > > > > if >> > >>> > (bindAddress.getAddress().isAnyLocalAddress()) { >> > >>> > > > > > > > > > > > advertisedAddress = this.restAddress; >> > >>> > > > > > > > > > > > } else { >> > >>> > > > > > > > > > > > advertisedAddress = >> > >>> > > > > > > > > > > > bindAddress.getAddress().getHostAddress(); >> > >>> > > > > > > > > > > > } >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > That is (as far as I understood), if >> > >>> > rest.bind-address >> > >>> > > > is set >> > >>> > > > > > > > to the >> > >>> > > > > > > > > > > > 0.0.0.0 wildcard (which means binding to all >> > >>> > available >> > >>> > > > > > > > interfaces), >> > >>> > > > > > > > > > then >> > >>> > > > > > > > > > > > the advertised address will be the value of >> > >>> > rest.address. >> > >>> > > > > > > > Otherwise, an >> > >>> > > > > > > > > > > > address in a form of IP address of the specified >> > >>> > > > > > rest.bind-address >> > >>> > > > > > > > > > will be >> > >>> > > > > > > > > > > > used. >> > >>> > > > > > > > > > > > What if I want to bind the REST endpoint to some >> > >>> > specific >> > >>> > > > > > > > address (for >> > >>> > > > > > > > > > > > security reasons), but at the same time >> > >>> > advertise it in >> > >>> > > > the >> > >>> > > > > > form >> > >>> > > > > > > > of >> > >>> > > > > > > > > > > > hostname? Assuming that all the name resolution >> > >>> > things >> > >>> > > > work >> > >>> > > > > > > > correctly. >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > For me particularly, the problem this creates >> > >>> > is with >> > >>> > > > SSL. The >> > >>> > > > > > > > > > certificate >> > >>> > > > > > > > > > > > I have for the Job Manager (REST connectivity) >> > >>> > is >> > >>> > created >> > >>> > > > > > with a >> > >>> > > > > > > > > > hostname >> > >>> > > > > > > > > > > > and not an IP address. I run Flink on YARN and >> > >>> > this way >> > >>> > > > the >> > >>> > > > > > > > default >> > >>> > > > > > > > > > value >> > >>> > > > > > > > > > > > for rest.bind-address is Node Manager's >> > >>> > hostname (thus, >> > >>> > > > not >> > >>> > > > > > the >> > >>> > > > > > > > 0.0.0.0 >> > >>> > > > > > > > > > > > wildcard), and the same goes for rest.address. >> > >>> > This >> > >>> > > > way, the >> > >>> > > > > > > > advertised >> > >>> > > > > > > > > > > > address is in the form of an IP address. I'd >> > >>> > like to >> > >>> > > > access >> > >>> > > > > > > > Flink's UI >> > >>> > > > > > > > > > via >> > >>> > > > > > > > > > > > the YARN Resource Manager proxy ("Tracking URL" >> > >>> > in the >> > >>> > > > > > application >> > >>> > > > > > > > > > page) >> > >>> > > > > > > > > > > > that has the Job Manager's certificate in its >> > >>> > truststore. >> > >>> > > > > > > > However, due >> > >>> > > > > > > > > > to >> > >>> > > > > > > > > > > > the Flink being advertised to Resource Manager >> > >>> > with >> > >>> > the IP >> > >>> > > > > > > > address and >> > >>> > > > > > > > > > the >> > >>> > > > > > > > > > > > certificate holds the hostname, the connection >> > >>> > from >> > >>> > > > Resource >> > >>> > > > > > > > Manager >> > >>> > > > > > > > > > to Job >> > >>> > > > > > > > > > > > Manager fails with: >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > javax.net.ssl.SSLPeerUnverifiedException: >> > >>> > Certificate for >> > >>> > > > > > > > > > <192.168.33.11> >> > >>> > > > > > > > > > > > doesn't match any of the subject alternative >> > >>> > names: [] >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > The only way I can fix this (without code >> > >>> > changes) >> > >>> > is by >> > >>> > > > > > > > explicitly >> > >>> > > > > > > > > > > > setting rest.bind-address to 0.0.0.0, which is >> > >>> > not >> > >>> > > > secure, as >> > >>> > > > > > > > far as I >> > >>> > > > > > > > > > > > understand (less secure than binding to a >> > >>> > specific >> > >>> > > > address). >> > >>> > > > > > > > > > > > However, if I substitute the getHostAddress() >> > >>> > call in >> > >>> > > > the code >> > >>> > > > > > > > block >> > >>> > > > > > > > > > above >> > >>> > > > > > > > > > > > with the getHostName(), the issue is gone. >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > So, my question is: is there any particular >> > >>> > reason >> > >>> > not to >> > >>> > > > > > > > > > > > use getHostName() here (assuming hostname is >> > >>> > available)? >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > > Thanks, >> > >>> > > > > > > > > > > > Yaroslav >> > >>> > > > > > > > > > > > >> > >>> > > > > > > > > > > >> > >>> > > > > > > > > > >> > >>> > > > > > > > > >> > >>> > > > > > > > >> > >>> > > > > > > >> > >>> > > > > > >> > >>> > > > > >> > >>> > > > >> > >>> > > >> > >>> >
