Bug 1025756

Summary: Server log warnings from CriteriaQueryRunner, Could not initialize
Product: [Other] RHQ Project Reporter: Jay Shaughnessy <jshaughn>
Component: Core ServerAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.9CC: 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
From Heiko e-mail thread:

Hey,
I saw the below fly by in the server log :

12:04:44,258 WARN [org.rhq.enterprise.server.util.CriteriaQueryRunner]
(http-/0.0.0.0:7080-6) Could not initialize private
org.rhq.core.domain.alert.AlertDefinition
org.rhq.core.domain.alert.Alert.recoveryAlertDefinition

Attaching with a debugger shows that seems to come from the recently
fired alerts portlet and internally from
org.rhq.enterprise.server.util.CriteriaQueryRunner#initialize

Comment 1 Jay Shaughnessy 2013-11-01 13:25:55 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...

Comment 2 Jay Shaughnessy 2013-11-01 17:52:19 UTC
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.

Comment 3 Heiko W. Rupp 2014-04-23 12:31:16 UTC
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.

Comment 4 Larry O'Leary 2014-06-12 20:29:09 UTC
*** Bug 1000999 has been marked as a duplicate of this bug. ***