Hudson-build log growing extremely fast....
RTC 4.0.3
Just received an alert on the file system that contains our CLM install ( hit 90% threshold ). This caught my eye because it rarely happens. So I do a quick du -sg * |sort -n to find where the space is getting used. It's in server/tomcat/temp/hudson-build-biglongstringofdigits.log Which has grown 1g since I noticed it. It is puking lines like this: [junit-tririga] [MID-3309500079] [junit-tririga] 2014/02/10 03:39:13 - PreparedStatementCallback; SQL [INSERT INTO HEARTBEAT_EVENT_QUEUE (EVENT_ID,EVENT_TYPE, HOSTNAME, DATA) VALUES (?,?,?,?)]; ORA-00001: unique constraint (DEV_UNIT_TEST.PK_HEARTBEAT_EVENT_QUEUE) violated [junit-tririga] ; nested exception is java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (DEV_UNIT_TEST.PK_HEARTBEAT_EVENT_QUEUE) violated [junit-tririga] [MID-3309500079] [junit-tririga] 2014/02/10 03:39:13 - PreparedStatementCallback; SQL [INSERT INTO HEARTBEAT_EVENT_QUEUE (EVENT_ID,EVENT_TYPE, HOSTNAME, DATA) VALUES (?,?,?,?)]; ORA-00001: unique constraint (DEV_UNIT_TEST.PK_HEARTBEAT_EVENT_QUEUE) violated [junit-tririga] ; nested exception is java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (DEV_UNIT_TEST.PK_HEARTBEAT_EVENT_QUEUE) violated [junit-tririga] [MID-3309500079] Q: How can this be squelched ? There is an overdue build in the RTC Project. |
One answer
What is the use of primary key DEV_UNIT_TEST.PK_HEARTBEAT_EVENT_QUEUE during the build? Google only points it to this post so I suppose it's unique to your environment and it's not something common to the CLM environment. I believe the build log is flooded with the same error and you have to find out why a duplicate key is being inserted into a Oracle table. Probably the build is overdue because of the same reason (it will never get built unless you resolve the duplicate key issue).
Comments I have enlisted the help of what I think is the affected Project Area admins to help flush this out.
Kevin filed work item Hudson spews 15g+ log in less than 15h. (307787) to track this. It turned out that the Jenkins build itself was generating such a large log. I've filed enhancement Hudson/Jenkins and other integrations should impose a limit on the size of log files (308795) to improve the handling of this situation on the RTC side. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Ok, let's freshen this question.... Now @ 4.0.5 and hudson build log was
-rw------- 1 wassrvr wasadm 0 Mar 15 04:37 sprite2992387446375690945.png
-rw------- 1 wassrvr wasadm 0 Mar 15 05:57 sprite4870140469207551151.png
-rw------- 1 wassrvr wasadm 15,583,294,673 Mar 15 07:55 hudson-build-2419919301820770169.log
That's OVERNIGHT. I really need to know how to bit-bucket these logs on the RTC host.