TLS Support #96
Closed
TLS Support #96
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I should have to say "must!", but I know it's not so easy. |
|
Just note: #37 |
|
Is this PR still alive? |
|
@gFazzari Yes! @tagomoris Yes, I am running in our load test. |
tagomoris
requested changes
Nov 10, 2021
There was a problem hiding this comment.
This change looks generally good to me.
I added two comments about details, and I want one more update on README about FluentNetwork to add "tls" as an option there.
|
@zonito DCO check is now failing. Could you check the instruction? |
|
@tagomoris Please confirm. I have also tried to address DCO check |
tagomoris
reviewed
Nov 10, 2021
|
We can't merge comments without |
Signed-off-by: Cam <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: ivan-valkov <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: ivan-valkov <[email protected]> Signed-off-by: Love Sharma <[email protected]>
They cannot be retrieved for values so one needs to skip them. This aligns with the json.marshal behavior Signed-off-by: dearoneesama <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Satoshi Moris Tagomori <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Satoshi Moris Tagomori <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Satoshi Moris Tagomori <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Satoshi Moris Tagomori <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Satoshi Moris Tagomori <[email protected]> Signed-off-by: Love Sharma <[email protected]>
We deprecated running tests on Travis in bfce90d. Update the build status badge accordingly. Signed-off-by: Fujimoto Seiji <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
PR #77 introduced a new parameter named ForceStopAsyncSend. It can be used to tell the logger to not try to send all the log messages in its buffer before closing. Without this parameter, the logger hangs out whenever it has logs to write and the target Fluentd server is down. But this new parameter is not enough: the connection is currently lazily initialized when the logger receive its first message. This blocks the select reading messages from the queue (until the connection is ready). Moreover, the connection dialing uses an exponential back-off retry. Because of that, the logger won't look for messages on `stopRunning` channel (the channel introduced by PR #77), either because it's blocked by the Sleep used for the retry or because the connection dialing is waiting until dialing timeout (eg. TCP timeout). To fix these edge cases, the time.Sleep() used for back-off retry has been transformed into a time.After(). Moreover, the dialer.Dial() call used to connect to Fluentd has been replaced with dialer.DialContext() and a cancellable context is now used to stop the call to that method. The associated cancel function is stored in Fluent and got called by Close() when ForceStopAsyncSend option is enabled. Finally, the Fluent.run() method has been adapted to wait for both new messages on f.pending and stop signal sent to f.stopRunning channel. Previously, both channels were selected independently, in a procedural fashion. This fix is motivated by the issue described in: moby/moby#40063. Signed-off-by: Albin Kerouanton <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Albin Kerouanton <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Using defered calls to unlock muconn mutex ensures the mutex doesn't stay locked if the lib user's have a panic recovering mechanism in place and f.connect(), f.conn.Write() or f.close() panic. Signed-off-by: Albin Kerouanton <[email protected]> Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
Signed-off-by: ivan-valkov <[email protected]>
Signed-off-by: ivan-valkov <[email protected]>
PR #77 introduced a new parameter named ForceStopAsyncSend. It can be used to tell the logger to not try to send all the log messages in its buffer before closing. Without this parameter, the logger hangs out whenever it has logs to write and the target Fluentd server is down. But this new parameter is not enough: the connection is currently lazily initialized when the logger receive its first message. This blocks the select reading messages from the queue (until the connection is ready). Moreover, the connection dialing uses an exponential back-off retry. Because of that, the logger won't look for messages on `stopRunning` channel (the channel introduced by PR #77), either because it's blocked by the Sleep used for the retry or because the connection dialing is waiting until dialing timeout (eg. TCP timeout). To fix these edge cases, the time.Sleep() used for back-off retry has been transformed into a time.After(). Moreover, the dialer.Dial() call used to connect to Fluentd has been replaced with dialer.DialContext() and a cancellable context is now used to stop the call to that method. The associated cancel function is stored in Fluent and got called by Close() when ForceStopAsyncSend option is enabled. Finally, the Fluent.run() method has been adapted to wait for both new messages on f.pending and stop signal sent to f.stopRunning channel. Previously, both channels were selected independently, in a procedural fashion. This fix is motivated by the issue described in: moby/moby#40063. Signed-off-by: Albin Kerouanton <[email protected]>
Signed-off-by: Albin Kerouanton <[email protected]>
Using defered calls to unlock muconn mutex ensures the mutex doesn't stay locked if the lib user's have a panic recovering mechanism in place and f.connect(), f.conn.Write() or f.close() panic. Signed-off-by: Albin Kerouanton <[email protected]>
Signed-off-by: Love Sharma <[email protected]>
Closed
|
Closing this duplicate PR because of #107 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Guide me for Unit Test, if it is a must!