[JBoss JIRA] (MODCLUSTER-338) Advertise adds a message digest even if security key is not configured
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-338?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-338:
--------------------------------------
Summary: Advertise adds a message digest even if security key is not configured (was: Advertize adds a message digest even if security key is not configured)
> Advertise adds a message digest even if security key is not configured
> ----------------------------------------------------------------------
>
> Key: MODCLUSTER-338
> URL: https://issues.jboss.org/browse/MODCLUSTER-338
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.4.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 1.3.0.Alpha1
>
>
> As wireshark hints, the message digest is always included in the message even if the advertise security key is not configured.
> This would not be such a problem if the salt actually used wouldn't be random bits from the memory.
> This renders the digest completely useless since it can never be verified.
--
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
[JBoss JIRA] (MODCLUSTER-358) demo in master branch does not compile on JDK6
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-358?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-358:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Done, compiles now fine with
java version "1.6.0_43"
Java(TM) SE Runtime Environment (build 1.6.0_43-b01)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)
> demo in master branch does not compile on JDK6
> ----------------------------------------------
>
> Key: MODCLUSTER-358
> URL: https://issues.jboss.org/browse/MODCLUSTER-358
> Project: mod_cluster
> Issue Type: Bug
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 1.3.0.Alpha2
>
>
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /home/rhusar/git/mod_cluster/demo/client/src/main/java/org/jboss/modcluster/demo/client/ModClusterDemo.java:[933,90] type javax.swing.ListCellRenderer does not take parameters
> [ERROR] /home/rhusar/git/mod_cluster/demo/client/src/main/java/org/jboss/modcluster/demo/client/ModClusterDemo.java:[937,59] type javax.swing.JList does not take parameters
> [ERROR] /home/rhusar/git/mod_cluster/demo/client/src/main/java/org/jboss/modcluster/demo/client/ModClusterDemo.java:[504,23] type javax.swing.JComboBox does not take parameters
> [ERROR] /home/rhusar/git/mod_cluster/demo/client/src/main/java/org/jboss/modcluster/demo/client/ModClusterDemo.java:[504,82] type javax.swing.JComboBox does not take parameters
> [ERROR] /home/rhusar/git/mod_cluster/demo/client/src/main/java/org/jboss/modcluster/demo/client/ModClusterDemo.java:[936,8] method does not override or implement a method from a supertype
> [INFO] 5 errors
--
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
[JBoss JIRA] (MODCLUSTER-288) SystemMemoryUsageLoadMetric is not correct on Linux/Unix
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-288?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-288:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Done. The 1.2.x is remain as is. We shouldn't be just dropping functionality (even if its not perfect).
> 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.Alpha2
>
>
> 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
11 years
[JBoss JIRA] (MODCLUSTER-288) SystemMemoryUsageLoadMetric is not correct on Linux/Unix
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-288?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-288:
--------------------------------------
Fix Version/s: 1.3.0.Alpha2
Affects Version/s: 1.3.0.Alpha1
> 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.Alpha2
>
>
> 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
11 years
[JBoss JIRA] (MODCLUSTER-288) SystemMemoryUsageLoadMetric is not correct on Linux/Unix
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-288?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-288:
--------------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/modcluster/mod_cluster/pull/52
> 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
> Environment: Linux/Unix operating systems with standard memory management
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
>
> 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
11 years
[JBoss JIRA] (MODCLUSTER-288) SystemMemoryUsageLoadMetric is not correct on Linux/Unix
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-288?page=com.atlassian.jira.pl... ]
Radoslav Husar reopened MODCLUSTER-288:
---------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
+1
Lets drop this for 1.3.0.Final and since.
> 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
> Environment: Linux/Unix operating systems with standard memory management
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
>
> 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
11 years
