Simplify SubprocessReportGenerator #359
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, subprocessed report generation was triggered by either the
ActiveRecordingReportCache
orArchivedRecordingReportCache
. TheActiveRecordingReportCache
would provide a description of the target (connection URL and any credentials) and the recording name, and theArchivedRecordingReportCache
would provide a local filesystem URI to a recording file already on-disk. The subprocess would then determine which it was provided at run time and either directly process the archived recording into a report, or set up its own connection toolkit and connection manager, then connect to the target application directly, copy the recording stream to a file, and then proceed to process it and generate a report. Then the report is written to a file and the subprocess shuts down.This was needlessly complex for the subprocess and required a bit of a hack to pass an already-saved archived recording file path to the subprocess as it it were a targetId, and then the subprocess has to check for this special case.
This PR refactors the flow so that the parent process is responsible for providing the subprocess with a path to a recording on disk in all cases. If the caller is the
ArchivedrRecordingReportCache
then this is already taken care of and the path is simply passed in. If the caller is theActiveRecordingReportCache
then it calls through to a utility method which uses the parent process' existing connection manager to copy the recording data into a local file, and then proceeds to pass the path to that file to the subprocess. The subprocess then always expects to be provided with consistent arguments - the path to the recording on disk, and the path where it should write the report.This also removes the need for the subprocess to handle establishing a JMX connection, or handling SSL/TLS certs for this connection, or handling JMX authorization credentials, etc., and should also reduce overall request->response latency for report requests since the parent process' target connection can be reused for retrieving the report (if necessary), a cached DNS entry for the target can be used if any lookup is needed, etc.