![]() Please wait while updating issue type...
Could not save your changes
This issue has been changed since you started editing it
Data that has been changed is highlighted in red below. Undo your changes to see the updated information
You have changed this issue, but haven't saved your changes yet. To save it, press the Save changes button to the right
This issue is blocking the next release
![]() There are no comments
There is nothing attached to this issue
This issue has no duplicates
7454d93
May 10, 23:18 - Preceeded by d7ac8f1a0c4616b90dad8f464842b115d1bb1d49
Log entry
issue JPPF-396, designed and implemented MonitoringDataProvider feature: - implemented mechaism to add any number of data provider - re-implemented data provided in HealthSnapshot as a built-in provider Changed files
Affected issues
f21f7c8
May 11, 00:39 - Preceeded by 52667add6647f2ca8cab7eabd3bdb0af63aa06c6
Log entry
issue JPPF-396 fixed error on system cpu load property Changed files
Affected issues
42890a0
May 17, 08:59 - Preceeded by 4af078e34829ec23d02eac51f5ed9bf9e659557b
Log entry
issue JPPF-396 implemented support for localization Changed files
Affected issues
4a2c4e2
May 18, 09:37 - Preceeded by e6ea9c4bbdcbeea281c04a21d5e29ff7e1f63f84
Log entry
issue JPPF-396 fixed deadlocked icon rendering issue Changed files
Affected issues
780b71d
May 18, 09:38 - Preceeded by 4a2c4e2a4a798d9ed16b3c1fc56999b9b61550e5
Log entry
issue JPPF-396 fixing physical RAM calculation Changed files
Affected issues
415f637
May 23, 19:39 - Preceeded by 534110ba319e30d597e64e4dc7c32cafb8eff883
Log entry
issue JPPF-396 integrated Oshi with JPPF and the built-in MonitoringDataProvider Changed files
Affected issues
476f8b1
May 23, 20:26 - Preceeded by e889b1b5ed9e8c44686031fb27448b6f2606ec6a
Log entry
issue JPPF-396 fixed mistake in pom.xml of common module Changed files
Affected issues
76eab95
May 29, 06:59 - Preceeded by ef9b4fd2666e29fe622342d80c6fa57a3a43ffc9
Log entry
issue JPPF-396 made Oshi's SystemInfo a singleton with a static accessor Changed files
Affected issues
020f6fc
Jun 03, 19:29 - Preceeded by fb768236cd390fd29d0624a7a289b3f419265bba
Log entry
issue JPPF-396 wrote documentation Changed files
Affected issues
|
|||||||||||||||||||||||||||||
Really delete this comment?
SystemB.java
GlobalMemory.java
Really delete this comment?
Really delete this comment?
Linux provides some memory information from the sysinfo() function and its associated structure. (Aside: the structure has a byte-array as padding which ends up 0-length on most 64-bit systems (if sizeof(long)=8 and sizeof(int)=4) which JNA can't handle, so there's a bit of complexity just to grab the "total" and "free" amounts from here.)
Unfortunately, this method does not provide access to inactive memory, which is necessary to calculate truly available memory. To get this value, one must call global_page_state() twice with appropriate integers corresponding to 2 different enums. And while I can read the source code and know the value of the important enums (I know it's 0 for one and 2 for another) I'm not sure it's good practice to rely on nobody every inserting a new value in the enum and throwing off future calculations. Also sysconf() has to be called to get the page size.
So, for available memory, one has to call 4 linux native functions, sysinfo (for free bytes), global_page_state twice (using enums that may one day change) for inactive pages of two different types, and sysconf() for page size.
Alternately, one can simply read the pseudo-file /proc/meminfo. This isn't an actual file; it's a hook into the kernel's meminfo function, eventually returning a string that can be parsed to get the information we want... a lot more reliably and flexibly. No disk reads are involved, so it's fast. And probably the best option.
Really delete this comment?
I've essentially taken over Oshi as the main "developer" (high honors for an amateur coder) and have written most of the existing code for the memory and CPU functions. I think the EPL license is liberal enough for you to take what you need here, but I'm happy to personally contribute any patches you need if licensing is a concern. I've already contributed the Mac SystemB code quoted above to the JNA project, which is in the current version, making implementation even easier.
It would be nice to get a true "free memory" reading on my linux JPPF nodes in the next minor release.
Really delete this comment?
Really delete this comment?
Instead of just adding the information provided by Oshi, I will also refactor the diagnostics so that it can take additional information from pluggable providers. In particular, the HealthSnapshot class will become a collection of named properties fed by the providers. To validate the excercise, a built-in data provider based on Oshi will be implemented and made available in the distribution.
The counterpart to this is the ability to add columns to the JVM health view of the desktop and web admin consoles, along with the ability to make data availble for the charts in the desktop console (I haven't found an "easy" way to the web console yet). This will be covered in another feature request I'm about to create.
Really delete this comment?
Really delete this comment?
Really delete this comment?
Now on to implementing a provider wrapping the OSHI APIs.
Really delete this comment?
lolo4j wrote:
Really delete this comment?