August 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-531) Stop advocating and remove auto-magic aspects from the project

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Description: I am proposing we abandon automagic as much as possible. 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 can break advertised address) Th was: I am proposing we abandon automagic as much as possible. 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 often backfires quite significantly resulting in: # insecure installations (listening on all interfaces, allow from all) # unstable installations (e.g. adding an interface) > Stop advocating and remove auto-magic aspects from the project > -------------------------------------------------------------- > > 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. > 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 can break advertised address) > Th -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Stop advocating and remove auto-magic aspects from the project

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Description: I am proposing we abandon automagic as much as possible. 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 often backfires quite significantly resulting in: # insecure installations (listening on all interfaces, allow from all) # unstable installations (e.g. adding an interface) > Stop advocating and remove auto-magic aspects from the project > -------------------------------------------------------------- > > 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. > 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 often backfires quite significantly resulting in: > # insecure installations (listening on all interfaces, allow from all) > # unstable installations (e.g. adding an interface) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Stop advocating and remove auto-magic aspects from the project

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-531: ----------------------------------------- Summary: Stop advocating and remove auto-magic aspects from the project 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: Jean-Frederic Clere -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Stop advocating and remove auto-magic aspects from the project

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar reassigned MODCLUSTER-531: ----------------------------------------- Assignee: Radoslav Husar (was: Jean-Frederic Clere) > Stop advocating and remove auto-magic aspects from the project > -------------------------------------------------------------- > > 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 > -- 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 1338641|https://bugzilla.redhat.com/show_bug.cgi?id=1338641] 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-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 1340958|https://bugzilla.redhat.com/show_bug.cgi?id=1340958] from ON_QA 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-458) Add JVMRoute or node identifier to httpd/mod_cluster errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-458: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1338644|https://bugzilla.redhat.com/show_bug.cgi?id=1338644] from ON_QA to VERIFIED > Add JVMRoute or node identifier to httpd/mod_cluster errors > ----------------------------------------------------------- > > Key: MODCLUSTER-458 > URL: https://issues.jboss.org/browse/MODCLUSTER-458 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Coty Sutherland > Assignee: Michal Karm Babacek > Fix For: 1.3.2.Final, 1.2.12.Final > > > Messages such as: > [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node > are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-466) mod_cluster undersizes the connection pool on httpd 2.2

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-466?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-466: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1338642|https://bugzilla.redhat.com/show_bug.cgi?id=1338642] from ON_QA to VERIFIED > mod_cluster undersizes the connection pool on httpd 2.2 > ------------------------------------------------------- > > Key: MODCLUSTER-466 > URL: https://issues.jboss.org/browse/MODCLUSTER-466 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.2.Final, 1.2.13.Final > > > If all threads in a httpd child worker process are saturated with long requests, then all connections in the pool are exhausted, likely leaving none available for additional pings, which then fail with errors like: > [error] (70007)The timeout specified has expired: proxy: ajp: failed to acquire connection for ... > Documentation suggests the connection pool will be sized to ThreadsPerChild+1 to avoid that, but it looks like it is really just ThreadsPerChild on httpd 2.2. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-492) mod_cluster should allow failover of GET requests by default

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-492?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-492: ------------------------------------------- The idea is that since GETs are supposed to be idempotent they can be failed over, i.e. retried, even after they started processing -- which we currently don't do nor support. > mod_cluster should allow failover of GET requests by default > ------------------------------------------------------------ > > Key: MODCLUSTER-492 > URL: https://issues.jboss.org/browse/MODCLUSTER-492 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java), Native (httpd modules) > Affects Versions: 1.3.2.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > For any well developed web application, all GET requests should be idempotent and safe for failing over to another node. This should be default behavior, with a configuration option to disable it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-452) mod_cluster with WildFly reports 0.0.0.0 to the balancer

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-452?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-452. ------------------------------------- Fix Version/s: (was: 1.3.4.Final) Resolution: Out of Date This is supposed to be fixed in WF with https://issues.jboss.org/browse/WFLY-5939. > mod_cluster with WildFly reports 0.0.0.0 to the balancer > -------------------------------------------------------- > > Key: MODCLUSTER-452 > URL: https://issues.jboss.org/browse/MODCLUSTER-452 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > While I was working on [issue 138|https://github.com/modcluster/mod_cluster/issues/138] (MODCLUSTER-448), it came to my attention that one can't force EAP 6.4 Beta (jbossweb, mod_cluster 1.2.11) to send anything like {{ajp://0.0.0.0:8009}} to the balancer. If one sets the application server to bind to 0.0.0.0, mod_cluster core correctly guesses 127.0.0.1 and sends {{ajp://127.0.0.1:8009}} to the balancer. > On the contrary, WildFly goes only half way: it reports 127.0.0.1 in the log: > {noformat} > [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000012: default-server connector will use /127.0.0.1 > {noformat} > and yet it sends 0.0.0.0 to the balancer: > {noformat} > Node localhost (ajp://0.0.0.0:8009): > {noformat} > Note the {{localhost}} string in place of properly generated UUID: MODCLUSTER-451. > For some historical context, I suggest: MODCLUSTER-91 and MODCLUSTER-168 -- 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