java.lang.RuntimeException: Selected H2O.CLOUD_MULTICAST_IF: name:lo (lo) doesn't support multicast

JIRA | Kevin Normoyle | 2 years ago
  1. 0

    The MultiReceiverThread.java retries on multicast error. I modified it to runtime exception on SocketException so we can get a stack trace. I think that prevents a retry. If we want retry in that case, need to improve the code But this jira is about the question of picking network interfaces for the multicast interface, and then h2o finding out the interface doesn't support multicast. for instance, this email below shows that "lo" can be picked, and sometimes (always?) "lo" doesn't support multicast? (at least Ubuntu 15 mattd machine hit the problem) I think maybe it will only pick "lo" if there is no live network connection (no wired or wireless) Probably should cleanly disable multicast, if the multicast interface doesn't support it. And do what? Maybe suggest using flattfile if a multi-node cloud was the goal? Probably ...because sometimes the wrong interface is picked...and using flatfile (and maybe specifying IP) works if multicast doesn't. User might disable multicast on an interface for some reason. Don't know if there could be a hw reason too in some cases? But probably 'lo' is the only interesting case, if no network. from email ---------------------------------------------------------------------- somehow the question must have been resolved for multi-jvm R unit testing on a machine (the gradlew build) because if h2o.init() in R, ever picks 'lo' for the interface, and the interface doesn't support multicast, and you don't use a flatfile to specify ip:port, then you're multi-jvm cloud won't build. but then again, whenever someone does a build, I suspect they are always connected to a network, so 'lo' won't be picked for the interface. curious if the gradle build works if a laptop is not connected to any network. someone may have done something so it does I changed my runtime exception on supportsMulticast() to just a Log.info() so it didn't impeded mattd. yeah I should file a jira around the questions. On 05/06/2015 03:01 PM, Raymond Peck wrote: > Those are great questions. JIRA ticket, please! > > :-) > > On Tue, May 5, 2015 at 7:15 PM, Kevin <kevin@0xdata.com> wrote: > > I'm wondering if we need some special handling for the case where there is no network interface, only lo > > we probably let lo be multicast today, and rely on the try/catch to avoid issues if the interface can't be multicast. > > but shouldn't we just not try to do multicast, if the selected interface is either not up, or can't support multicast? > > not clear what the strategy for the multicast is, when there's no suitable interfaces (like if you're not connected to a network) > > > -kevin > > > > On 05/05/2015 07:12 PM, Kevin wrote: >> I just added code to check that the interface selected by h2o (I didn't change the selection algorithm) thinks it can support multicast >> I was surprised to see that Matt hit it, for some reason >> >> does "lo" not support multicast? >> >> I was going to put in a check on the interface picked, to not allow "lo" because that can't be a multicast interface? or can it >> >> Was h2o always picking "lo" sometimes? does it not matter if single node? >> >> I added this code to H2ONode.java >> >> which you would think should be a valid check, if we're going to make H2O.CLOUD_MULTICAST_IF a multicast if in MultiReceiverThread.java >> in >> /home/kevin/h2o-dev/h2o-core/src/main/java/water >> >> H2ONode.java: >> >> try { >> if( !H2O.CLOUD_MULTICAST_IF.supportsMulticast() ) { >> throw new RuntimeException("Selected H2O.CLOUD_MULTICAST_IF: "+H2O.CLOUD_MULTICAST_IF+ " doesn't support multicast"); >> } >> if( !H2O.CLOUD_MULTICAST_IF.isUp() ) { >> throw new RuntimeException("Selected H2O.CLOUD_MULTICAST_IF: "+H2O.CLOUD_MULTICAST_IF+ " is not up and running"); >> } >> } catch( SocketException e ) { >> throw Log.throwErr(e); >> } >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: Your MTU fix works great! >> Date: Tue, 5 May 2015 18:58:24 -0700 >> From: Matt Dowle <mattd@0xdata.com> >> To: Kevin Normoyle <kevin@0xdata.com> >> >> >> This may not be related but when I load the H2O package and run h2o.init() I get the following : >> >> Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar >> Exception in thread "main" java.lang.RuntimeException: Selected H2O.CLOUD_MULTICAST_IF: name:lo (lo) doesn't support multicast >> at water.H2ONode.self(H2ONode.java:174) >> at water.init.NetworkInit.initializeNetworkSockets(NetworkInit.java:359) >> at water.H2O.startLocalNode(H2O.java:856) >> at water.H2O.main(H2O.java:1195) >> at water.H2OApp.driver(H2OApp.java:26) >> at water.H2OApp.main(H2OApp.java:21) >> >> Did that /etc/network/interfaces change affect multicast by any chance? >> >> Thanks, Matt >> >> >> On Tue, May 5, 2015 at 6:26 PM, Matt Dowle <mattd@0xdata.com> wrote: >> >> >> Works great now. The subsequent python problem was unrelated and Ray fixed it. >> >> It indeed takes 7 mins for "./gradlew build" from clean and completes OK. The same time as the same laptop when running MacOS. >> >> Yay! >> >> Thanks, Matt

    JIRA | 2 years ago | Kevin Normoyle
    java.lang.RuntimeException: Selected H2O.CLOUD_MULTICAST_IF: name:lo (lo) doesn't support multicast
  2. 0

    The MultiReceiverThread.java retries on multicast error. I modified it to runtime exception on SocketException so we can get a stack trace. I think that prevents a retry. If we want retry in that case, need to improve the code But this jira is about the question of picking network interfaces for the multicast interface, and then h2o finding out the interface doesn't support multicast. for instance, this email below shows that "lo" can be picked, and sometimes (always?) "lo" doesn't support multicast? (at least Ubuntu 15 mattd machine hit the problem) I think maybe it will only pick "lo" if there is no live network connection (no wired or wireless) Probably should cleanly disable multicast, if the multicast interface doesn't support it. And do what? Maybe suggest using flattfile if a multi-node cloud was the goal? Probably ...because sometimes the wrong interface is picked...and using flatfile (and maybe specifying IP) works if multicast doesn't. User might disable multicast on an interface for some reason. Don't know if there could be a hw reason too in some cases? But probably 'lo' is the only interesting case, if no network. from email ---------------------------------------------------------------------- somehow the question must have been resolved for multi-jvm R unit testing on a machine (the gradlew build) because if h2o.init() in R, ever picks 'lo' for the interface, and the interface doesn't support multicast, and you don't use a flatfile to specify ip:port, then you're multi-jvm cloud won't build. but then again, whenever someone does a build, I suspect they are always connected to a network, so 'lo' won't be picked for the interface. curious if the gradle build works if a laptop is not connected to any network. someone may have done something so it does I changed my runtime exception on supportsMulticast() to just a Log.info() so it didn't impeded mattd. yeah I should file a jira around the questions. On 05/06/2015 03:01 PM, Raymond Peck wrote: > Those are great questions. JIRA ticket, please! > > :-) > > On Tue, May 5, 2015 at 7:15 PM, Kevin <kevin@0xdata.com> wrote: > > I'm wondering if we need some special handling for the case where there is no network interface, only lo > > we probably let lo be multicast today, and rely on the try/catch to avoid issues if the interface can't be multicast. > > but shouldn't we just not try to do multicast, if the selected interface is either not up, or can't support multicast? > > not clear what the strategy for the multicast is, when there's no suitable interfaces (like if you're not connected to a network) > > > -kevin > > > > On 05/05/2015 07:12 PM, Kevin wrote: >> I just added code to check that the interface selected by h2o (I didn't change the selection algorithm) thinks it can support multicast >> I was surprised to see that Matt hit it, for some reason >> >> does "lo" not support multicast? >> >> I was going to put in a check on the interface picked, to not allow "lo" because that can't be a multicast interface? or can it >> >> Was h2o always picking "lo" sometimes? does it not matter if single node? >> >> I added this code to H2ONode.java >> >> which you would think should be a valid check, if we're going to make H2O.CLOUD_MULTICAST_IF a multicast if in MultiReceiverThread.java >> in >> /home/kevin/h2o-dev/h2o-core/src/main/java/water >> >> H2ONode.java: >> >> try { >> if( !H2O.CLOUD_MULTICAST_IF.supportsMulticast() ) { >> throw new RuntimeException("Selected H2O.CLOUD_MULTICAST_IF: "+H2O.CLOUD_MULTICAST_IF+ " doesn't support multicast"); >> } >> if( !H2O.CLOUD_MULTICAST_IF.isUp() ) { >> throw new RuntimeException("Selected H2O.CLOUD_MULTICAST_IF: "+H2O.CLOUD_MULTICAST_IF+ " is not up and running"); >> } >> } catch( SocketException e ) { >> throw Log.throwErr(e); >> } >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: Your MTU fix works great! >> Date: Tue, 5 May 2015 18:58:24 -0700 >> From: Matt Dowle <mattd@0xdata.com> >> To: Kevin Normoyle <kevin@0xdata.com> >> >> >> This may not be related but when I load the H2O package and run h2o.init() I get the following : >> >> Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar >> Exception in thread "main" java.lang.RuntimeException: Selected H2O.CLOUD_MULTICAST_IF: name:lo (lo) doesn't support multicast >> at water.H2ONode.self(H2ONode.java:174) >> at water.init.NetworkInit.initializeNetworkSockets(NetworkInit.java:359) >> at water.H2O.startLocalNode(H2O.java:856) >> at water.H2O.main(H2O.java:1195) >> at water.H2OApp.driver(H2OApp.java:26) >> at water.H2OApp.main(H2OApp.java:21) >> >> Did that /etc/network/interfaces change affect multicast by any chance? >> >> Thanks, Matt >> >> >> On Tue, May 5, 2015 at 6:26 PM, Matt Dowle <mattd@0xdata.com> wrote: >> >> >> Works great now. The subsequent python problem was unrelated and Ray fixed it. >> >> It indeed takes 7 mins for "./gradlew build" from clean and completes OK. The same time as the same laptop when running MacOS. >> >> Yay! >> >> Thanks, Matt

    JIRA | 2 years ago | Kevin Normoyle
    java.lang.RuntimeException: Selected H2O.CLOUD_MULTICAST_IF: name:lo (lo) doesn't support multicast
  3. 0

    Chunked http view query response

    GitHub | 2 years ago | vmarc
    gnieh.sohva.SohvaException: Query failed for view `testview' in design `design' at http://localhost:5984/testdb
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    python freeline.py -f报错

    GitHub | 2 months ago | pgsheng
    org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':Gmcchh'.
  6. 0

    [DRILL-2602] Throw an error on schema change during streaming aggregation - ASF JIRA

    apache.org | 1 year ago
    java.lang.RuntimeException: java.sql.SQLException: UNSUPPORTED_OPERATION ERROR: Sort doesn't currently support sorts with changing schemas Fragment 0:0 [Error Id: 86b2b995-0143-4941-a550-5f60ddb0862d on atsqa4-133.qa.lab:31010]

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.RuntimeException

      Selected H2O.CLOUD_MULTICAST_IF: name:lo (lo) doesn't support multicast

      at water.H2ONode.self()
    2. water
      H2ONode.self
      1. water.H2ONode.self(H2ONode.java:174)
      1 frame
    3. water.init
      NetworkInit.initializeNetworkSockets
      1. water.init.NetworkInit.initializeNetworkSockets(NetworkInit.java:359)
      1 frame
    4. water
      H2OApp.main
      1. water.H2O.startLocalNode(H2O.java:856)
      2. water.H2O.main(H2O.java:1195)
      3. water.H2OApp.driver(H2OApp.java:26)
      4. water.H2OApp.main(H2OApp.java:21)
      4 frames