June 2013 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-347?page=com.atlassian.jira.pl... ] Aaron Ogburn commented on MODCLUSTER-347: ----------------------------------------- I whipped up a fix on 1.2.x that works for me locally: https://github.com/modcluster/mod_cluster/pull/35 The idea is to just go ahead and check for and print all matching aliases when we first encounter a new vhost. Will that do? > mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page > ---------------------------------------------------------------------------------------- > > Key: MODCLUSTER-347 > URL: https://issues.jboss.org/browse/MODCLUSTER-347 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Environment: -JBoss Enterprise Application Platform (EAP 6.1.0) > -mod_cluster 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Attachments: mod_cluster-manager.html > > > Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause: > balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1 > node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 > host: 1 [example3.com] vhost: 3 node: 1 > host: 2 [example2.com] vhost: 3 node: 1 > host: 3 [example.com] vhost: 3 node: 1 > host: 4 [localhost] vhost: 3 node: 1 > host: 5 [example6.com] vhost: 1 node: 1 > host: 6 [example5.com] vhost: 1 node: 1 > host: 7 [example4.com] vhost: 1 node: 1 > host: 8 [testhost2] vhost: 1 node: 1 > host: 9 [default-host] vhost: 3 node: 1 > host: 10 [example9.com] vhost: 2 node: 1 > host: 11 [example8.com] vhost: 2 node: 1 > host: 12 [example7.com] vhost: 2 node: 1 > host: 13 [testhost3] vhost: 2 node: 1 > context: 1 [/helloworld2] vhost: 3 node: 1 status: 1 > context: 2 [/helloworld3] vhost: 1 node: 1 status: 1 > context: 3 [/] vhost: 2 node: 1 status: 1 > The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries. > The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-347?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-347: ------------------------------------ Git Pull Request: https://github.com/modcluster/mod_cluster/pull/35 > mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page > ---------------------------------------------------------------------------------------- > > Key: MODCLUSTER-347 > URL: https://issues.jboss.org/browse/MODCLUSTER-347 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Environment: -JBoss Enterprise Application Platform (EAP 6.1.0) > -mod_cluster 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Attachments: mod_cluster-manager.html > > > Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause: > balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1 > node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 > host: 1 [example3.com] vhost: 3 node: 1 > host: 2 [example2.com] vhost: 3 node: 1 > host: 3 [example.com] vhost: 3 node: 1 > host: 4 [localhost] vhost: 3 node: 1 > host: 5 [example6.com] vhost: 1 node: 1 > host: 6 [example5.com] vhost: 1 node: 1 > host: 7 [example4.com] vhost: 1 node: 1 > host: 8 [testhost2] vhost: 1 node: 1 > host: 9 [default-host] vhost: 3 node: 1 > host: 10 [example9.com] vhost: 2 node: 1 > host: 11 [example8.com] vhost: 2 node: 1 > host: 12 [example7.com] vhost: 2 node: 1 > host: 13 [testhost3] vhost: 2 node: 1 > context: 1 [/helloworld2] vhost: 3 node: 1 status: 1 > context: 2 [/helloworld3] vhost: 1 node: 1 status: 1 > context: 3 [/] vhost: 2 node: 1 status: 1 > The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries. > The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-347?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-347: ------------------------------------ Workaround Description: don't deploy multiple applications at once (was: don't deploy applications at once) > mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page > ---------------------------------------------------------------------------------------- > > Key: MODCLUSTER-347 > URL: https://issues.jboss.org/browse/MODCLUSTER-347 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Environment: -JBoss Enterprise Application Platform (EAP 6.1.0) > -mod_cluster 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Attachments: mod_cluster-manager.html > > > Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause: > balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1 > node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 > host: 1 [example3.com] vhost: 3 node: 1 > host: 2 [example2.com] vhost: 3 node: 1 > host: 3 [example.com] vhost: 3 node: 1 > host: 4 [localhost] vhost: 3 node: 1 > host: 5 [example6.com] vhost: 1 node: 1 > host: 6 [example5.com] vhost: 1 node: 1 > host: 7 [example4.com] vhost: 1 node: 1 > host: 8 [testhost2] vhost: 1 node: 1 > host: 9 [default-host] vhost: 3 node: 1 > host: 10 [example9.com] vhost: 2 node: 1 > host: 11 [example8.com] vhost: 2 node: 1 > host: 12 [example7.com] vhost: 2 node: 1 > host: 13 [testhost3] vhost: 2 node: 1 > context: 1 [/helloworld2] vhost: 3 node: 1 status: 1 > context: 2 [/helloworld3] vhost: 1 node: 1 status: 1 > context: 3 [/] vhost: 2 node: 1 status: 1 > The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries. > The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-347?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-347: ------------------------------------ Attachment: mod_cluster-manager.html > mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page > ---------------------------------------------------------------------------------------- > > Key: MODCLUSTER-347 > URL: https://issues.jboss.org/browse/MODCLUSTER-347 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Environment: -JBoss Enterprise Application Platform (EAP 6.1.0) > -mod_cluster 1.2.4.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Attachments: mod_cluster-manager.html > > > Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause: > balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1 > node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 > host: 1 [example3.com] vhost: 3 node: 1 > host: 2 [example2.com] vhost: 3 node: 1 > host: 3 [example.com] vhost: 3 node: 1 > host: 4 [localhost] vhost: 3 node: 1 > host: 5 [example6.com] vhost: 1 node: 1 > host: 6 [example5.com] vhost: 1 node: 1 > host: 7 [example4.com] vhost: 1 node: 1 > host: 8 [testhost2] vhost: 1 node: 1 > host: 9 [default-host] vhost: 3 node: 1 > host: 10 [example9.com] vhost: 2 node: 1 > host: 11 [example8.com] vhost: 2 node: 1 > host: 12 [example7.com] vhost: 2 node: 1 > host: 13 [testhost3] vhost: 2 node: 1 > context: 1 [/helloworld2] vhost: 3 node: 1 status: 1 > context: 2 [/helloworld3] vhost: 1 node: 1 status: 1 > context: 3 [/] vhost: 2 node: 1 status: 1 > The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries. > The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-347) mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page

