Re: [grpc-io] GRPC Get Server Address

2023-05-01 Thread 'yas...@google.com' via grpc.io
Wow, I forgot to respond to this. Apologies! `ServerContext` does give you `peer()` which I believe is filled with the appropriate address. For security related purposes, we do not recommend that this be used though. You probably want to use a proper authentication mechanism like the ones

[grpc-io] Re: Doubt about "Next" API.

2023-05-01 Thread 'yas...@google.com' via grpc.io
Hi, Wow, I forgot about replying to this. Apologies! You are right in your assumptions. By default, "is going to go to the wire" just means that data has been accepted by the gRPC stack and that gRPC will try to write the data to the socket (or whatever transport mechanism is being used). From

Re: [grpc-io] Re: Connection leak on GRPC Java client

2023-05-01 Thread Arthur Naseef
I updated the README.md for the test project this morning to show a use-case that leaks connections without calling `getState(true)`. https://github.com/artnaseef/opennms-poc-hs1384/blob/main/README.md Art On Monday, May 1, 2023 at 9:08:20 AM UTC-7 Arthur Naseef wrote: > Correct - the client

Re: [grpc-io] Re: Connection leak on GRPC Java client

2023-05-01 Thread Arthur Naseef
Correct - the client is not cleaning up those connections. Netstat shows the ESTABLISHED connections increasing over time. The POC test code shows this can happen even when no GPC call is made, but instead the `channel.getState(true)` call is made by the client application. It can also show

[grpc-io] gRPC message validation question

2023-05-01 Thread Brad Post
Is there a built in validator to ensure that the message passed to a method is the correct one? For example: *message GetAddressInfoRequest {* *string street = 1;* *string zip = 2;* *};* *rpc get_address_info(GetAddressInfoRequest) returns (GetAddressResult);* I would like the