[grpc-io] Re: Go - TRANSIENT_FAILURE and FailOnNonTempDialError

This check is only applied to the connection errors (specifically errors return from a custom dialer, or from creds handshake). Errors are non temporary by default. You can make it implement the interface and return true. It has nothing to do with wait-for-ready. And it only applies to the

[grpc-io] Re: Go - IDLE_TIMEOUT support

IDLE_TIMEOUT isn't supported in go. It's tracked in https://github.com/grpc/grpc-go/issues/1719 The PR you mentioned is a step towards this goal. But that only covers connection idleness, not at the ClientConn level (e.g. it doesn't turn down resolver and balancers) On Saturday, July 24, 2021

Re: [grpc-io] Re: Go - Server with TLS and Insecure Client

(), maybe things happened too fast that the client got killed before the logs were flushed? On Tuesday, July 13, 2021 at 3:45:22 PM UTC-7 amits...@gmail.com wrote: > On Tue, Jul 13, 2021 at 4:25 AM 'Menghan Li' via grpc.io > wrote: > > > > Yes, this is expected. The connection

[grpc-io] Re: Go - Server with TLS and Insecure Client

Yes, this is expected. The connection cannot be created, because the server is expecting a handshake, but the client is not configured to do it. The only thing is, I would expect a better error message. Can you check the client and server logs and see if there's any information?

[grpc-io] Re: A weird issue index out of range: 3 + 116> 76

Can you provide more details of what the client/server do? And maybe try to turn on logs: https://github.com/grpc/grpc-go#how-to-turn-on-logging And also check kubernetes error logs? It's not clear to me where the error is from. And this looks like a recovered panic. gRPC code doesn't use

[grpc-io] Re: Julia lang: validating an implementation attempt

There's a set of interop tests defined in: https://github.com/grpc/grpc/blob/master/doc/interop-test-descriptions.md If you implement the client/server, you can run the tests as Julia to Julia, or between Julia and other languages. Some basic tests to start with are: empty_unary,

[grpc-io] Re: Is there a way to verify if HTTP2 or HTTP1.1 is in use?

gRPC only support HTTP2, no matter with or without security. > I am using a C++ server, and a C++ client and JS client, Which JS client are you referring to? Is it Node client? Or JS from browser? JS from browser would be gRPC-web, it's wire format is different from gRPC over HTTP2, see more

[grpc-io] gRPC-go Release 1.36.0

