-
Notifications
You must be signed in to change notification settings - Fork 791
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
Add additional connection and request logging to client #2047
Add additional connection and request logging to client #2047
Conversation
@@ -300,6 +309,7 @@ public async ValueTask<Stream> GetStreamAsync(BalancerAddress address, Cancellat | |||
lock (Lock) | |||
{ | |||
_activeStreams.Add(new ActiveStream(address, socket, stream)); | |||
SocketConnectivitySubchannelTransportLog.StreamCreated(_logger, _subchannel.Id, address, _activeStreams.Count); |
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.
logging inside the lock troubles me; is this intentional? would it perhaps be better to snag the Count
inside the lock and log outside?
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 don't think this is a concern. There is logging inside locks throughout gRPC and ASP.NET Core.
@@ -331,7 +341,7 @@ private void OnStreamDisposed(Stream streamWrapper) | |||
if (t.Stream == streamWrapper) | |||
{ | |||
_activeStreams.RemoveAt(i); | |||
SocketConnectivitySubchannelTransportLog.DisposingStream(_logger, _subchannel.Id, t.Address); | |||
SocketConnectivitySubchannelTransportLog.DisposingStream(_logger, _subchannel.Id, t.Address, _activeStreams.Count); |
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.
hmmm, maybe ignore my last comment about lock; I can't see a nice / clean way of avoiding this one, so... if we're in that situation anyway, maybe just live with 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.
added a question about logging inside the lock, and whether we care about that - I can't get hugely excited either way, as long as considered - looks fine generally
Additional logging for #1948
Also, implement DisposeAsync on StreamWrapper in as there is a situation where it is called.