Bug 721281

Summary: [RFE] Removing "ORA-00001: unique constraint (JON.RHQ_PACKAGE_VERSION_IDX) violated" from the log file in normal working conditions
Product: [Other] RHQ Project Reporter: bkramer <bkramer>
Component: ContentAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: high    
Version: 3.0.1CC: hrupp, mazz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 625146    

Description bkramer 2011-07-14 04:26:18 EDT
Description of problem:

Customer has fresh Oracle, JON Server (2.4.1) and JON Agents installations and after some time the following ERROR is logged:

2011-07-11 19:08:02,919 WARN  [org.hibernate.util.JDBCExceptionReporter] SQL Error: 1, SQLState: 23000
2011-07-11 19:08:02,919 ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-00001: unique constraint (JON.RHQ_PACKAGE_VERSION_IDX) violated

2011-07-11 19:08:02,919 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update

This is followed by:

2011-07-11 19:08:02,939 WARN  [org.rhq.enterprise.server.content.ContentManagerBean] There was probably a very big and ugly EJB/hibernate error just above this log message - you can normally ignore that. We detected that a package version was already created when we tried to do it also - we will ignore this and just use the new package version that was created in the other thread

AS explained in: https://bugzilla.redhat.com/show_bug.cgi?id=536070 the above error messages can be ignored. However, it doesn't look good to have all those ERRORs logged in the log file under normal conditions.

Looking at https://bugzilla.redhat.com/show_bug.cgi?id=536070#c9 it seems that there is nothing we can do at the moment to change this but we should try to get rid of them (in case when everything works fine) in a future. 


Version-Release number of selected component (if applicable):
JON 2.4.1
Comment 1 Charles Crouch 2011-07-25 13:52:25 EDT
Lets review if this is still intractable
Comment 2 John Mazzitelli 2011-11-16 15:18:28 EST
there isn't much we can do here because the exception is logged by hibernate.

This code needs to be executed fast (because this potentially is storing logs of packages) so we don't want to run into problems slowing down by doing a "check the DB if it exists, if not, THEN persist". We just persist and if we hit problems, we see if its not "really" a problem at that point. Besides, if we do the "check if it exists, if not, persist" we STILL aren't guaranteed that it will work - due to the multi-threadedness, we could concurrently have committed a new package after the if check but before the persist so the same issue occurs.

To avoid seeing the log messages, we'd have to turn that category off in log4j (in that case, we never see those errors if they legitimately happen elsewhere in the code) or we'd have to somehow refactor this code to avoid persisting a package version that was concurrently committed but yet not slow things down.

In my opinion, this is a low priority, low severity issue.