May 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-480) Tomcat 8 Context isDistributable implementation needs to consult the underlying context instead of the manager

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-480?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-480: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 > Tomcat 8 Context isDistributable implementation needs to consult the underlying context instead of the manager > -------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-480 > URL: https://issues.jboss.org/browse/MODCLUSTER-480 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.2.Final, 2.0.0.Alpha1 > > > https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/Manager.... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-479) Add support for Tomcat 9

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-479?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-479: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 > Add support for Tomcat 9 > ------------------------ > > Key: MODCLUSTER-479 > URL: https://issues.jboss.org/browse/MODCLUSTER-479 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > This won't be binary compatible with Tomcat 8 classes because there are some differences. > Comet support has bee removed, see https://github.com/apache/tomcat/commit/376a308dbb1742f9fc88e693fb8100c44... > Service.getContainer refactored https://github.com/apache/tomcat/commit/2d9d4519cea1879209848952832fe194a... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-479) Add support for Tomcat 9

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-479?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-479: -------------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/179 > Add support for Tomcat 9 > ------------------------ > > Key: MODCLUSTER-479 > URL: https://issues.jboss.org/browse/MODCLUSTER-479 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > This won't be binary compatible with Tomcat 8 classes because there are some differences. > Comet support has bee removed, see https://github.com/apache/tomcat/commit/376a308dbb1742f9fc88e693fb8100c44... > Service.getContainer refactored https://github.com/apache/tomcat/commit/2d9d4519cea1879209848952832fe194a... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-497) ModClusterConfig#setAdvertiseInterface(java.lang.String) should not have been deprecated as it's used by Tomcat modeller

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-497?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-497: -------------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/178 > ModClusterConfig#setAdvertiseInterface(java.lang.String) should not have been deprecated as it's used by Tomcat modeller > ------------------------------------------------------------------------------------------------------------------------ > > Key: MODCLUSTER-497 > URL: https://issues.jboss.org/browse/MODCLUSTER-497 > Project: mod_cluster > Issue Type: Bug > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 11 months

1
0
0 / 0

[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: ------------------------------------------- On related note, this has been deprecated in the code but should not have been as there is no alternative for Tomcat, see MODCLUSTER-497. > 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, 12 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-497) ModClusterConfig#setAdvertiseInterface(java.lang.String) should not have been deprecated as it's used by Tomcat modeller

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-497?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-497 started by Radoslav Husar. ------------------------------------------------- > ModClusterConfig#setAdvertiseInterface(java.lang.String) should not have been deprecated as it's used by Tomcat modeller > ------------------------------------------------------------------------------------------------------------------------ > > Key: MODCLUSTER-497 > URL: https://issues.jboss.org/browse/MODCLUSTER-497 > Project: mod_cluster > Issue Type: Bug > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-497) ModClusterConfig#setAdvertiseInterface(java.lang.String) should not have been deprecated as it's used by Tomcat modeller

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-497: ----------------------------------------- Summary: ModClusterConfig#setAdvertiseInterface(java.lang.String) should not have been deprecated as it's used by Tomcat modeller Key: MODCLUSTER-497 URL: https://issues.jboss.org/browse/MODCLUSTER-497 Project: mod_cluster Issue Type: Bug Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 12 months

1
0
0 / 0

[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 edited comment on MODCLUSTER-495 at 5/11/16 1:06 PM: -------------------------------------------------------------------- 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? was (Author: rhusar): 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)

7 years, 12 months

1
0
0 / 0

[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 resolved MODCLUSTER-495. --------------------------------------- Resolution: Rejected > 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, 12 months

1
0
0 / 0

[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 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)

7 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues May 2016