by Aaron Ogburn (JIRA)

Aaron Ogburn created MODCLUSTER-347: --------------------------------------- Summary: mod_cluster-manager may break up aliases from a single VirtualHost, causing a messy page Key: MODCLUSTER-347 URL: https://issues.jboss.org/browse/MODCLUSTER-347 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.4.Final Environment: -JBoss Enterprise Application Platform (EAP 6.1.0) -mod_cluster 1.2.4.Final Reporter: Aaron Ogburn Assignee: Jean-Frederic Clere Now that we properly show all the individual virtual hosts for a node, mod_cluster-manager may display a messy page with the aliases from a single Virtual Host broken up with multiple instances of the Virtual Host and its contexts. This can occur with our concurrent start ups now when JBoss has multiple applications bound to virtual servers that are deploying and enabling at once. The dump output demonstrates the cause: balancer: [1] Name: mycluster Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1 node: [1:1],Balancer: mycluster,JVMRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516,LBGroup: [],Host: 127.0.0.1,Port: 8009,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0 host: 1 [example3.com] vhost: 3 node: 1 host: 2 [example2.com] vhost: 3 node: 1 host: 3 [example.com] vhost: 3 node: 1 host: 4 [localhost] vhost: 3 node: 1 host: 5 [example6.com] vhost: 1 node: 1 host: 6 [example5.com] vhost: 1 node: 1 host: 7 [example4.com] vhost: 1 node: 1 host: 8 [testhost2] vhost: 1 node: 1 host: 9 [default-host] vhost: 3 node: 1 host: 10 [example9.com] vhost: 2 node: 1 host: 11 [example8.com] vhost: 2 node: 1 host: 12 [example7.com] vhost: 2 node: 1 host: 13 [testhost3] vhost: 2 node: 1 context: 1 [/helloworld2] vhost: 3 node: 1 status: 1 context: 2 [/helloworld3] vhost: 1 node: 1 status: 1 context: 3 [/] vhost: 2 node: 1 status: 1 The messy html representative of this bad output is attached. Note host entry 9 is for vhost 3, but separated in the html from the other vhost 3 entries. The problem is in manager_info_hosts. It assumes all of those entries will be in order, printing out the Virtual Host/Context lines whenever a different vhost entry is seen. It'd be much cleaner if we ensured each VirtualHost was only ever printed once on the page. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-346) :read-proxies-configuration and :read-proxies-info fail when there is no httpd

