Red Hat Bugzilla – Bug 1025756
Server log warnings from CriteriaQueryRunner, Could not initialize
Last modified: 2014-06-12 16:31:25 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-/0.0.0.0:7080-6) Could not initialize private
Attaching with a debugger shows that seems to come from the recently
fired alerts portlet and internally from
> 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
> 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
... will implement option 2, although option 3 may be something we should look at in the future...
master commit 29d66b177657a37fc126304408da49210c22a063
Author: Jay Shaughnessy <firstname.lastname@example.org>
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. ***