Errors like the following have been seen as the result of AS5 package discovery. 23:18:12,431 ERROR [JDBCExceptionReporter] Batch entry 0 insert into RHQ_PACKAGE_VERSION (PACKAGE_ID, DISPLAY_NAME, SHORT_DESCRIPTION, LONG_DESCRIPTION, VERSION, DISPLAY_VERSION, ARCHITECTURE_ID, FILE_NAME, FILE_SIZE, FILE_MD5, FILE_SHA256, FILE_CREATION_TIME, LICENSE_NAME, LICENSE_VERSION, METADATA, CONFIG_ID, PACKAGE_BITS_ID, ID) values ('10101', NULL, NULL, NULL, '5.0.0.GA (5.0.0.GA (build: SVNTag=JBPAPP_5_0_0_GA date=200910202128)) [sha256=55efb4677fb743fa8101e6fce18ed4a12312ef30a18a1fa2d47d6062bfa63359]', NULL, '1', 'jboss-xa-jdbc.rar', '15420', NULL, '34356cbf35b5a85b6ff723e7f62b464a8834ceb5b572c8d8c4d8c25fcaee266c', NULL, NULL, NULL, NULL, NULL, NULL, '10097') was aborted. Call getNextException to see the cause. 23:18:12,431 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 23505 23:18:12,432 ERROR [JDBCExceptionReporter] ERROR: duplicate key value violates unique constraint "rhq_package_version_idx" This relates to the work in https://bugzilla.redhat.com/show_bug.cgi?id=596704 NOte that the sha256 in the version string is different than the sha256 in the sha256 field. This can only happen (afaics) if the version is pulled from the "application versions store". this is a filestore of filename-to-version string mappings maintained by the plugin. I need to know more about this store, it looks like it may have issues with stale data. So, filename of the package is in the store, associated to a version string that was generated from a different binary with the same name. We pull the bad version string and use it with the real sha256 for this binary.
This is not super easy to QA. In short, if you have multiple AS5 servers in inventory, particularly if you have a 5.0.0 and a different supported version, say 5.0.1, and you don't get any of these errors, then you're probably good to go.
commit 2d0df150841d9adcba5ac4e1dd470776dc99fbce Remove from the AS/AS5/Tomcat plugins the approach of a file-based cache mapping filename-to-version for packages. This is one, unnecessary and two, doesn't work as you can't guarantee version based on filename at plugin granularity. This should solve [BZ 602538] but goes further to clean up all three plugins using the bad approach.
The testing of this is blocked by bug 607932.
Verified on JON 2.4 GA_QA (tag-jon-release build #46) Revision: 10759 Steps: 1) Installed JON 2.4 GA_QA (tag-jon-release build #46) and agent on RHEL 5.5 with Postgres 8.4 and Sun JDK1.6 2) Installed JBossAS 5.0 and JBossAS 5.1 (with different port) on agent box Observation: JBossAS 5.0 and JBossAS 5.1 auto discovered without error/exception.
Mass-closure of verified bugs against JON.