-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DYN-2680] Write logs to std out instead of creating new files for each test. #10651
Conversation
This is to avoid storing these large number of logs on the VM which is affecting its performance over time.
@@ -157,7 +157,7 @@ public IEnumerable<NotificationMessage> StartupNotifications | |||
/// </summary> | |||
/// <param name="debugSettings">Debug settings</param> | |||
/// <param name="logDirectory">Directory path where log file will be written</param> | |||
public DynamoLogger(DebugSettings debugSettings, string logDirectory) | |||
public DynamoLogger(DebugSettings debugSettings, string logDirectory, Boolean IsTestMode = false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we used chained constructors instead? Optional parameters require a client recompile, so technically this is a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: The parameter name should start with lower case: isTestMode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I finally found an official version of this:
https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/breaking-change-rules.md
but It does not seem as comprehensive as:
https://stackoverflow.com/questions/1456785/a-definitive-guide-to-api-breaking-changes-in-net
please review it whenever making changes to public apis.
relevant section:
Adding a parameter with a default value.
though it requires careful reading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes will be changing this to an overloaded constructor. I tried to look if adding a optional parameter is a good design or not for public API's but that link is really comprehensive
{ | ||
Console.WriteLine(string.Format("{0} : {1}", DateTime.UtcNow.ToString("u"), message)); | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just leverage on the existing code for the console logging by setting the level
variable to LogLevel.Console
if testMode
is true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The LogLevel.Console is configured to write to both the dynamo console and to the log file. So couldn't use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are indeed right. The fact that it does both things having that name is confusing :)
These tests verify that the logs are written to dynamo console and to a file. When we changed the behaviour to write the logs to std out in test mode, there were failing. Fixed them accordingly.
Fixed a couple of existing tests. These tests verify that the logs are written to dynamo console and to a file. When we changed the behaviour to write the logs to std out in test mode, they were failing. Fixed them accordingly. |
CorePath = config.DynamoCorePath, | ||
HostPath = config.DynamoHostPath, | ||
PathResolver = config.PathResolver | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to confirm, these params were not needed, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, these were null values.
Assert.IsTrue(File.Exists(currentLoggerPath));//Check that the log was created successfully | ||
Assert.IsTrue(CurrentDynamoModel.Logger.LogText.Contains("migration from 0.5.3.x to 0.6.1.x"));//Checks that the log text contains the migration info | ||
//Checks that the console output text contains the migration info | ||
Assert.IsTrue(consoleOutput.Contains("migration from 0.5.3.x to 0.6.1.x")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe for this test we actually want to use the non-test version of the logger? I'm thinking that having a persistent log after a migration is done is desired and should be tested to exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing is, the dynamo logger is created from the dynamo model when the dynamo model is initialized from the tests. It is a read only property and we cannot create an instance of logger in non test mode here, then add it to the model(only then this log message will be written to a file).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please check if this should be disposed. Since the logger is created with each test it could introduce a leak.
|
||
consoleOutput = stringWriter.ToString(); | ||
|
||
StreamWriter sw = new StreamWriter(Console.OpenStandardOutput()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should you call dispose on StreamWriter? I believe it implements IDisposable!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, looked too quickly, didn't see this was one test, not the logger!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can avoid creating the StreamWriter object. Saving the std out beforehand and setting it back.
Merging this. |
Purpose
This PR is in reference to the task: https://jira.autodesk.com/browse/DYN-2680.
In the current design, a log file is created everytime dynamo is started and closed. So during a test run on the VM, around 5000-10000 logs are created. Over time, this is causing performance issues on the VM. We are not using these logs anyways so it is better to avoid it.
After this change, during tests, we write the logs only to std out instead of file or to dynamo console.
Declarations
Check these if you believe they are true
*.resx
filesReviewers
@DynamoDS/dynamo