[mod_cluster-issues] [JBoss JIRA] (MODCLUSTER-495) mod_cluster UDP multicast listener does not honour the proper interface

[Radoslav Husar (JIRA)]

     [ https://issues.jboss.org/browse/MODCLUSTER-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed MODCLUSTER-495.
-------------------------------------
    Resolution: Cannot Reproduce Bug


Tested, this works for me (tested on OS X).

{code:xml}
  <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="true" advertiseInterface="192.168.1.50"/>
{code}

Have you correctly specified advertiseInterface?



> mod_cluster UDP multicast listener does not honour the proper interface
> -----------------------------------------------------------------------
>
>                 Key: MODCLUSTER-495
>                 URL: https://issues.jboss.org/browse/MODCLUSTER-495
>             Project: mod_cluster
>          Issue Type: Bug
>          Components: Core & Container Integration (Java)
>    Affects Versions: 1.3.1.Final
>         Environment: Linux, multiple NICs
>            Reporter: Michal Karm Babacek
>            Assignee: Radoslav Husar
>
> h3. Wrong interface
> On a multi-interface systems, it is necessary to pick the right interface the balancer should send to
> and worker should receive from. Merely setting UDP multicast address and port is not enough.
>  * With Apache HTTP Server, this is achieved by {{AdvertiseBindAddress}} directive (though the default is wrong MODCLUSTER-487)
>  * With Undertow mod_cluster proxy in Wildfly, the {{interface}} could be set in socket bindings, e.g.: {code}<socket-binding name="modcluster-adv" port="7637" multicast-address="224.0.1.105" multicast-port="7637" interface="special-public"/>{code}
>  * In the case of Tomcat/JBossWeb, [historical mod_cluster 1.x|http://docs.jboss.org/mod_cluster/1.1.0/html_single/#d0e1113] documentation suggests that it is done "automatically": _interface on which mod_cluster's internal connection was established_.
> The statement from the historical documentation doesn't make much sense to me -- which internal connection?
> The actual result is that if you have 2 boxes, 2 interfaces each:
> h4. Balancer (Undertow or Apache HTTP Server)
> {{Box 1: enp1s0:10.16.88.186, enp2s0:172.17.71.254}}, all connectors including advertisement bound to {{enp2s0:172.17.71.254}}
> h4. Worker (Tomcat)
> {{Box 2: enp1s0:10.16.88.181, enp2s0:172.17.66.254}}, HTTP/AJP connectors bound to {{enp2s0:172.17.66.254}}
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="true"
>           loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
>           loadMetricCapacity="1" loadHistory="9" loadDecayFactor="2"
>           stickySession="true" stickySessionForce="false" stickySessionRemove="true"
>           excludedContexts="ROOT,manager,docs,examples,host-manager"
>           autoEnableContexts="true" advertiseGroupAddress="224.0.1.105" advertisePort="7637"
> <Connector address="172.17.66.254" port="8080" protocol="HTTP/1.1" 
>            connectionTimeout="20000" 
>            redirectPort="8443" />
> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="172.17.66.254"/>
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="172.17.66.254node">
> {code}
> The worker node *is unable to receive balancer's advertising*. The tomcat actually listens for advertisements on {{enp1s0:10.16.88.181}}, because if I rebind the balancer to {{enp1s0:10.16.88.186}}, the whole setup suddenly works. I also verified it with the Advertize.java utility.
> h3. Suggestion
> IMHO, we have to either make it configurable via listener's attribute or fetch the interface from one of the available connectors (sometimes AJP is not configured, sometimes HTTP(S) ain't -- but at least one is always present).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)