A few things to note:
- ByteString has gone away in favor of AsciiString.
- Http2Headers now uses CharSequence for all methods, so there are a few places that we have to explicitly check for AsciiString to get the optimizations.
- We now have to specify a graceful shutdown timeout for our Netty handlers. Using 5 seconds.
The encoding of the issuer field in this cert is now a PRINTABLESTRING
as opposed to UTF8STRING in the previous server1.pem which was causing
the Go issue.
- https://github.com/grpc/grpc/pull/4096
- https://github.com/grpc/grpc-go/pull/442
Sorry I should have done this java PR and have it approved before
submitting the grpc-go and grpc PRs.
If a LoadBalancer is requested for a transport future before it can get
one from TransportManager, e.g., before name resolution is completed,
LoadBalancer will return a blank future created by BlankFutureProvider
and to be linked with real futures later.
This allows for binding state to be reset to known-good states precisely which in turn
facilitates making it safe to have 'detach' not throw exceptions and instead log
a severe error that attach/detach calls were not correctly balanced.
The error occurs when name resolution completes after the channel is
shut down. What ManagedChannelImpl doing right now is violating the
TransportManager interface, because TransportManager.getTransport()
should never return null.
We've seen an NPE as a side-effect of a failure in protocol negotiation:
Oct 27, 2015 9:27:09 PM io.grpc.transport.netty.ProtocolNegotiators$AbstractBufferingHandler fail
SEVERE: Transport failed during protocol negotiation
java.lang.NullPointerException
at io.grpc.transport.netty.NettyClientHandler$2.visit(NettyClientHandler.java:218)
- Channel builders decide the default port based on whether TLS is used.
- Channel builders populate the default port via an Attributes object
passed to NameResolver.Factory#newNameResolver
Although it is unlikely the awaits return false, it would be useful
information to know about the failure if they did.
This should provide more clues in case the test flakes again (#1146)
Without the attributes, fc loses its mind a bit when comparing the
codegen output against the golden; the golden would have DOS newlines
(assuming default git configuration) and the generated code would have
Unix newlines.
The jenkins-pre script just reduces the amount of code is backed into
the jenkins project.
This fixes a problem where gradle would try to use VC's amd64_x86 cl
(without the correct environment) and fail to compile with return code
-1073741515 (STATU_DLL_NOT_FOUND) because of missing mspdb120.dll.