March 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-394) Address issues found by code inspections: Java part

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-394: ----------------------------------------- Summary: Address issues found by code inspections: Java part Key: MODCLUSTER-394 URL: https://issues.jboss.org/browse/MODCLUSTER-394 Project: mod_cluster Issue Type: Sub-task Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-382) Address issues found by code inspections

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-382?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-382: ------------------------------------------- Let me split this to 2 issues then, so we can address Java and C separately. > Address issues found by code inspections > ---------------------------------------- > > Key: MODCLUSTER-382 > URL: https://issues.jboss.org/browse/MODCLUSTER-382 > Project: mod_cluster > Issue Type: Task > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > Fix For: 1.3.1.Final > > > There are about 70 javadoc issues, 20 redundant declarations, etc. Would be nice to address before final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-289) MemManagerFile creates directory but put files in ..

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-289?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-289. ------------------------------------- Ain't an issue anymore. > MemManagerFile creates directory but put files in .. > ---------------------------------------------------- > > Key: MODCLUSTER-289 > URL: https://issues.jboss.org/browse/MODCLUSTER-289 > Project: mod_cluster > Issue Type: Bug > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.2.1.Beta2 > > > MemManagerFile /var/cache/httpd/FILES > [root@neo4 jfclere]# ls -lt /var/cache/httpd/ > total 28 > -rw-r--r--. 1 root root 4 Mar 2 17:05 FILES.domain.domain > -rw-r--r--. 1 root root 4 Mar 2 17:05 FILES.balancer.balancers > -rw-r--r--. 1 root root 0 Mar 2 17:05 FILES.balancer.balancers.lock > -rw-r--r--. 1 root root 0 Mar 2 17:05 FILES.domain.domain.lock > -rw-r--r--. 1 root root 4 Mar 2 17:05 FILES.sessionid.sessionid > -rw-r--r--. 1 root root 0 Mar 2 17:05 FILES.sessionid.sessionid.lock > -rw-r--r--. 1 root root 4 Mar 2 17:05 FILES.context.contexts > -rw-r--r--. 1 root root 0 Mar 2 17:05 FILES.context.contexts.lock > -rw-r--r--. 1 root root 4 Mar 2 17:05 FILES.host.hosts > -rw-r--r--. 1 root root 0 Mar 2 17:05 FILES.host.hosts.lock > -rw-r--r--. 1 root root 4 Mar 2 17:05 FILES.node.nodes > -rw-r--r--. 1 root root 0 Mar 2 17:05 FILES.node.nodes.lock > drwx------. 2 root root 4096 Mar 2 17:05 FILES -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-288) SystemMemoryUsageLoadMetric is not correct on Linux/Unix

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-288?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-288. ------------------------------------- Closing. > SystemMemoryUsageLoadMetric is not correct on Linux/Unix > -------------------------------------------------------- > > Key: MODCLUSTER-288 > URL: https://issues.jboss.org/browse/MODCLUSTER-288 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.0.10, 1.1.0.Final, 1.1.1.Final, 1.2.0.Final, 1.3.0.Alpha1 > Environment: Linux/Unix operating systems with standard memory management > Reporter: Michal Babacek > Assignee: Radoslav Husar > Fix For: 1.3.0.Final > > > I am convinced that the [SystemMemoryUsageLoadMetric.java|https://github.com/modcluster/mod_cluste...] is of no use to anyone. > I have tested it by allocating some memory outside the JVM control with [NativeMemoryStress.c|https://github.com/Karm/clusterbench/blob/system-mem...]. > The results from Mod_cluster are such that the system is almost fully loaded all the time despite the fact that I work with 8GB RAM box with almost nothing running on it. > This [picture|http://hudson.qa.jboss.com/hudson/view/mod_cluster-QE/view/mod_cl...] displays time on X axis and (100-(Load from Mod_cluster)) on Y axis. As you may observe, all 4 nodes appear to be under full load all the time and there is a spike on each of them. This spike represents a period of time when the aforementioned [NativeMemoryStress.c|https://github.com/Karm/clusterbench/blob/system-mem...] was called with the following setting: > {noformat} > megabytes 500; > milliseconds 60000; > {noformat} > What had happened is that kernel has cleared some cache and garbage data from the RAM in order to accommodate new demands, so by the time I freed the memory, there was all of sudden actually more free RAM then before. > The actual problem with the current [SystemMemoryUsageLoadMetric.java|https://github.com/modcluster/mod_cluste...] implementation using [OperatingSystemMXBean|http://docs.oracle.com/javase/6/docs/jre/api/manage...] is that this code: > {code:lang=java} > +++ > public static final String FREE_MEMORY = "FreePhysicalMemorySize"; > public static final String TOTAL_MEMORY = "TotalPhysicalMemorySize"; > +++ > double free = ((Number) this.server.getAttribute(name, FREE_MEMORY)).doubleValue(); > double total = ((Number) this.server.getAttribute(name, TOTAL_MEMORY)).doubleValue(); > return (total - free) / total; > +++ > {code} > Is somewhat similar to this (on 8GB RAM machine with almost nothing running on at the moment): > {noformat} > [karm@killerbox karm]$ free -m > total used free shared buffers cached > Mem: 7933 6755 1177 0 44 141 > -/+ buffers/cache: 6569 1363 > Swap: 16383 58 16325 > {noformat} > Obviously, this does not mean that I could get only 1177MB of RAM if I want to. The "free" actually means "wasted". The majority of RAM is being used as cache. If I ask for e.g. 2GB, I am gonna get them, because kernel will simply sacrifice some cache, clears some garbage from RAM and free up space so as to accommodate my demands. > So, according to my opinion, on a sane, well-behaving caching operating system, the [SystemMemoryUsageLoadMetric.java|https://github.com/modcluster/mod_cluste...] will always show ~ 98% RAM usage. > Due to this fact, this metric is unlikely to be of some use to anyone on Linux/UNIX. What do you think? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-295) default suggested port for ServerAdvertise needs to be changed to 7777 or some other unprotected port for Chrome support

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-295?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-295. ------------------------------------- > default suggested port for ServerAdvertise needs to be changed to 7777 or some other unprotected port for Chrome support > ------------------------------------------------------------------------------------------------------------------------ > > Key: MODCLUSTER-295 > URL: https://issues.jboss.org/browse/MODCLUSTER-295 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.2.0.Final > Environment: Default Httpd server provided for Linux in 1.2.0.Final release but this would affect all platforms. > Reporter: Simeon Pinder > Assignee: Jean-Frederic Clere > Priority: Minor > Labels: rhq > Fix For: 1.2.1.Final > > > If you setup mod_cluster and use the default configuration/ports used in httpd.conf of 6666 in your initial modcluster configuration, when attempting to browse http://(server ip):6666/mod_cluster_manager from a Chrome browser you get "The webpage is not available". Initially this feels like a 'File Not Found' exception indicating that the mod_cluster module may not actually be setup correctly. On closer investigation you'll see that the actual error is: > Error 312 (net::ERR_UNSAFE_PORT): Unknown error. > There's a workaround is to change the port to another port not marked as 'secured' or do what is described here but this is a hurdle to new users trying to test out their mod_cluster integration with Chrome: > http://superuser.com/questions/188006/how-to-fix-err-unsafe-port-error-on... > Firefox loads the same page fine. > Either way if it complicates modcluster setup and testing and we can get around it by suggesting a different port(ex. 7777) I think this is preferable. If not we should at a minimum include this as a note in the installation and trouble shooting guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-304) Port to httpd 2.4

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-304?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-304. ------------------------------------- AFAIK, it compiles and basic tests pass. Closing. > Port to httpd 2.4 > ----------------- > > Key: MODCLUSTER-304 > URL: https://issues.jboss.org/browse/MODCLUSTER-304 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.1.1.Final > Reporter: Marek Goldmann > Assignee: Jean-Frederic Clere > Fix For: 1.2.1.Final > > > Fedora Rawhide (upcoming Fedora 18) switched to HTTPD 2.4. Mod_cluster fails to build against httpd 2.4. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-306) Backport MODCLUSTER-201 to 1.0.10.GA - update mod_cluster to use HTTP/1.1

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-306?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-306. ------------------------------------- > Backport MODCLUSTER-201 to 1.0.10.GA - update mod_cluster to use HTTP/1.1 > ------------------------------------------------------------------------- > > Key: MODCLUSTER-306 > URL: https://issues.jboss.org/browse/MODCLUSTER-306 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: MOD_CLUSTER_1_0_10_GA_CP02 > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Priority: Minor > Fix For: MOD_CLUSTER_1_0_10_GA_CP03 > > > Certain technologies like siteminder require the host header which is not present in HTTP/1.0 so siteminder won't work out of the box with HTTP/1.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-309) mod_proxy_cluster not checking all available balancers (but only the first one) for an available route

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-309?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-309. ------------------------------------- > mod_proxy_cluster not checking all available balancers (but only the first one) for an available route > ------------------------------------------------------------------------------------------------------ > > Key: MODCLUSTER-309 > URL: https://issues.jboss.org/browse/MODCLUSTER-309 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.1.Final > Environment: RedHat EL 6.2, httpd-2.2.15-15.el6 > Reporter: Simone Gotti > Assignee: Jean-Frederic Clere > Fix For: 1.2.2.Final > > > I have an environment with two or more balancers. > I want all the balancers to be available for all the virtualhosts (and maybe filter them using UseAlias). So I'm not configuring any ProxyPass directive but let mod_cluster create the balancers. > During a simple test I noticed that session stickiness was not working for some requests. > Enabling debug I noticed that mod_proxy_cluster:get_route_balancer failed to find a route so the worker was recalculated: > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(2617): proxy_cluster_trans for 0 (null) (null) uri: /context01/jsp01.jsp args: (null) unparsed_uri: /context01/jsp01.jsp > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(2441): cluster: balancer://balancer01 Found value 7tTdLpqWIZjDLcyBrn25tCc9.eb5376bd-c45b-38d1-97e0-c16b97f471d1 for stickysession JSESSIONID|jsessionid > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(2441): cluster: balancer://balancer01 Found value 7tTdLpqWIZjDLcyBrn25tCc9.eb5376bd-c45b-38d1-97e0-c16b97f471d1 for stickysession JSESSIONID|jsessionid > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(2675): proxy_cluster_trans using balancer02 uri: proxy:balancer://balancer02/context01/jsp01.jsp > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(2708): proxy_cluster_canon url: //balancer02/context01/jsp01.jsp > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(3140): proxy_cluster_pre_request: url balancer://balancer02/context01/jsp01.jsp > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(2880): cluster:No route found > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(1854): proxy: Entering byrequests for CLUSTER (balancer://balancer02) > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(1972): proxy: byrequests balancer DONE (ajp://192.168.122.22:8359) > [Tue May 15 16:39:46 2012] [debug] mod_proxy_cluster.c(3368): proxy_cluster_pre_request: balancer (balancer://balancer02) worker (ajp://192.168.122.22:8359) rewritten to ajp://192.168.122.22:8359/context01/jsp01.jsp > Looking at the code looks like mod_cluster checks only the first balancer and, if it does not find any valid route it will give up without retrying the other available balancers. > With this patch it's now checking all the available balancers: > {noformat} > Index: mod_proxy_cluster/mod_proxy_cluster.c > =================================================================== > --- mod_proxy_cluster/mod_proxy_cluster.c (revision 838) > +++ mod_proxy_cluster/mod_proxy_cluster.c (working copy) > @@ -2453,7 +2453,7 @@ > /* Nice we have a route, but make sure we have to serve it */ > int *nodes = find_node_context_host(r, balancer, route, use_alias, vhost_table, context_table); > if (nodes == NULL) > - return NULL; /* we can't serve context/host for the request */ > + continue; /* we can't serve context/host for the request with this balancer*/ > } > if (route && *route) { > char *domain = NULL; > {noformat} > and this is the log after this possible fix: > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2617): proxy_cluster_trans for 0 (null) (null) uri: /context01/ args: (null) unparsed_uri: /context01/ > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2441): cluster: balancer://balancer02 Found value Frjih6gBZzDUg+RFgeUvKJfy.9cedb7e1-5c20-3da7-bd17-9d0bc99b49d3 for stickysession JSESSIONID|jsessionid > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2441): cluster: balancer://balancer01 Found value Frjih6gBZzDUg+RFgeUvKJfy.9cedb7e1-5c20-3da7-bd17-9d0bc99b49d3 for stickysession JSESSIONID|jsessionid > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2461): cluster: Found route 9cedb7e1-5c20-3da7-bd17-9d0bc99b49d3 > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2377): find_nodedomain: finding node for 9cedb7e1-5c20-3da7-bd17-9d0bc99b49d3: balancer01 > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2470): cluster: Found balancer balancer01 for 9cedb7e1-5c20-3da7-bd17-9d0bc99b49d3 > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2675): proxy_cluster_trans using balancer01 uri: proxy:balancer://balancer01/context01/ > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2708): proxy_cluster_canon url: //balancer01/context01/ > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(3140): proxy_cluster_pre_request: url balancer://balancer01/context01/ > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(2876): cluster: Using route 9cedb7e1-5c20-3da7-bd17-9d0bc99b49d3 > [Tue May 15 16:38:36 2012] [debug] mod_proxy_cluster.c(3368): proxy_cluster_pre_request: balancer (balancer://balancer01) worker (ajp://192.168.122.22:8259) rewritten to ajp://192.168.122.22:8259/context01/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-318) make connector address user configurable

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-318?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-318: ------------------------------------------- Hmm, any update on this one? > make connector address user configurable > ---------------------------------------- > > Key: MODCLUSTER-318 > URL: https://issues.jboss.org/browse/MODCLUSTER-318 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.1.Final > Reporter: Aleksandar Kostadinov > Assignee: Jean-Frederic Clere > > MODCLUSTER-168 introduced a change that broke some existing working configurations relying on using IP instead of a hostname. Also it is likely to be the cause of MODCLUSTER-91. > To have everybody happy, this needs to be made configurable, perhaps a system property that user can set to force a particular IP or hostname. It would also be very useful if there is a special value that makes the behavior same as before the changes in MODCLUSTER-168. For example setting the value to -1 would return the original behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-323) TestHang hangs on windows

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-323?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-323: ------------------------------------------- Close? Deferred? Fixed? :-) > TestHang hangs on windows > ------------------------- > > Key: MODCLUSTER-323 > URL: https://issues.jboss.org/browse/MODCLUSTER-323 > Project: mod_cluster > Issue Type: Bug > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > > the test for java/test hangs = takes for ever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2014