Bug 1108912 - Server log warnings from CriteriaQueryRunner: could not initialize recoveryAlertDefinition when viewing recent alerts portlet
Summary: Server log warnings from CriteriaQueryRunner: could not initialize recoveryAl...
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Core Server
Version: JON 3.2.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: DR01
: JON 3.3.0
Assignee: Jay Shaughnessy
QA Contact: Mike Foley
Depends On: 1025756
TreeView+ depends on / blocked
Reported: 2014-06-12 20:20 UTC by Larry O'Leary
Modified: 2018-12-05 18:51 UTC (History)
3 users (show)

When the Recent Alerts dashboard portlet loaded the alert history, it also attempted to load the alerts corresponding recovery alert. If the alert did not have a recovery alert, a "could not initialize recoveryAlertDefinition" WARN level log entry was appended to server.log. This message was incorrectly classified as a WARN log message, and customers were unsure what action needed to be taken to correct the issue. The fix to the Recent Alerts dashboard portlet catches and ignores any EntityNotFoundException instances, which fixes the originally-reported issue.
Clone Of: 1025756
Last Closed: 2014-12-11 14:00:15 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 727573 None None None Never

Description Larry O'Leary 2014-06-12 20:20:24 UTC
This issue was reported in JBoss ON 3.2 update-01. We need to get this fix in 3.3 and verified.

+++ This bug was initially created as a clone of Bug #1025756 +++

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

--- Additional comment from Jay Shaughnessy on 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...

--- Additional comment from Jay Shaughnessy on 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.

--- Additional comment from Heiko W. Rupp on 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 1 Simeon Pinder 2014-07-31 15:52:18 UTC
Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993

Comment 3 Jay Shaughnessy 2014-10-29 13:12:38 UTC
Jared, this comment is fine.  Thanks.

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