Skip to content
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

Merged
merged 4 commits into from
May 15, 2020

Conversation

reddyashish
Copy link
Contributor

@reddyashish reddyashish commented May 13, 2020

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

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.

Reviewers

@DynamoDS/dynamo

This is to avoid storing these large number of logs on the VM which is affecting its performance over time.
@reddyashish reddyashish changed the title Write logs to std out instead of creating new files for each test. [DYN-2680] Write logs to std out instead of creating new files for each test. May 13, 2020
@@ -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)
Copy link
Collaborator

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.

Copy link
Collaborator

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

Copy link
Member

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.

Copy link
Contributor Author

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;
}
Copy link
Collaborator

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?

Copy link
Contributor Author

@reddyashish reddyashish May 13, 2020

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.

Copy link
Collaborator

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.
@reddyashish
Copy link
Contributor Author

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
});
Copy link
Collaborator

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?

Copy link
Contributor Author

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"));
Copy link
Collaborator

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.

Copy link
Contributor Author

@reddyashish reddyashish May 14, 2020

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).

Copy link
Member

@mjkkirschner mjkkirschner left a 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());
Copy link
Member

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!

Copy link
Member

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!

Copy link
Contributor Author

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.

@reddyashish
Copy link
Contributor Author

Merging this.

@reddyashish reddyashish merged commit 888face into DynamoDS:master May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants