James Newton-King comments

Results 299 comments of


James Newton-King

INTERNAL: Internal error Rst Stream above okhttp 1.47.1 version

You can enable server-side logging. Instructions here: https://learn.microsoft.com/en-us/aspnet/core/grpc/diagnostics?view=aspnetcore-8.0#grpc-services-logging Getting full information about the HTTP error likely requires capturing most logs, e.g. trace level for `Grpc` and `Microsoft` logs (HTTP/2 runs...

Allow argument grpc.so_reuseport to be used

I don't know that setting. Most gRPC for .NET settings are on `SocketsHttpHandler` (client), `KestrelServerOptions` (server) and `GrpcChannelOptions` (gRPC specific)

gRPC C# .NET Framework issue WinHttpException: Error 12175 calling WINHTTP_CALLBACK_STATUS_REQUEST_ERROR

Hi, this looks like a problem with the underlying WinHttpHandler component. Could you copy the issue here to dotnet/runtime repository? I’ll make sure the right people take a look at...

Endless `OperationCancelledException` errors in `GrpcCall` after Cancellation in `SocketConnectivitySubchannelTransport.TryConnectAsync`

Thanks for the detailed report. I can reproduce the error by adding the code you suggested. However, that doesn't answer the question of how the subchannel got in that state....

Endless `OperationCancelledException` errors in `GrpcCall` after Cancellation in `SocketConnectivitySubchannelTransport.TryConnectAsync`

https://www.nuget.org/packages/Grpc.Net.Client/2.63.0-pre1 is on NuGet with this change. A non-preview version will come in about 2 weeks.

Connecting to gRPC Server over Unix Domain Socket

`ConnectAsync` isn't supported when using unix domain sockets. Remove it and make gRPC calls as usual.

Picker poisoning after calling `Listener(...)` and `PickAsync(...)` in parallell

Hi I took at the sample. When I ran the new test, it eventually failed but I didn't see it go into a state where the picker stops working forever....

Picker poisoning after calling `Listener(...)` and `PickAsync(...)` in parallell

I updated the test slightly to reset the error count when there is a successful pick, and to increase the number of allowed concurrent errors. https://github.com/JamesNK/grpc-dotnet/commit/61341208eb134f71acc7e8cc632dd380414a65e5 I made these changes...

Picker poisoning after calling `Listener(...)` and `PickAsync(...)` in parallell

Sorry, I still don't understand what the bug is your test is showing. While looking at this I noticed a bug about a pending connection attempt not being canceled when...

Picker poisoning after calling `Listener(...)` and `PickAsync(...)` in parallell

Reconnect and connection backoff is already there. It's been a feature for years. I fixed what I think might be an unrelated bug here - https://github.com/grpc/grpc-dotnet/pull/2410 - when investigating this...