[#RIO-220] Excessive WARNINGs in log when no sigar available

Rio

Excessive WARNINGs in log when no sigar available

Created: 16/Feb/10 07:44 PM Updated: 19/Feb/10 09:47 AM

Component/s:

None

Affects Version/s:

4.0 M3

Fix Version/s:

4.0

Time Tracking:

Not Specified

Environment:

FreeBSD 8.0, sigar temporarily not builds

Description

« Hide

On my OS sigar is not building for the time being. As a consequence calls to SigarHelper methods results in continued WARNINGs with stacktraces that clutters log.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Dennis Reedy added a comment - 16/Feb/10 08:59 PM

Can you include a snippet of the logger messages?

[ Permalink | « Hide ]

Zsolt Kúti added a comment - 17/Feb/10 09:25 AM

The scheme below is repeated originating from the different sigar methods.

WARNING: Failed invoking getProcCpu method
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.rioproject.system.measurable.SigarHelper.getProcessCpuUser(SigarHelper.java:366)
at org.rioproject.system.measurable.cpu.ProcessCPUHandler.getUtilization(ProcessCPUHandler.java:105)
at org.rioproject.system.measurable.cpu.ProcessCPUHandler.getMeasuredResource(ProcessCPUHandler.java:91)
at org.rioproject.system.measurable.cpu.CPU.checkValue(CPU.java:155)
at org.rioproject.system.measurable.MeasurableCapability.getMeasuredResource(MeasurableCapability.java:261)
at org.rioproject.system.ComputeResource.getMeasuredResources(ComputeResource.java:699)
at org.rioproject.system.ComputeResource.getComputeResourceUtilization(ComputeResource.java:799)
at org.rioproject.system.ComputeResource.getResourceCapability(ComputeResource.java:785)
at org.rioproject.cybernode.CybernodeAdapter.getResourceCapability(CybernodeAdapter.java:61)
at org.rioproject.cybernode.ServiceConsumer.register(ServiceConsumer.java:291)
at org.rioproject.cybernode.ServiceConsumer.serviceAdded(ServiceConsumer.java:235)
at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.serviceNotifyDo(ServiceDiscoveryManager.java:2130)
at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.serviceNotifyDo(ServiceDiscoveryManager.java:2117)
at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.addServiceNotify(ServiceDiscoveryManager.java:2077)
at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.access$2500(ServiceDiscoveryManager.java:821)
at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl$NewOldServiceTask.run(ServiceDiscoveryManager.java:1393)
at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331)
Caused by: org.hyperic.sigar.SigarException: java.lang.UnsatisfiedLinkError: org.hyperic.sigar.ProcCpu.gather(Lorg/hyperic/sigar/Sigar;J)V: -1
at org.hyperic.sigar.SigarProxyCache.invoke(SigarProxyCache.java:222)
at $Proxy21.getProcCpu(Unknown Source)
... 21 more

[ Show » ]

Zsolt Kúti added a comment - 17/Feb/10 09:25 AM The scheme below is repeated originating from the different sigar methods. WARNING: Failed invoking getProcCpu method java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.rioproject.system.measurable.SigarHelper.getProcessCpuUser(SigarHelper.java:366) at org.rioproject.system.measurable.cpu.ProcessCPUHandler.getUtilization(ProcessCPUHandler.java:105) at org.rioproject.system.measurable.cpu.ProcessCPUHandler.getMeasuredResource(ProcessCPUHandler.java:91) at org.rioproject.system.measurable.cpu.CPU.checkValue(CPU.java:155) at org.rioproject.system.measurable.MeasurableCapability.getMeasuredResource(MeasurableCapability.java:261) at org.rioproject.system.ComputeResource.getMeasuredResources(ComputeResource.java:699) at org.rioproject.system.ComputeResource.getComputeResourceUtilization(ComputeResource.java:799) at org.rioproject.system.ComputeResource.getResourceCapability(ComputeResource.java:785) at org.rioproject.cybernode.CybernodeAdapter.getResourceCapability(CybernodeAdapter.java:61) at org.rioproject.cybernode.ServiceConsumer.register(ServiceConsumer.java:291) at org.rioproject.cybernode.ServiceConsumer.serviceAdded(ServiceConsumer.java:235) at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.serviceNotifyDo(ServiceDiscoveryManager.java:2130) at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.serviceNotifyDo(ServiceDiscoveryManager.java:2117) at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.addServiceNotify(ServiceDiscoveryManager.java:2077) at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl.access$2500(ServiceDiscoveryManager.java:821) at net.jini.lookup.ServiceDiscoveryManager$LookupCacheImpl$NewOldServiceTask.run(ServiceDiscoveryManager.java:1393) at com.sun.jini.thread.TaskManager$TaskThread.run(TaskManager.java:331) Caused by: org.hyperic.sigar.SigarException: java.lang.UnsatisfiedLinkError: org.hyperic.sigar.ProcCpu.gather(Lorg/hyperic/sigar/Sigar;J)V: -1 at org.hyperic.sigar.SigarProxyCache.invoke(SigarProxyCache.java:222) at $Proxy21.getProcCpu(Unknown Source) ... 21 more

[ Permalink | « Hide ]

Dennis Reedy added a comment - 17/Feb/10 06:58 PM

Instead of printing the stacktrace by default, Rio will log the cause and the message. So the above would look like:

WARNING: Failed invoking getProcCpu method. Caused by: org.hyperic.sigar.SigarException: java.lang.UnsatisfiedLinkError: org.hyperic.sigar.ProcCpu.gather(Lorg/hyperic/sigar/Sigar;J)V: -1

If however the org.rioproject.system.measurable logger is set to Level.FINE, the verbosity will be turned up to include the complete stacktrace.

Is this sufficient?

[ Permalink | « Hide ]

Dennis Reedy added a comment - 17/Feb/10 10:45 PM

Reduce verbosity and also put a test check even if the Sigar class is loaded that it can be used

[ Permalink | « Hide ]

Zsolt Kúti added a comment - 18/Feb/10 08:40 AM

The other problem beyond verbosity is the constant production of such failed invocations. Even single lines can still amount to large numbers with time.

[ Permalink | « Hide ]

Dennis Reedy added a comment - 18/Feb/10 03:04 PM

As indicated, a test has been put in to verify that not only the sigar class can be reflectively loaded, but also to check if the loaded sigar runtime can be used. This seems to address your unique condition for a sigar installation that is not valid.

[ Permalink | « Hide ]

Zsolt Kúti added a comment - 19/Feb/10 09:47 AM

OK, it seems I did not understand what that means. It's fine then. Thanks!