by Kristina Clair (JIRA)

Kristina Clair created MODCLUSTER-346: ----------------------------------------- Summary: :read-proxies-configuration and :read-proxies-info fail when there is no httpd Key: MODCLUSTER-346 URL: https://issues.jboss.org/browse/MODCLUSTER-346 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.4.Final Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch, Reporter: Kristina Clair Assignee: Jean-Frederic Clere When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error. On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host: {noformat} [domain@localhost:9999 subsystem=modcluster] pwd /host=localhost/server=cluster2/subsystem=modcluster [domain@localhost:9999 subsystem=modcluster] :list-proxies { "outcome" => "success", "result" => [ "web02:8009", "web01:8009" ] } [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration { "outcome" => "failed", "result" => undefined, "failure-description" => "JBAS014749: Operation handler failed: newValue is null", "rolled-back" => true } [domain@localhost:9999 subsystem=modcluster] :read-proxies-info { "outcome" => "failed", "result" => undefined, "failure-description" => "JBAS014749: Operation handler failed: newValue is null", "rolled-back" => true } {noformat} In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-322) Using AverageSystemLoadMetric can improperly cause a Load Factor of 0

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-322?page=com.atlassian.jira.pl... ] Jean-Frederic Clere closed MODCLUSTER-322. ------------------------------------------ Resolution: Done merged > Using AverageSystemLoadMetric can improperly cause a Load Factor of 0 > --------------------------------------------------------------------- > > Key: MODCLUSTER-322 > URL: https://issues.jboss.org/browse/MODCLUSTER-322 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.1.Final, MOD_CLUSTER_1_0_10_GA_CP04 > Environment: *JBoss Enterprise Application Platform 5 > *Apache httpd > *mod_cluster 1.0.10.GA_CP02 or 1.2.1 > Reporter: Aaron Ogburn > Assignee: Paul Ferraro > Fix For: 1.2.2.Final, MOD_CLUSTER_1_0_10_GA_CP03 > > > It looks like AverageSystemLoadMetric is not properly implemented. When using it, mod_cluster may always report a load factor of 0, thus making the JBoss node unreachable from Apache. We've tested with a simple web app that checks the underlying MXBean SystemLoadAverage: > Double.class.cast(server.getAttribute(ObjectName.getInstance(ManagementFactory.OPERATING_SYSTEM_MXBEAN_NAME), "SystemLoadAverage")).doubleValue() > This info is grabbed pretty much the same way mod_cluster does, but these calls appeared to work just fine outside of mod_cluster as it returns the following values from my test app: > 12:08:26,519 INFO [STDOUT] From MBeanServer: 1.81640625 > So the issue does not appear to be necessarily with the underlying JDK/MXBean call but with how mod_cluster is handling the data grabbed from it. But the root cause here appears to be that a value above 1 is being returned, and it looks like mod_cluster is expecting metrics to return a 0-1 percentile based range. > The way the load is determined allows the AverageSystemLoadMetric to improperly exceed its weight. For example if it were weighted as 2 and another metric was weighted at 1 (say RequestCountLoadMetric with a capacity of 1000), then AverageSystemLoadMetric should only be able to account for 67% of the load. But here we can see AverageSystemLoadMetric can out run its weight and really account for 100% of the load. So let's say AverageSystemLoadMetric is the above seen 1.81640625 value with 100 requests/second, putting RequestCountLoadMetric at .1 load, so DynamicLoadBalanceFactorProvider would calculate the load factor like so: > int load = (int) Math.round(100 * totalWeightedLoad / totalWeight); > int load = (int) Math.round(100 * (1.81640625 * 2 + 0.1) / 3); > load = 124.4 > And that gets truncated down to 100 so AverageSystemLoadMetric comes to represent really all of the load. But if a 2 weight metric is at its max and a 1 weight metric is at .1%, then their total load should just be ~70-71%. > S is mod_cluster assuming that the SystemLoadAverage will always be between 0 and 1? Does it look like mod_cluster is not properly scaling this metric? Do we know a definite max return to expect from OperatingSystemMXBean.getSystemLoadAverage() so that this metric can be scaled more in line with the other percentile based ones? Or should a user definable max capacity be implemented into this metric as it is with others? -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-322) Using AverageSystemLoadMetric can improperly cause a Load Factor of 0

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-322?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-322: ------------------------------------ Affects Version/s: MOD_CLUSTER_1_0_10_GA_CP04 (was: MOD_CLUSTER_1_0_10_GA_CP02) > Using AverageSystemLoadMetric can improperly cause a Load Factor of 0 > --------------------------------------------------------------------- > > Key: MODCLUSTER-322 > URL: https://issues.jboss.org/browse/MODCLUSTER-322 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.1.Final, MOD_CLUSTER_1_0_10_GA_CP04 > Environment: *JBoss Enterprise Application Platform 5 > *Apache httpd > *mod_cluster 1.0.10.GA_CP02 or 1.2.1 > Reporter: Aaron Ogburn > Assignee: Paul Ferraro > Fix For: MOD_CLUSTER_1_0_10_GA_CP03, 1.2.2.Final > > > It looks like AverageSystemLoadMetric is not properly implemented. When using it, mod_cluster may always report a load factor of 0, thus making the JBoss node unreachable from Apache. We've tested with a simple web app that checks the underlying MXBean SystemLoadAverage: > Double.class.cast(server.getAttribute(ObjectName.getInstance(ManagementFactory.OPERATING_SYSTEM_MXBEAN_NAME), "SystemLoadAverage")).doubleValue() > This info is grabbed pretty much the same way mod_cluster does, but these calls appeared to work just fine outside of mod_cluster as it returns the following values from my test app: > 12:08:26,519 INFO [STDOUT] From MBeanServer: 1.81640625 > So the issue does not appear to be necessarily with the underlying JDK/MXBean call but with how mod_cluster is handling the data grabbed from it. But the root cause here appears to be that a value above 1 is being returned, and it looks like mod_cluster is expecting metrics to return a 0-1 percentile based range. > The way the load is determined allows the AverageSystemLoadMetric to improperly exceed its weight. For example if it were weighted as 2 and another metric was weighted at 1 (say RequestCountLoadMetric with a capacity of 1000), then AverageSystemLoadMetric should only be able to account for 67% of the load. But here we can see AverageSystemLoadMetric can out run its weight and really account for 100% of the load. So let's say AverageSystemLoadMetric is the above seen 1.81640625 value with 100 requests/second, putting RequestCountLoadMetric at .1 load, so DynamicLoadBalanceFactorProvider would calculate the load factor like so: > int load = (int) Math.round(100 * totalWeightedLoad / totalWeight); > int load = (int) Math.round(100 * (1.81640625 * 2 + 0.1) / 3); > load = 124.4 > And that gets truncated down to 100 so AverageSystemLoadMetric comes to represent really all of the load. But if a 2 weight metric is at its max and a 1 weight metric is at .1%, then their total load should just be ~70-71%. > S is mod_cluster assuming that the SystemLoadAverage will always be between 0 and 1? Does it look like mod_cluster is not properly scaling this metric? Do we know a definite max return to expect from OperatingSystemMXBean.getSystemLoadAverage() so that this metric can be scaled more in line with the other percentile based ones? Or should a user definable max capacity be implemented into this metric as it is with others? -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-322) Using AverageSystemLoadMetric can improperly cause a Load Factor of 0

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-322?page=com.atlassian.jira.pl... ] Aaron Ogburn reopened MODCLUSTER-322: ------------------------------------- Reopening this as it looks like we made a mistake fixing this for EAP 5/mod_cluster 1.0.10.GA_CP. Looks like the fix was committed to trunk, the 1.0.x branch, and the 1.0.10.GA_CP03 tag directly. When we tagged 1.0.10.GA_CP04, we tagged it from the MOD_CLUSTER_1_0_10_GA_CP branch. This branch didn't have the fix and so CP04 and EAP 5.2.0 lost this fix. Fix needs to be added to the MOD_CLUSTER_1_0_10_GA_CP branch for future releases. Put in the following pull request for that: https://github.com/modcluster/mod_cluster/pull/34/ > Using AverageSystemLoadMetric can improperly cause a Load Factor of 0 > --------------------------------------------------------------------- > > Key: MODCLUSTER-322 > URL: https://issues.jboss.org/browse/MODCLUSTER-322 > Project: mod_cluster > Issue Type: Bug > Affects Versions: MOD_CLUSTER_1_0_10_GA_CP02, 1.2.1.Final > Environment: *JBoss Enterprise Application Platform 5 > *Apache httpd > *mod_cluster 1.0.10.GA_CP02 or 1.2.1 > Reporter: Aaron Ogburn > Assignee: Paul Ferraro > Fix For: MOD_CLUSTER_1_0_10_GA_CP03, 1.2.2.Final > > > It looks like AverageSystemLoadMetric is not properly implemented. When using it, mod_cluster may always report a load factor of 0, thus making the JBoss node unreachable from Apache. We've tested with a simple web app that checks the underlying MXBean SystemLoadAverage: > Double.class.cast(server.getAttribute(ObjectName.getInstance(ManagementFactory.OPERATING_SYSTEM_MXBEAN_NAME), "SystemLoadAverage")).doubleValue() > This info is grabbed pretty much the same way mod_cluster does, but these calls appeared to work just fine outside of mod_cluster as it returns the following values from my test app: > 12:08:26,519 INFO [STDOUT] From MBeanServer: 1.81640625 > So the issue does not appear to be necessarily with the underlying JDK/MXBean call but with how mod_cluster is handling the data grabbed from it. But the root cause here appears to be that a value above 1 is being returned, and it looks like mod_cluster is expecting metrics to return a 0-1 percentile based range. > The way the load is determined allows the AverageSystemLoadMetric to improperly exceed its weight. For example if it were weighted as 2 and another metric was weighted at 1 (say RequestCountLoadMetric with a capacity of 1000), then AverageSystemLoadMetric should only be able to account for 67% of the load. But here we can see AverageSystemLoadMetric can out run its weight and really account for 100% of the load. So let's say AverageSystemLoadMetric is the above seen 1.81640625 value with 100 requests/second, putting RequestCountLoadMetric at .1 load, so DynamicLoadBalanceFactorProvider would calculate the load factor like so: > int load = (int) Math.round(100 * totalWeightedLoad / totalWeight); > int load = (int) Math.round(100 * (1.81640625 * 2 + 0.1) / 3); > load = 124.4 > And that gets truncated down to 100 so AverageSystemLoadMetric comes to represent really all of the load. But if a 2 weight metric is at its max and a 1 weight metric is at .1%, then their total load should just be ~70-71%. > S is mod_cluster assuming that the SystemLoadAverage will always be between 0 and 1? Does it look like mod_cluster is not properly scaling this metric? Do we know a definite max return to expect from OperatingSystemMXBean.getSystemLoadAverage() so that this metric can be scaled more in line with the other percentile based ones? Or should a user definable max capacity be implemented into this metric as it is with others? -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-334) mod_cluster core when use ProxyPass / balancer://bal and CreateBalancers 1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-334?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-334: ---------------------------------------------------- Jean-frederic Clere <jclere(a)redhat.com> made a comment on [bug 958990|https://bugzilla.redhat.com/show_bug.cgi?id=958990] Doc Text looks ok. > mod_cluster core when use ProxyPass / balancer://bal and CreateBalancers 1 > -------------------------------------------------------------------------- > > Key: MODCLUSTER-334 > URL: https://issues.jboss.org/browse/MODCLUSTER-334 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.4.Final > Environment: Any > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Fix For: 1.2.5.Final > > > Use something like: > ProxyPass / balancer://neo5 > CreateBalancers 1 > When the first STATUS is received from a node using the balancer (neo5) httpd will dump a core. -- 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

11 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2013