[jira] (FLINK-5669) flink-streaming-contrib DataStreamUtils.collect in local environment mode fails when offline

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847415#comment-15847415 ] 

ASF GitHub Bot commented on FLINK-5669:
---------------------------------------

Github user rick-cox commented on the issue:

    https://github.com/apache/flink/pull/3223
  
    Thanks for the detailed explanation. I confirmed that using the previous patch with a standalone cluster failed, then applied the suggested alternative approach and tested that works with both standalone and local (online and offline). (I don't have ready access to Yarn or Mesos clusters, but believe they should be fine since this version only affects LocalStreamEnvironments).


> flink-streaming-contrib DataStreamUtils.collect in local environment mode fails when offline
> --------------------------------------------------------------------------------------------
>
>                 Key: FLINK-5669
>                 URL: https://issues.apache.org/jira/browse/FLINK-5669
>             Project: Flink
>          Issue Type: Bug
>          Components: flink-contrib
>            Reporter: Rick Cox
>            Priority: Minor
>
> {{DataStreamUtils.collect()}} needs to obtain the local machine's IP so that the job can send the results back. In the case of local {{StreamEnvironments}}, it uses {{InetAddress.getLocalHost()}}, which attempts to resolve the local hostname using DNS.
> If DNS is not available (for example, when offline) or if DNS is available but cannot resolve the hostname (for example, if the hostname is an intranet name but the machine is not currently on that network), an {{UnknownHostException}} will be thrown (and wrapped in an {{IOException}}).
> If the resolved IP is not reachable for some reason, streaming results will fail.
> Since this case is for local execution only, it seems that using {{InetAddress.getLoopbackAddress()}} would work just as well, and avoid the assumptions made by {{getLocalHost()}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)