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

Provide mechanism to flush background queue of log messages #211

Open
1 of 2 tasks
normj opened this issue Oct 26, 2022 · 0 comments
Open
1 of 2 tasks

Provide mechanism to flush background queue of log messages #211

normj opened this issue Oct 26, 2022 · 0 comments
Labels
feature-request A feature should be added or improved. module/logging p2 This is a standard priority issue queued

Comments

@normj
Copy link
Member

normj commented Oct 26, 2022

Describe the feature

Developers that use this library in Lambda have the issue that log messages queued in the background queue don't get processed before the Lambda function is complete and the Lambda compute container is frozen. If no more Lambda events are sent to the Lambda compute container then those log messages are lost.

To ensure all messages are sent before the Lambda function finish processing an event provide a method from AWS.Logger.Core that developers can call to flush the queue.

This is the issue that inspired me to write this feature request but is far from the first to callout the limitations of these libraries in Lambda.
#204

Use Case

Developers want to use these logging libraries in Lambda because they want their log messages to go to their own log groups. Currently we don't recommend using these libraries in Lambda due to the background processing nature but there is clearly a demand for doing this based other GitHub issues. We should provide them a flushing mechanism to make it work. It does mean that developers will have to wait finishing their Lambda event being processed till the messages are pushed to CloudWatch Logs.

Proposed Solution

For every logging output in each of our supported plugins there is an instance of AWSLoggerCore created to manage the background processing queue. Most cases there will only be one instance of AWSLoggerCore but it is possible there could be multiple instances. For example developers could configure info messages to go to one target and error messages to go to another target. Consumers of any of our plugin libraries have no direct access to the instance of AWSLoggerCore.

We need to maintain a registry of every instance created. Basically whenever the constructor of AWSLoggerCore is called add it to some static registry. Whenever the Close method is called remove the instance from the registry. Then somewhere in core package provide a public static method that triggers a flush on all registered instances of AWSLoggerCore. This flush should take in a timeout so we don't get stuck flush indefinitely.

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

AWS .NET SDK and/or Package version used

Latest

Targeted .NET Platform

.NET Core 3.1 and .NET 6

Operating System and version

Linux

@normj normj added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Oct 26, 2022
@ashishdhingra ashishdhingra added module/logging and removed needs-triage This issue or PR still needs to be triaged. labels Oct 26, 2022
@ashishdhingra ashishdhingra added the p1 This is a high priority issue label Dec 8, 2022
@ashishdhingra ashishdhingra added p2 This is a standard priority issue queued and removed p1 This is a high priority issue needs-review labels Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved. module/logging p2 This is a standard priority issue queued
Projects
None yet
Development

No branches or pull requests

2 participants