Bug 1025756 - Server log warnings from CriteriaQueryRunner, Could not initialize
Server log warnings from CriteriaQueryRunner, Could not initialize
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: RHQ 4.10
Assigned To: Jay Shaughnessy
Mike Foley
: 1000999 (view as bug list)
Depends On:
Blocks: 1108912
  Show dependency treegraph
Reported: 2013-11-01 09:24 EDT by Jay Shaughnessy
Modified: 2014-06-12 16:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1108912 (view as bug list)
Last Closed: 2014-04-23 08:31:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jay Shaughnessy 2013-11-01 09:24:08 EDT
From Heiko e-mail thread:

I saw the below fly by in the server log :

12:04:44,258 WARN [org.rhq.enterprise.server.util.CriteriaQueryRunner]
(http-/ Could not initialize private

Attaching with a debugger shows that seems to come from the recently
fired alerts portlet and internally from
Comment 1 Jay Shaughnessy 2013-11-01 09:25:55 EDT
> 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 13:52:19 EDT
master commit 29d66b177657a37fc126304408da49210c22a063
Author: Jay Shaughnessy <jshaughn@redhat.com>
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 08:31:16 EDT
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 16:29:09 EDT
*** Bug 1000999 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.