+++ This bug was initially created as a clone of Bug #802003 +++ Description of problem: This message is output repeatedly in the logfile: 2012-03-10 06:42:41,984 ERROR [ResourceDiscoveryComponent.invoker.daemon-308] (rhq.core.pc.util.DiscoveryComponentProxyFactory)- Thread [ResourceDiscoveryComponent.invoker.daemon-308] was interrupted. 2012-03-10 06:42:41,984 WARN [ResourceDiscoveryComponent.invoker.daemon-308] (rhq.core.pluginapi.inventory.ResourceContext)- Cannot get native process for resource [JVM] - discovery failed java.lang.RuntimeException: Call to [org.rhq.plugins.jmx.EmbeddedJMXServerDiscoveryComponent.discoverResources()] with args [[org.rhq.core.pluginapi.inventory.ResourceDiscoveryContext@797d8adf]] was interrupted. at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ResourceDiscoveryComponentInvocationHandler.invokeInNewThread(DiscoveryComponentProxyFactory.java:224) at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ResourceDiscoveryComponentInvocationHandler.invoke(DiscoveryComponentProxyFactory.java:207) at $Proxy43.discoverResources(Unknown Source) at org.rhq.core.pluginapi.inventory.ResourceContext.getNativeProcess(ResourceContext.java:230) at org.rhq.plugins.jmx.EmbeddedJMXServerDiscoveryComponent.discoverResources(EmbeddedJMXServerDiscoveryComponent.java:70) at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:292) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1238) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:227) at java.util.concurrent.FutureTask.get(FutureTask.java:91) at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ResourceDiscoveryComponentInvocationHandler.invokeInNewThread(DiscoveryComponentProxyFactory.java:220) ... 13 more And 'Tomcat Server JVM' appears unavailable. Version-Release number of selected component (if applicable): rhq-jmx-plugin-4.3.0-SNAPSHOT.jar How reproducible: Seems to happen with Tomcat discovery.
per BZ Triage 5/29/2012 (ccrouch, loleary, asantos, mfoley, myarborough) moving these to JON 3.1.1 or later
*** Bug 825300 has been marked as a duplicate of this bug. ***
Lukas Please analyze the changes Ian put into master for this issue, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=802003#c11 https://bugzilla.redhat.com/show_bug.cgi?id=802003#c8 then a) Determine if the fix in master is complete (it may not be judging by https://bugzilla.redhat.com/show_bug.cgi?id=802003#c12) b) Determine if we want this fix in jon311. I'm concerned right now that this may be a destabilizing fix. If we don't have sufficient test coverage of the changes Ian then I would be reluctant to include it, given this isn't related to a specific customer issue.
I think the fix is complete. I am not sure what refactoring Ian had in mind in https://bugzilla.redhat.com/show_bug.cgi?id=802003#c12. On the other hand, the fix influences some of our key plugins - AS4, AS5 and Tomcat so I am a little bit afraid of pushing this into a JON release without any baking time in RHQ. The fixes in bug 802003 are only included in the yet unreleased RHQ 4.5.0 codebase. Also, there is currently no test coverage for the changes (nor is there much of it for the JMX plugin as a whole).
Charles, what do you think?
This is in RHQ for a year and at least 3 releases without negative feedback.
Re-opening. This must optional go through QE and then be set to VERIFIED so we get it documented in the release notes. The fact that it was fixed long ago is not relevant as we have not documented the fix or that a fix was actually released. If this was documented in a previous product release then we need to set the target to the release that it was documented as fixed.
Moving into ER3 as didn't make it into ER2.
I was able to inventory Tomcat 7 without any exceptions with ER5.