Tracking Issue for Netty being Experimental.

[carl-mastrangelo]

Despite Netty being the default and recommended transport, we mark is as experimental, implying it is not stable. Once the transport layer is stable, this should be promoted.

Either we should commit to supporting it, or commit to a subset of the methods exposed.

Specific usages:

• GrpcSslContexts
• GrpcSslContexts.configure
• NegotiationType
• NettyChannelBuilder
• NettyServerBuilder

[email2liyang]

Hi, @carl-mastrangelo

1. Do you have any data shows that how unstable it is for NettyChannelBuilder?
2. Is the instance of ManagedChannel build by NettyChannelBuilder thread safe
3. what's the recommended channel lifecycle management strategy
4. can it be shared between different stubs for a same gRPC #server?

[carl-mastrangelo]

1. NettyChannelBuilder is pretty stable, and likely to be around for a long time, but we reserve the right to change its interface at any time. We try to avoid such changes, but it is not held to the same level of API stability.
2. I believe it is thread safe, but you should be interacting with the channel very rarely.
3. You should make a channel, and wrap it in a stub. Use the stub as the entry point. When you are ready to shutdown the channel, just call shutdown and then awaitTermination to wait for all RPCs to finish.
4. Yes.

In the future, these kinds of questions would be better answered on the user forum here: https://groups.google.com/forum/#!forum/grpc-io

[hcoona]

I've got some questions:

1. The buildTransportServer & buildTransportFactory method are protected, how could I use the NettyServerBuilder & NettyChannelBuilder?
2. I'd like to leverage netty resolver mechanism for service discovery, how could I build the netty channal with it? (For example, the DnsNameResolver)

[carl-mastrangelo]

@hcoona

1. Those are protected as they are called by the super class. They don't have a use outside of NCB.
2. You can use the same event loop with each, but not the same channel. DnsNameResolver is not public API, and isn't specific to netty (okhttp uses it too).

[savannahar68]

@carl-mastrangelo
On using NettyChannelBuilder for a GRPC Client and using it

.withOption(ChannelOption.SO_TIMEOUT, timeout.getSocketTimeoutInMillis())

gives this error.

WARN i.g.n.s.i.n.b.Bootstrap - Unknown channel option 'SO_TIMEOUT' for channel

Does this mean SO_TIMEOUT is not allowed with NettyChannelBuilder with Grpc and the client service should use withDeadline on stub?

[ejona86]

There are no plans to ever stabilize this API.