see AvailabilityExecutor - don't always sendResourceError in the catch if (resourceContainer.getResourceComponentState() == ResourceComponentState.STARTED) { current = resourceComponent.getAvailability(); } else { this.inventoryManager.activateResource(resource, resourceContainer, false); if (resourceContainer.getResourceComponentState() == ResourceComponentState.STARTED) { current = resourceComponent.getAvailability(); } } } catch (Throwable t) { ResourceError resourceError = new ResourceError(resource, ResourceErrorType.AVAILABILITY_CHECK, t, System.currentTimeMillis()); this.inventoryManager.sendResourceErrorToServer(resourceError); // TODO GH: Put errors in report, rather than sending them to the Server separately. if (log.isDebugEnabled()) { if (t instanceof TimeoutException) // no need to log the stack trace for timeouts... log.debug("Failed to collect availability on resource " + resource + " (call timed out)"); else log.debug("Failed to collect availability on resource " + resource, t); } }
ghinkle checked in svn rev 4810 that makes the sendResourceError NOT guaranteed - so it won't be sent again if it fails
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2285
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
Do we even want to support this type of ResourceError going forward? I may be wrong, but I don't recall ever seeing this type of information in the server anywhere - we just show the latest AvailabilityType and availability history instead for each resource. The only type of ResourceError we actually propagate to the UI is the one for plugin configuration errors. In the last few weeks, we now support resource upgrade error types as well. Unless there is a good reason to keep this kind of error, and unless we actually want to show that error somewhere in the UI (and does that mean that the message should be guaranteed?), then I vote to get rid of it. Mazz, thoughts?
we can get rid of this
we actually do show this in the new GWT interface now. this isn't a problem anymore. one final glitch is being fixed via BZ 664126. but now we can show issues with avail resource errors.