gRPC-go 1.36.0 is now released. Full release notes: New Features - xds bootstrap: support config content in env variable (#4153 ) Bug Fixes - encoding/proto: do not panic when types do not match (#4218

[grpc-io] Re: CallCredentials Without ChannelCredentials

If you don't need transport credentials, create the channel with `grpc.WithInsecure()`. And make sure your `TokenAuth` returns false in `RequireTransportSecurity()`. Otherwise Dial will fail. (See doc at https://pkg.go.dev/google.golang.org/grpc@v1.35.0/credentials#PerRPCCredentials) Please

[grpc-io] gRPC-go Release 1.33.1

gRPC-go 1.33.1 is now released. Release 1.33.0 is skipped because we mistakenly tagged v1.33.0 at the wrong commit. Full release notes: API Changes - connectivity: remove unused, experimental Reporter interface (#3875 ) New Features - xds

[grpc-io] Re: [C++] Custom error_message for grpc::Status::OK

OK status is not designed to include error messages. Other options are: - Send it in the response - Send RPC trailer metadata (example: https://github.com/grpc/grpc/tree/master/examples/cpp/metadata) On Thursday, September 3, 2020 at 3:49:08 AM UTC-7 tnkh...@gmail.com wrote: > Sometimes, I

[grpc-io] gRPC-go Release 1.31.0

gRPC-go 1.31.0 is now released. Full release notes: API Changes - balancer: remove deprecated type aliases (#3742 ) New Features - The following new xDS functionalities are added in this release (xDS features supported in a given release

[grpc-io] gRPC-go Release 1.30.0

gRPC-go 1.30.0 is now released. Full release notes: API Changes - This release adds an xDS URI scheme called xds. This is the stable version of the scheme xds-experimental that was introduced in v1.28.0. xds-experimental scheme will be removed in subsequent releases so you must

[grpc-io] gRFC A28: gRPC xDS traffic splitting and routing

https://github.com/grpc/proposal/pull/178 This adds more xDS features in gRPC. Based on A27 ( https://github.com/grpc/proposal/blob/master/A27-xds-global-load-balancing.md ) -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this

[grpc-io] gRPC-go Release 1.27.0

gRPC-go 1.27.0 is now released. Full release notes: API Changes - balancer/resolver: remove temporary backward-compatibility type aliases (#3309 ) Behavior Changes - dns: ignore TXT errors unless GRPC_GO_IGNORE_TXT_ERRORS=false (#3299

[grpc-io] gRPC-go Release 1.25.0

gRPC-go 1.25.0 is now released. Full release notes: API Changes - resolver: move dns and passthrough to internal (#3116 ) New Features - credentials: add RequestInfo to context passed to GetRequestMetadata ( #3057

Re: [grpc-io] Detect TLS mismatch between Client and Server

There's currently no built-in ways to detect this. You can do a dial WithBlock with FailOnNonTempDialError as mentioned in this issue: https://github.com/grpc/grpc-go/issues/2863#issuecomment-500852442 You will need wrap TLS to make the specific TLS errors non-temporary, and the dial will fail

Re: [grpc-io] Detect TLS mismatch between Client and Server

If the connections fail because of TLS issues, the RPCs will also fail, and the RPC errors will have the TLS error message. The PR https://github.com/grpc/grpc-go/pull/2055/

[grpc-io] Re: On client-streaming RPC, How to do Windowing, Filtering or Watermark of Client messages?

Hi, Can you provide more details about what you are trying to do? Some examples would also help. And which language are you using? Thanks, Menghan On Saturday, March 16, 2019 at 11:35:30 AM UTC-7, Chethan U wrote: > > Hello Sir, > > I have some doubts: On client-streaming RPC, How to do

[grpc-io] gRPC-go Release 1.19.0

gRPC-go 1.19.0 is now released. Full release notes: API Changes - dialOption: export WithContextDialer() (#2629 ) - client: deprecate CallCustomCodec and provide new version using encoding.Codec (#2556

[grpc-io] Re: Push based name resolution in Go

The current resolver interface is capable of handling push based resolvers. Call `NewAddress()` whenever you have the updated addresses (when you get a push). Thanks, Menghan -- You received this message because you are

[grpc-io] Re: grpc reconnect

You can set a custom dialer (https://godoc.org/google.golang.org/grpc#WithDialer). This dialer is called to create new connections. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it,

[grpc-io] gRPC-go Release 1.16

gRPC-go 1.16.0 is now released. Full release notes: New Features - health: implement Watch method in server (#2365 ) - balancer: add trailer metadata to DoneInfo (#2359 ) - balancer: add header

[grpc-io] Re: grpc-go balancer behavior when there are no backends

Ashwin, What you observed is correct. A bit into details: failfast RPCs fail when the ClientConn is in TRANSIENT_FAILURE, which means, all underlying connections are all in TRANSIENT_FAILURE. But if the resolver never returned any addresses, no connection was ever started, so the connectivity

[grpc-io] gRPC-go Release 1.11.0

gRPC-go 1. ​11 .0 is now released. Full release notes:​​ Dependencies - travis: add Go 1.10 and run vet there instead of 1.9 (#1913 ) API Changes - credentials/alts: Update ALTS "New" APIs (#1921

[grpc-io] gRPC-go Release 1.10.0

gRPC-go 1. ​10 .0 is now released. Full release notes: ​ API Changes - Revert "Add WithResolverUserOptions for custom resolver build options" (#1839 ) Behavior Changes - streams: Stop cleaning up after orphaned streams (#1854

[grpc-io] Re: Is there a way for gRPC server - Go server specifically, to close the the client stream/connection?

For connection level auth, if the ServerHandshake() function returns an error, the connection will be closed by the server: https://github.com/grpc/grpc-go/blob/82e9f61ddde02833789fdca2123b576151db8654/server.go#L565 There's currently no way to close the connection in the RPC handler. -- You

Re: [grpc-io] Re: Server side connection management

Ravi, In go, the client address is part of the peer struct in the RPC context (https://godoc.org/google.golang.org/grpc/peer#Peer). Use https://godoc.org/google.golang.org/grpc/peer#FromContext to get peer out from the context. Thanks, Menghan -- You received this message because you are

[grpc-io] gRPC-go release 1.8.0

​​gRPC-go 1.8.0 is now released. Full release notes: Dependencies - Re-add support for Go1.6 (#1603 ) API Changes - Add functions to ClientConn so it satisfies an interface for generated code (#1599

[grpc-io] Re: [grpc-go] How to properly use context.Done()?

If there's a way for the redisClient to create a pubsub client with a given context, you should call that function with the stream context. All cancellation and timeout will be propagated automatically. If that's not possible, you can move the for loop into a goroutine. In the service handler

[grpc-io] Re: Preventing RPC access to a single process when using localhost

I would think a transport security layer sounds OK here, since you want it to be compatible across multiple systems... On Tuesday, September 5, 2017 at 6:55:39 AM UTC-7, johns...@gmail.com wrote: > > I've got a process that is running GRPC servers on a single device via > localhost in Golang.

[grpc-io] Re: If a message of GO data struct format is built in C, how such msg is used in GO without unmarshal?

Please see answer at: https://groups.google.com/forum/#!topic/grpc-io/682p5QJS4SU On Monday, October 16, 2017 at 10:10:50 AM UTC-7, Steven Jiang wrote: > > Hi, > A message following GO data struct format has to be built inside C code. > Could anyone tell me how could this message be used in GO

[grpc-io] gRPC-go release 1.7.0

gRPC-go 1.7.0 is now released. Full release notes: Dependencies - Remove Go1.6 support (#1492 ) API Changes - Add new Resolver and Balancer APIs (gRFC L9) (#1408 ) - New implementation of

[grpc-io] Re: High latency while concurrent unary rpc over same connection(grpc-go)

Tracked in issue: https://github.com/grpc/grpc-go/issues/1512 -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this

[grpc-io] gRPC-go 1.6.0

​ gRPC-go 1.6.0 is now released. Full release notes: API Changes - Add and use connectivity package for states (#1430 ) - metadata: Remove NewContext and FromContext for gRFC L7 (#1392 ) - Remove

[grpc-io] gRFC L9: new balancer and resolver APIs for gRPC-go

gRFC for new balancer and resolver APIs for gRPC-go: https://github.com/grpc/proposal/pull/30 Issues solved include: - switching balancers based on service config - get service config updates from resolver -- You received this message because you are subscribed to the Google Groups

[grpc-io] gRPC-go 1.5.0

​​ gRPC-go 1.5.0 is now released. Full release notes: Performance - BDP estimation and window update. (#1310 ) - Do not flush NewStream header on client side for unary RPCs and streaming RPCs with requests. (#1343

[grpc-io] gRPC-go 1.4.0

gRPC-go 1.4.0 is now released. Please see release notes at: https://github.com/grpc/ grpc-go/releases/tag/v1.4.0 -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[grpc-io] Re: [grpc-go] Multiple concurrent clients and bidirectional streaming

Everything you described about the design RPC service looks reasonable. But we may need more information to find out why all RPCs are accidentally canceled. Is each client an independent ClientConn, or one stream from the same ClientConn (I assume independent ClientConn because you said it

Re: [grpc-io] Re: gRPC-go golang-version and "context" package survey

Sorry about that. Should work now. On Tue, May 2, 2017 at 2:23 PM, 'Alex Barlow' via grpc.io < grpc-io@googlegroups.com> wrote: > I'd love to fill in and help, but I get a permission denied at the moment! > > > On Tuesday, 2 May 2017 18:46:25 UTC+1, Menghan Li wrote: >> >> Beginning with Go 1.7,

[grpc-io] gRPC-go golang-version and "context" package survey

Beginning with Go 1.7, the Standard Library includes a "context" package that is intended to supersede "golang.org/x/net/context". There has been some discussion about migrating to this new package in gRPC: https://github.com/grpc/grpc-go/issues/711. This form is to get an idea how gRPC-go users

[grpc-io] Re: How to set TOS bits on grpc server side for a new grpc client connection request?

If you just need to have access to the net.Conn, you don't need to change the grpc lib. What I mean is something like: type listenerWrapper struct { net.Listener } func (l *listenerWrapper) Accept() (net.Conn, error) { c, err := l.Listener.Accept() if err == nil { *// Do something to the

[grpc-io] Re: How to set TOS bits on grpc server side for a new grpc client connection request?

net.Listener is an interface. You could wrap the listener, override the Accept(), and set the TOS bit there. On Tuesday, April 18, 2017 at 4:30:24 PM UTC-7, Steven Jiang wrote: > > grpc server is listening on a port and accepting connection request from > grpc clients. lis.Accept() is called

Re: [grpc-io] Re: Go gRPC server keeps connections open even if clients died

Client side keepalive support is merged in https://github.com/grpc/grpc-go/pull/993 Server side support is in review: https://github.com/grpc/grpc-go/pull/1119 On Thu, Jan 12, 2017 at 5:11 PM, 'Qi Zhao' via grpc.io < grpc-io@googlegroups.com> wrote: > Yes, you are right. We need that heart-beat

[grpc-io] Re: Connect to a Go GRPC Server running with TLS enabled using node js grpc client

gRPC server expects http2.ClientPreface(https://godoc.org/golang.org/x/net/http2#pkg-constants). >From the server side log, I can only tell that it didn't get the ClientPreface. The client logs doesn't tell anything more than the connection failed. I'm not sure what the reason is. Can you