[JBoss JIRA] (MODCLUSTER-495) mod_cluster UDP multicast listener does not honour the proper interface
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-495?page=com.atlassian.jira.pl... ]
Michal Karm Babacek commented on MODCLUSTER-495:
------------------------------------------------
Routing is correct - enp1s0 is the default interface, having a gateway outside the network, enp2s0 lives only within 172.17.64.1 - 172.17.95.254 (without routing outside the network). With all instances bound to enp2s0, communicating within 172.17.64.1 - 172.17.95.254 network, it should work.
IMHO it's again The Return of The Infamous InetSocket...
> 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)
7 years, 11 months
[JBoss JIRA] (MODCLUSTER-495) mod_cluster UDP multicast listener does not honour the proper interface
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-495?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-495:
-------------------------------------------
{quote}If you don't specify a concrete interface, then the kernel will choose it based on its routing tables when datagrams are to be sent.{quote}
This looks like misconfigured routing table. Can you verify that?
> 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)
7 years, 11 months
[JBoss JIRA] (MODCLUSTER-495) mod_cluster UDP multicast listener does not honour the proper interface
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-495?page=com.atlassian.jira.pl... ]
Michal Karm Babacek moved JWS-408 to MODCLUSTER-495:
----------------------------------------------------
Project: mod_cluster (was: JBoss Web Server)
Key: MODCLUSTER-495 (was: JWS-408)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Core & Container Integration (Java)
(was: mod_cluster)
(was: tomcat7)
(was: tomcat8)
Target Release: (was: JWS 3.0.4 GA)
Affects Version/s: 1.3.1.Final
(was: JWS 3.0.3 GA)
(was: JWS 3.0.3 CR1)
> 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)
7 years, 11 months