August 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-463) UpperCase Alias never matches any context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-463?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-463: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1340957|https://bugzilla.redhat.com/show_bug.cgi?id=1340957] from MODIFIED to VERIFIED > UpperCase Alias never matches any context > ----------------------------------------- > > Key: MODCLUSTER-463 > URL: https://issues.jboss.org/browse/MODCLUSTER-463 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.11.Final, 1.3.1.Final > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final, 1.2.13.Final > > Attachments: simplecontext-examples.zip > > > h3. Problem > h4. JBossWeb > Regardless the upper/lower case of an Alias one configured in _JBossWeb (EAP 6.4.3, mod_cluster subsystem 1.2.11.Final)_, it has always been reported to Apache HTTP Server in lower case. For example, the following configuration:{code:xml} > <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="workerXXX" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > <virtual-server name="web1" default-web-module="simplecontext-web1"> > <alias name="web1.rhel7GAx86-64"/> > </virtual-server> > <virtual-server name="web2" default-web-module="simplecontext-web2"> > <alias name="web2.rhel7GAx86-64"/> > </virtual-server> > </subsystem> > {code}sends this message with aliases actually being reported in lower case: {{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7gax86-64&Context=%2F}}. Having {{aliases}} stored in lower case on the Apache HTTP Server side enables both these URLs to work perfectly:{noformat}curl http://web2.rhel7GAx86-64:6666/ > curl http://web2.rhel7gax86-64:6666/{noformat}. The balancer configuration is just a simple [UseAlias 1|http://fpaste.org/251417/86985831/]. > h4. Undertow > _Undertow (JBossWeb's successor in EAP 7.0.0.DR7, mod_cluster subsystem 1.3.1.Final)_ behaves differently; it reports verbatim what one sets as an alias, so with the following configuration:{code:xml}<subsystem xmlns="urn:jboss:domain:undertow:3.0" instance-id="workerXXX"> > <buffer-cache name="default"/> > <server name="default-server"> > <ajp-listener name="ajp" socket-binding="ajp"/> > <http-listener name="default" redirect-socket="https" socket-binding="http"/> > <host name="default-host" alias="localhost"> > <location name="/" handler="welcome-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web1" alias="web1.rhel7GAx86-64"> > <location name="/" handler="web1-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web2" alias="web2.rhel7GAx86-64"> > <location name="/" handler="web2-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > <websockets/> > </servlet-container> > <handlers> > <file name="web1-content" path="${jboss.home.dir}/simplecontext-web1"/> > <file name="web2-content" path="${jboss.home.dir}/simplecontext-web2"/> > <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> > </handlers> > <filters> > <response-header name="server-header" header-value="WildFly/10" header-name="Server"/> > <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/> > </filters> > </subsystem>{code}, the message reported to Apache HTTP Server actually is:{{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7GAx86-64&Context=%2F}}. Due to the fact that aliases are being compared byte-by-byte for equality (because pumping of slash characters takes place) and the accessed domain is always in lower case and alias is stored as it was received, there is never match between these. > The result is that while these work:{{http://web2:6666/}}, {{http://web1:6666/}}, one of the upper case containing ones work at all: {{http://web1.rhel7GAx86-64:6666}} and {{http://web2.rhel7gax86-64:6666/}} neither. By not working I actually mean they return the root of Apache HTTP Server Welcome page instead of correctly forwarding to one of the Application server's virtual host contexts. > Last but not least, while EAP 6.4.3 with JBossWeb itself treats aliases as case-insensitive, EAP 7.0.0.DR7 with Undertow does not; i.e. {{web1.rhel7GAx86-64:8080/}} returns correctly web application content whereas {{web1.rhel7gax86-64:8080/}} returns EAP7 Welcome page. > While the aforementioned is clearly a bug (or a weird feature :)) in Undertow, we must make the Apache HTTP Server code resilient to such behaviour. > h3. Solution > I suggest converting aliases to lower case in mod_manager on ENABLE-APP arrival. According to my preliminary tests, this approach works for both JBossWeb and Undertow equipped workers. I think it's cool to do that: [RFC 1035|https://tools.ietf.org/html/rfc1035#section-2.3.3]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1338664|https://bugzilla.redhat.com/show_bug.cgi?id=1338664] from MODIFIED to VERIFIED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final, 1.3.4.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-397) StickySessions don't work for ProxyPass from unenabled context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-397?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-397: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1085427|https://bugzilla.redhat.com/show_bug.cgi?id=1085427] from ON_QA to VERIFIED > StickySessions don't work for ProxyPass from unenabled context > -------------------------------------------------------------- > > Key: MODCLUSTER-397 > URL: https://issues.jboss.org/browse/MODCLUSTER-397 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final, 2.0.0.Alpha1, 1.2.13.Final > > > Sticky sessions are not maintained if you try to ProxyPass from an unenabled context to an enabled one. For example, consider JBoss with just /foo deployed and enabled via MCMP. Then try to ProxyPass / to /foo/ on httpd: > CreateBalancers 1 > ... > ProxyPass / balancer://mycluster/foo/ stickysession=JSESSIONID|jsessionid nofailover=On -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Eliminate automagic

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Summary: Eliminate automagic (was: Consider eliminating automagic) > Eliminate automagic > ------------------- > > Key: MODCLUSTER-531 > URL: https://issues.jboss.org/browse/MODCLUSTER-531 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > I am proposing we abandon automagic as much as possible. > h1. Problem > The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: > # insecure (listening on all interfaces, allow from all, default security key "changeme!") > # difficult to debug (not clear what is the actual configuration) > # unstable installations (seemingly unrelated aspects like adding an interface or connector break the config) > h1. Areas > There are several areas where automagic happens. > h5. Advertised address of the proxy > There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. > h5. Advertise interfaces > The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly. > h5. Connector address > If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface. > h5. Connector selection > This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-533) Conform route (jvmRoute) to mod_jk standards; cannot contain periods

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-533: ----------------------------------------- Summary: Conform route (jvmRoute) to mod_jk standards; cannot contain periods Key: MODCLUSTER-533 URL: https://issues.jboss.org/browse/MODCLUSTER-533 Project: mod_cluster Issue Type: Feature Request Components: Core & Container Integration (Java), Documentation & Demos Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-533) Conform route (jvmRoute) to mod_jk standards; cannot contain periods

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-533?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-533: -------------------------------------- Description: This is in preparation supporting multiple route. > Conform route (jvmRoute) to mod_jk standards; cannot contain periods > -------------------------------------------------------------------- > > Key: MODCLUSTER-533 > URL: https://issues.jboss.org/browse/MODCLUSTER-533 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java), Documentation & Demos > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > This is in preparation supporting multiple route. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-533) Conform route (jvmRoute) to mod_jk standards; cannot contain periods

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-533?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-533: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 > Conform route (jvmRoute) to mod_jk standards; cannot contain periods > -------------------------------------------------------------------- > > Key: MODCLUSTER-533 > URL: https://issues.jboss.org/browse/MODCLUSTER-533 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java), Documentation & Demos > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > This is in preparation supporting multiple route. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-528) Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-528?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-528: ------------------------------------------- > The conclusion doesn't make any sense to me - which systems? Which tomcats? For instance Fedora 24 build system (i.e. ecosystem). > Why would we bring Tomcat 7 dependencies to Tomcat 8 game? See below. > I should need only Tomcat 8 dependencies without patching *.java files That's a terrible approach. Building for RPM or whatever other system needs to follow what maven is doing -- that's the build that is used and tested. introducing new code in e.g. RPM building is a quiality risk. > drop Tomcat 6 from 1.3.x branch and from master, it is not needed there > drop JBossWeb/AS7 from 1.3.x branch and from master, it is not needed there Long time dropped from master. > move Catalina stuff around so as -PTC7 needs Tomcat 7 dependencies, -PTC8 needs Tomcat 8 dependencies, -PTC85 needs Tomcat 8.5 dependencies etc. This is setup in pre-master, never used and never worked. This is dropped in master (commented out). Doing this means unnecessary code duplication. The base module could then only contain code that can be compiled with *every* Tomcat version we support. The approach that we have been shipping for years is to compile base against single version and override code that needs to be changed for newer tomcat version. > Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-528 > URL: https://issues.jboss.org/browse/MODCLUSTER-528 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.3.3.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > It is not possible (or I'm doing something wrong) to build mod_cluster Tomcat libs with Tomcat 8-only API. > I hit this problem with RPM build on Fedora where I cannot download random stuff from maven central and I need to specify dependencies beforehand. > h3. Description > * container/catalina contains calls to API that is deprecated in Tomcat 7 and missing in Tomcat 8, so I have to apply this patch: [MODCLUSTER-528-CatalinaContext.java.patch|https://github.com/Karm/mod_clu...] before build > * profiles and test dependencies and Servlet API dependencies needs hacks to build without Tomcat 7 too: see other patches in [mod_cluster-fedora-packages/|https://github.com/Karm/mod_cluster-fedora-p...] > h3. Suggestion > * architecture dependencies so as it is possible to build mod_cluster with Tomcat 8 API only (and Tomcat 7 API only) > * drop Tomcat 6 and JBossWeb from 1.3.x as they are not used in 1.3.x anyway (last use of Tomcat 6 and JBossWeb is 1.2.x) > h3. Fedora 24 offers only Tomcat 8 > ...so does it even make sense to offer users Tomcat 7 libs RPM? At the moment, I have it disabled. Note: Former mod_cluster RPM (1.2.6) hasn't been distributing any usable tomcat integration; it has been AS7/JBossWeb one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-528) Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-528?page=com.atlassian.jira.pl... ] Michal Karm Babacek commented on MODCLUSTER-528: ------------------------------------------------ Ad {quote} We agreed on the call today that we don't want to keep introducing workarounds for different building systems. {quote} That the is the sole point of this Jira - to get rid of silly workarounds such as: * https://github.com/Karm/mod_cluster-fedora-packages/blob/master/MODCLUSTE... * https://github.com/Karm/mod_cluster-fedora-packages/blob/master/MODCLUSTE... * https://github.com/Karm/mod_cluster-fedora-packages/blob/master/MODCLUSTE... > Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-528 > URL: https://issues.jboss.org/browse/MODCLUSTER-528 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.3.3.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > It is not possible (or I'm doing something wrong) to build mod_cluster Tomcat libs with Tomcat 8-only API. > I hit this problem with RPM build on Fedora where I cannot download random stuff from maven central and I need to specify dependencies beforehand. > h3. Description > * container/catalina contains calls to API that is deprecated in Tomcat 7 and missing in Tomcat 8, so I have to apply this patch: [MODCLUSTER-528-CatalinaContext.java.patch|https://github.com/Karm/mod_clu...] before build > * profiles and test dependencies and Servlet API dependencies needs hacks to build without Tomcat 7 too: see other patches in [mod_cluster-fedora-packages/|https://github.com/Karm/mod_cluster-fedora-p...] > h3. Suggestion > * architecture dependencies so as it is possible to build mod_cluster with Tomcat 8 API only (and Tomcat 7 API only) > * drop Tomcat 6 and JBossWeb from 1.3.x as they are not used in 1.3.x anyway (last use of Tomcat 6 and JBossWeb is 1.2.x) > h3. Fedora 24 offers only Tomcat 8 > ...so does it even make sense to offer users Tomcat 7 libs RPM? At the moment, I have it disabled. Note: Former mod_cluster RPM (1.2.6) hasn't been distributing any usable tomcat integration; it has been AS7/JBossWeb one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-528) Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-528?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-528: ------------------------------------------------ drop Tomcat 6 from 1.3.x branch NO drop Tomcat 6 from master yes. drop JBossWeb/AS7 from 1.3.x branch NO drop JBossWeb/AS7 from master Yes, So you ask to build with a single tomcat, that makes more sense, not sure that is doable. > Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-528 > URL: https://issues.jboss.org/browse/MODCLUSTER-528 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.3.3.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > It is not possible (or I'm doing something wrong) to build mod_cluster Tomcat libs with Tomcat 8-only API. > I hit this problem with RPM build on Fedora where I cannot download random stuff from maven central and I need to specify dependencies beforehand. > h3. Description > * container/catalina contains calls to API that is deprecated in Tomcat 7 and missing in Tomcat 8, so I have to apply this patch: [MODCLUSTER-528-CatalinaContext.java.patch|https://github.com/Karm/mod_clu...] before build > * profiles and test dependencies and Servlet API dependencies needs hacks to build without Tomcat 7 too: see other patches in [mod_cluster-fedora-packages/|https://github.com/Karm/mod_cluster-fedora-p...] > h3. Suggestion > * architecture dependencies so as it is possible to build mod_cluster with Tomcat 8 API only (and Tomcat 7 API only) > * drop Tomcat 6 and JBossWeb from 1.3.x as they are not used in 1.3.x anyway (last use of Tomcat 6 and JBossWeb is 1.2.x) > h3. Fedora 24 offers only Tomcat 8 > ...so does it even make sense to offer users Tomcat 7 libs RPM? At the moment, I have it disabled. Note: Former mod_cluster RPM (1.2.6) hasn't been distributing any usable tomcat integration; it has been AS7/JBossWeb one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2016