Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-11195

DR19 Cluster behaves differently when trying to use already used IP/port for "jgroups-udp" socket-binding

    XMLWordPrintable

Details

    • Clarification
    • Resolution: Done
    • Major
    • 7.1.0.DR19
    • 7.1.0.DR19
    • Clustering
    • None

    Description

      There are some tests which start a cluster of two EAP servers, using standalone-full-ha.xml profile. Rather than using a port offset, EAP servers are started in this way:

      node1
      sh bin/standalone.sh -Djboss.bind.address=$IP -Djboss.bind.address.unsecure=$IP -Djboss.bind.address.management=$IP -Djboss.messaging.cluster.password=password -Djboss.node.name=node1 -c standalone-full-ha.xml
      node2
      sh bin/standalone.sh -Djboss.messaging.cluster.password=password -Djboss.node.name=node2 -c standalone-full-ha.xml

      The node, which is started second logs this error while being started in DR19 (it did not log this error in DR18):

      15:32:14,103 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel.ee: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel.ee: java.lang.Exception: failed to open a port in range 55200-55200
        at org.jboss.as.clustering.jgroups.subsystem.ChannelBuilder.start(ChannelBuilder.java:127)
        at org.wildfly.clustering.service.AsynchronousServiceBuilder.lambda$start$0(AsynchronousServiceBuilder.java:99)
        at org.wildfly.clustering.service.AsynchronousServiceBuilder$$Lambda$695/1973869844.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
        at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.Exception: failed to open a port in range 55200-55200
        at org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
        at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
        at org.jgroups.protocols.UDP.start(UDP.java:266)
        at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
        at org.jgroups.JChannel.startStack(JChannel.java:889)
        at org.jgroups.JChannel._preConnect(JChannel.java:553)
        at org.jgroups.JChannel.connect(JChannel.java:288)
        at org.jgroups.JChannel.connect(JChannel.java:279)
        at org.jboss.as.clustering.jgroups.subsystem.ChannelBuilder.start(ChannelBuilder.java:125)
        ... 6 more

      It is obvious from the error message and from the startup command, that the IP address for "private" interface is not being set when starting node1, i.e. there should be also this parameter:

      -Djboss.bind.address.private=$IP

      In that case, both servers bind to 127.0.0.1 and try to use 55200 port. Second server then logs the error as expected.

      The question is: why this did not happen with previous DR builds?

      Attachments

        Issue Links

          is related to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-10587 JGroups transport port_range should default to 0

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Activity

            People

              pferraro@redhat.com Paul Ferraro
              mvinkler1@redhat.com Michal Vinkler
              Michal Vinkler Michal Vinkler
              Michal Vinkler Michal Vinkler
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: