Description of problem: Since the change to straight serialization, the AvailabilityReport has added some girth. It now sends the full attached Resource object and a lot of other stuff along with any reported availability to the server. This means a full availability report can now easily exceed a MB. The fix is to send only the necessary info of avail information and the resourceId to attach it to. Patch to follow. Version-Release number of selected component (if applicable): 4.0 dev series How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 454905 [details] A patch to greatly reduce amount of unnecessary data sent in avail reports This patch adds a new report object to send agent to server instead of the real Availability object.
Created attachment 455622 [details] code review for 1st patch submission
commit 9304ba488341b487d00d3d180276525ad81cd0fe Author: Joseph Marques <joseph> Date: Thu Nov 11 18:57:36 2010 -0500 BZ-645502: re-introduce AvailabilityReport customized serialization for performance (cherry-pick of commit 42c2d3e) * replace payload List<Availability> with List<AvailabiltyReport.Datum> * agent-side calls to getResourceAvailability() need to perform lookups for the corresponding ResourceContainer to print additional data * server-side calls to getResourceAvailability() need to translate back to List<Availability> with an attached fly-weight resource to mirror the previously existing method semantics misc: * remove no-arg constructor for AvailabilityReport, which used to be needed to satisfy the Externalizable interface * remove commented out readExternal/writeExternal methods * add toString() method for AvailabilityReport.Datum, which was needed as part of the toString() impl for AvailabilityReport itself note: * specifically did not add override for equals(Object) in Datum because it's only needed in InventoryManager.handleReport(AvailabilityReport) where Collection.remove() is called; the default reference-equals should suffice
There are a couple things to test: 1) while the system is in steady that, that there aren't any exceptions in either the agent log or server log that indicate serialization issues when dealing with availability data 2) start the agent with the interactive console, and force an availability report to be sent up to the server. first test by sending a partial report, then test by sending a full report. both of these should complete successfully without any exceptions bring printed to the agent log or server log that indicate serialization issues for availability data 3) take the agent down and wait 5-10 minutes for the suspect agent job to trigger. this will come along and mark all resources managed by that agent as down. all resources managed by that agent should be marked down/red in the web UI, and there should be no exceptions in the server log concerning execution of this job.
Removing blocker against the jon 241 version of this bug
Verified on build#1143 (Version: 4.0.0-SNAPSHOT Build Number: 90254fb) While the system is in steady, no serialization exceptions are observed in the agent log or server log. At agent prompt command issued command 'avail -c' to get a report based on changed status of resources. Executed 'avail' command and observed that both commands are completed successfully without any exceptions to the agent log or server log. Executed 'shutdown' at agent prompt command. The agent got down. Waited for the agent job to trigger. All managed resources are marked down/red in the web UI, and there are no exceptions in the server log. Marking the bug as verified.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.