Bug 1025756
Summary: | Server log warnings from CriteriaQueryRunner, Could not initialize | |||
---|---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Jay Shaughnessy <jshaughn> | |
Component: | Core Server | Assignee: | Jay Shaughnessy <jshaughn> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 4.9 | CC: | hrupp, kupo, loleary, pyadav | |
Target Milestone: | --- | |||
Target Release: | RHQ 4.10 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1108912 (view as bug list) | Environment: | ||
Last Closed: | 2014-04-23 12:31:16 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1108912 |
Description
Jay Shaughnessy
2013-11-01 13:24:08 UTC
> OK, this is not directly related to recovery alert definitions. It's > producible just using alerts that *don't* have a recovery alert def > associated. Meaning, your everyday, typical alerts. When we perform the > recent alerts query in the portlet (see > AbstractRecentAlertsPortlet.AlertsPortletDataSource.getFetchCriteria()) we > pull the optional data for the recovery alert definition > (criteria.fetchRecoveryAlertDefinition(true)). > As an aside, it's not immediately clear why we do this because on casual > inspection it's not used. > Anyhow, the issue is that this QueryCriteriaRunner code now tries to hydrate > requested hibernate proxies into entities (Hibernate.initialize) but in this > case the proxy is wrapping nothing. i.e., the recovery AlertDefinition id is > 0 because there is no recovery alert def. The fact that this happens is very > unusual. It's due to the fact (for reasons that I'm sure are obscure) that > this field is not nullable. Meaning we set it to 0 as opposed to letting it > be null in the DB. So the entity actually gets a proxy for nothing as > opposed to the typical null value. > The code doesn't die, it generates a WARN in QueryCriteriaRunner.initialize() > because it does not expect to have a problem hydrating the proxy. But this > will be very disconcerting in the logs, as the portlet will generate the > warnings on every refresh when there are alerts. > We have a few options: > 1. guard against the 0 id case and don't try to hydrate (may be slightly > tricky as we'd have to play with a proxy object) > 2. catch and ignore (or log.debug) EntityNotFoundException on hydrate (and we > should likely set the field null here as well, if possible) > 3. change Alert.recoveryAlertDefinition to be optional (may be OK but an > entity change seems risky of regression due to unknown deps) > 4. look the other way and just change the portlet criteria to not ask for > this optional data (would need to make sure we don't need it) > 5. maybe others? > Right now I'd recommend option (2). If for whatever reason we can't hydrate > the entity field because it's not found, I think we should log as debug and > continue. Any other exception we could catch and handle as a warn, like > today. ... will implement option 2, although option 3 may be something we should look at in the future... master commit 29d66b177657a37fc126304408da49210c22a063 Author: Jay Shaughnessy <jshaughn> Date: Fri Nov 1 13:46:35 2013 -0400 Handle the case where we have a required, lazy-loaded entity that may be set to 0. We shouldn't do that, but we do. Bulk closing of 4.10 issues. If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10. *** Bug 1000999 has been marked as a duplicate of this bug. *** |