Bug 699542 - Intermittent Serialization issues with Hibernate types
Summary: Intermittent Serialization issues with Hibernate types
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.0.0.Beta2
Hardware: All
OS: All
medium
high
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: rhq4 712192
TreeView+ depends on / blocked
 
Reported: 2011-04-25 21:52 UTC by Jay Shaughnessy
Modified: 2013-09-02 07:28 UTC (History)
1 user (show)

Fixed In Version: 4.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-02 07:28:06 UTC
Embargoed:


Attachments (Terms of Use)
trace I'm getting (12.96 KB, text/plain)
2011-04-25 21:53 UTC, Jay Shaughnessy
no flags Details

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.


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