This is consistent with how io.ErrUnexpectedEOF is handled in a bunch of
other places (e.g. stream.go, server.go), and signals to
application-level code that the error is retryable.
This is a breaking change, but the transport package was never intended for use outside of grpc. Any current users that we are aware of are incorrect or have a preferred alternative.
docs: deprecate stream, move documentation to client|server stream
Deprecate Stream, and move the methods and documention to ServerStream
and ClientStream. This is due to the fact that there are different
semantics for SendMsg, and it's quite confusing to document one method
for two things. Furthermore, Stream is not actually used in any way
other than to be inherited by ClientStream and ServerStream.
Relevant issue: #2159
This PR removes race testing from all travis runs except go1.10 except during nightlies.
| | Before* | After** | % Change |
| --------------- | ------- | ------- | -------- |
| Total runtime | 65m | 45m | -31% |
| Wall-clock time | 21m | 11.5m | -45% |
*: (one random sample I found in our PRs)
**: (latest run on this PR)
Also includes some organization changes (making proper use of `before_install` and `install`) / cleanups in `.travis.yml` to make it easier to understand. As a result, we now stop unintentionally running `vet` on a second build by accident (go1.10 with retry enabled).
Technically this is a behavior change, but any usage of "host:" or ":" should be considered invalid, since dialing a target with a trailing ":" attempts to dial port zero, which is never valid (and we always used to pass the target directly to `net.Dial`).
In https://github.com/grpc/grpc/pull/15618, the target format will be defined as: `host[:port]` -- not: `host[:[port]]`. (This is potentially subject to change.)
Fixes https://github.com/grpc/grpc-go/issues/2161
I introduced `serverTerminatedConnectionErr `, because I wanted `callRemoteBalancer` to still returns error on a terminated connections. Its client, which is function `watchRemoteBalancer` can decide how to log this error.
When remote grpclb-server terminates the connection, don't log it as
error. Instead, log it as info.
It is natural for servers to terminate long lived grpc streaming
connections. Two sample reasons to do this are: load balancing and
deployment of a new version. Therefore client of grpclb-server shouldn't
recognise this situation as an error.
