Description of problem: By default we do not want to store binary content on the server. Remediation is not going to be available in JON 3.0; so, we do not really need binary content on the server since there is not anything we can do with it. This also serves as a safeguard to protect users from accidentally saturating network bandwidth or filling up disk space on the database server. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Added logic to exclude binary content by default. Binary content can be stored by setting the property rhq.server.drift.store-binary-content to true in the rhq-server.properties file. master commit hash: 1495d03f65e30eef1f533d90ee4c8b434282f790 release_jon3.x commit hash: abab0d45276feec10db95c4202b2f0ba4f61acb0
okay ... i see this failing in this build ... https://hudson.qa.jboss.com/hudson/view/JON3%20Core/job/rhq-release-gwt-locales/24/ retest tomorrow or in a later build
this is verified ... no binary data is being stored. however, i still see the link to view "Old File" ... * bkramer has quit (Quit: Leaving) <mfoley> jsanda: question on https://bugzilla.redhat.com/show_bug.cgi?id=757758 <mfoley> jsanda: it is about drift and binary files <mfoley> i don't see that we are storing the binary data anymore ... so that is working <mfoley> however ... i still see the link to view the data for "Old File" * siamak has quit (Ping timeout: 615 seconds) <jsanda> mfoley: that bz doesn't involve the changes for viewing 'Old File' for binary files <mfoley> k <mfoley> just checking
(4:22:00 PM) jshaughn: I'm seeing an issue now that jsanda_bbl also saw just a little while ago (4:22:12 PM) jshaughn: and it may be related to the binary content filtering (4:22:22 PM) ccrouch: rats (4:22:57 PM) jshaughn: john said he wanted to look at this again later. there may be a badness in drift (4:26:59 PM) ccrouch: jshaughn: is drift completely blown out of the water with the issue you are referring to? (4:27:09 PM) ccrouch: jshaughn: or just some use cases? (4:27:34 PM) jshaughn: not sure, it seems at times now drift file storage is bombing
re-opening per jshaughn comment <jshaughn> not sure, it seems at times now drift file storage is bombing setting status to urgent. should block drift and sprint#9
Here is the actual exception we are seeing, 2011-11-30 07:05:38,984 INFO [org.rhq.enterprise.server.drift.JPADriftServerBean] Skipping bad drift file javax.ejb.EJBException: java.lang.IllegalArgumentException: JPADriftFile not found [eec86c6712976844ffe31411c982fc7b6aa6d4e89b6c759273cf6c888872efb1] After some more investigation, I do not believe that this issue is not related to the binary content filtering changes. I reverted JPADriftServerBean.java back to the version before the content filtering changes and have still been able to reproduce this exception. I will open a separate bug with full details around when this is happening as well as steps to reproduce.
I am re-targeting this for JON 3.1.2 as it was originally a blocker for a previous release. Not sure how we released JON 3.1 without fixing this or at least updating the results of the investigation. What's the status? It appears there should be another bug to track the new issue and it is unrelated to the original change here? Can we confirm and close this bug if that's the case?
The exception that I reported in comment 6 is from a year ago. Have any customers hit this or has QE been able to reproduce in any of their testing since then? If the answer is no then I think we can close this out. I have spent some time reviewing the code, and I have come up with one possible explanation, albeit an unlikely one. The agent sends a change set report to the server. That change set report is persisted as well as any instances of JPADriftFile as necessary. The server subsequently sends a different request to the agent asking for content referenced in the change set report that is not already in the database. The agent sends that content back to the server in a separate request. If before the server receives that change set content, the drift definition is deleted and then the data purge job runs, rows in the rhq_drift_file table would get purged. This would result in the exception reported in comment 6. Like I said, this is pretty unlikely since the data purge job runs hourly; however, it is possible.
As per comment 3, this issue has been fixed and verified in JON 3.0. The new issue mentions by jshaughn as indicated in comment 5 was not related to this change as per comment 6 and therefore, this issue is still VERIFIED. If the new issue identified during testing this issue is still a problem, a new bug should be filed against a later release. Closing as it is in current release and resetting target release to JON 3.0 seeing that is where this originally came from and was tested.