Put Channel into TRANSIENT_FAILURE when CDS/EDS resource that is currently being watched becomes unavailable. CDS/EDS LB policies should shut down their downstream policy instances (stop using current Subchannels for new RPCs) and propagate TRANSIENT_FAILURE status to their parent policies (and may eventually to the Channel).
The original service config error handling design was unclear about the case when an updated resolution result with valid service config and empty address is returned to Channel, and the selected LB policy does not accept empty addresses. Existing implementation silently triggers resolver backoff after LB policy is changed, while leaving Channel being CONNECTING state, if there was an old service config resolved. This change converge the behaviors of whether the received service config is the first one or an update to a previous config, in both cases, Channel goes into TRANSIENT_FAILURE if the selected LB policy cannot handle empty addresses.
This splits server-side flow control from client-side, but tailors the API for
each case. Client-side continues having disableAutoRequestWithInitial(). While
client-side could have disableAutoRequest(), it seems like it will only rarely
be used and disableAutoRequestWithInitial(0) isn't that bad. So we leave it off
for now; we can always add it in the future.
To avoid having too many ShortBufferException thrown in ALTS code path on Java 8, we came up with this workaround creating new managed buffer, filling it, and passing it to underlying Conscrypt not to hit the code path throwing the exception. This might look to introduce another inefficiency but it's more like making it explicit because Conscrypt will do for non-managed buffer which gRPC uses.
Fix: #6761
Changed the logic of parsing Route to skip Routes with action that specifies cluster_header. Eliminate unnecessary validation logic in XdsClientImpl, of which is already covered in converters.
This PR changes the `NettyServerTransport#getLogLevel` method to log
`SocketException`s to `LogLevel.FINE`, rather than exclusively pure
IOExceptions. This may fix an unintentional regression introduced in
c166ec2c, although the message in my java version (14.0.1) wouldn't have
passed the old logic for quieting either. This also fixes the issue
raised in #6423 that was locked for inactivity.
This fixes
```
[2020/05/14 20:21:52 INFO] [io.grpc.netty.NettyServerTransport.connections] Transport failed
java.net.SocketException: Connection reset
at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:345)
at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:376)
at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1125)
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:347)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:677)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:612)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:529)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:491)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:905)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:832)
```
being logged to level INFO, which occurs whenever a socket is improperly
closed by the client, such as with the grpc-health-probe (They've got an
[open issue](https://github.com/grpc-ecosystem/grpc-health-probe/issues/34)
for this)
If the server fails (e.g.: with an unimplemented status), the test still succeeds.
This change adds assertions to check the status code as well as the expected number of responses.
We include this dep in our examples, but never mentioned it in the README.
Instead of getting into details about what it's for, the brief comment should
avoid most confusion for existing Java 8 users about why it appears to be
unnecessary.
Add a new disableAutoRequest method that disables all automatic requests while disableAutoInboundFlowControl maintains existing behavior.
The default behavior of requesting initial messages is applied even if disableAutoInboundFlowControl is called. ServerCalls disables all automatic flow control which is much more useful in case the user can't handle incoming messages until some time after the call has started. This change creates a new StartableListener that has an onStart method that is invoked when the call is started which makes initial requests if necessary.
See #6806
This is a java analogue of the C++ test added in grpc/grpc#19623.
Proto changes were synced from grpc/grpc-proto
This client is suitable for testing fallback with any "grpclb" load-balanced service, but is particularly meant to implement a set of test cases described in an internal doc titled "DirectPath Cloud-to-Prod End-to-End Test Cases", section "gRPC DirectPath-to-CFE fallback".
Elliotte Rusty Harold
Chengyuan Zhang
Eric Anderson
Gaurav S
ZHANG Dapeng
sanjaypujare
Jihun Cho
Reginald McDonald
Nicholas Titcombe
Esun Kim
AgentK
Ran
Jongho Jeon
Philippe Laflamme
Kun Zhang
DRayX
apolcyn