Bug 699542

Summary: Intermittent Serialization issues with Hibernate types
Product: [Other] RHQ Project Reporter: Jay Shaughnessy <jshaughn>
Component: Core UIAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: medium    
Version: 4.0.0.Beta2CC: hrupp
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: 4.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-02 07:28:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 585306, 712192    
Attachments:
Description Flags
trace I'm getting none

Description Jay Shaughnessy 2011-04-25 21:52:24 UTC 
Somewhat related to BZ 688000 but not really the same, I think.

I can unreliably reproduce Serialization issues where it looks like HibernateDetachUtility fails to properly scrub return data.  This happens typically in the ConfigUpdate report, abouy 5% of the time it renders for me.

It seems to get triggered by the Configuration attached to a Postgres Table resource.  This resource does declare a "List of Maps", which is a PropertyList such that each List entry is a PropertyMap.

Just because this is triggered in my current inventory by this Postgres type, I believe this is probably a more general issue that could get triggered in various ways.
Comment 1 Jay Shaughnessy 2011-04-25 21:53:03 UTC 
Created attachment 494766 [details]
trace I'm getting
Comment 2 Jay Shaughnessy 2011-04-27 00:36:02 UTC 
commit 9fa27ab58dfd8ce9eb94e346ada11a96620c2e96
Author: Jay Shaughnessy <jshaughn>
Date:   Tue Apr 26 17:48:07 2011 -0400

This is a fix that I think solves the issue. It introduces changes and logging that indicate that a potential problem in HibernateDetachUtility has been identified and avoided. In short we treated System.identityHashCode() as if it guaranteed unique values, which it may not.  We now handle the situation where the identity hash may in fact not be unique among the set of objects being scrubbed.

The logging will be tuned down in a subsequent commit but for now dumps out the objects that have the same hash but are not the same.

Test Notes: This is not simple to test as the problem is dependent on Inventory and is intermittent.  But it was best reproducible with Databases in inventory, like the RHQ database, because the Table resources have "List of Map" configuration.  The reports->configuration update report would occasionally show the issue.  Banging in this report, with databses in inventory, refreshing, etc is one way to try and reproduce.  If no exceptions are thrown then that is about the best we can do to verify.
Comment 3 Mike Foley 2011-06-07 13:57:20 UTC 
verification will occur as part of the performance/load effort ... now beginning....
Comment 4 Mike Foley 2011-08-15 14:21:31 UTC 
i have not seen this issue in 2 months time.
Comment 5 Heiko W. Rupp 2013-09-02 07:28:06 UTC 
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.