Red Hat Bugzilla – Bug 699542
Intermittent Serialization issues with Hibernate types
Last modified: 2013-09-02 03:28:06 EDT
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.
Created attachment 494766 [details]
trace I'm getting
Author: Jay Shaughnessy <firstname.lastname@example.org>
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.
verification will occur as part of the performance/load effort ... now beginning....
i have not seen this issue in 2 months time.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.