Description of problem: This bug is really an extension of bug 235108. With that bug we found that there was an incorrect association mapping between the Server and CPU classes. Further investigation revealed for the association mappings in Server with Ram and Dmi. The issue manifests itself in the HQL query, Server.findByIdAndOrgId which is defined in Server_legacyUser.hbm.xml. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Find a server with multiple entries in the table rhnRam. 1.a. Find a server multiple entries in the table rhnServerDmi. 2. Run the HQL query Server.findByIdAndOrgId. 3. Actual results: See Comment 2 in bug 235108. It provides a stack trace. Expected results: No exceptions should be thrown. Additional info:
There are a very small number of servers that have multiple rows in rhnRam and or rhnServerDmi. It has been concluded that servers should not have multiple rows in either of these tables. For those servers that do have multiple rows, it should be treated as an error. Two things probably need to be done. 1) Remove bad data from the database. 2) Make our Hibernate error handling more robust. Currently, we almost always propagate a HibernateException up the call stack and the user winds up seeing an ISE. We need to recover from errors when possible and report/log more intelligible error messages when and where possible. Both of these items are probably beyond the scope of 501.
Has this hit webdev yet?
The hibernate mappings for rhnServerDmi and rhnRam are in fact correct. We have concluded that the few servers that have multiple rows in these tables have erroneous data. These extra rows need to be purged from the database. Bret, in our last conversation about this, you mentioned that we could do this at any time. Can we move this off of 501h-must since it is not a high priority issue?
John, we'll align this to rhn502; once the script is done and you're happy with it, we can fast-track it through the various env's.
There are currently 15 servers with >1 DMI entry, 88 with >1 CPU, and 90 with >1 RAM entry. It looks like the extras are duplicates of each other. A script that deleted all but one of the dups, however we did that, would likely be sufficient. Currently, any/all of the systems affected by this will throw an ISE if you attempt to visit their SDC pages. As an example - ... Caused by: com.redhat.rhn.common.hibernate.HibernateRuntimeException: Executing query Server.findByIdandOrgId with params {orgId=779013, sid=1000122758} failed ... Caused by: org.hibernate.HibernateException: More than one row with the given identifier was found: 1000122758, for class: com.redhat.rhn.domain.server.Ram So - right now, we need to fix up the data, regardless of whatever other work we do, it looks like.
moving these to rhn505-triage until we can re-examine for rhn503+
I'm using 237898 as the master BZ for tracking this problem - closing this one as adup *** This bug has been marked as a duplicate of 237898 ***
*** Bug 579491 has been marked as a duplicate of this bug. ***