fixes#2078
A status with invalid utf-8 characters could still be created, but invalid characters will be replaced with [Unicode replacement character](https://en.wikipedia.org/wiki/Specials_(Unicode_block)#Replacement_character) before being sent out. Those bytes will still be percent encoded.
All details added to this invalid status will be dropped.
* Don't send nil requests.
* Fix import name and get rid of condition.
* Let registered encoder deal with nil requests.
* Break encode into encode and compress.
This change introduces some behavior changes that should not impact users that
are following the proper stream protocol. Specifically, one of the following
conditions must be satisfied:
1. The user calls Close on the ClientConn.
2. The user cancels the context provided to NewClientStream, or its deadline
expires. (Note that it if the context is no longer needed before the deadline
expires, it is still recommended to call cancel to prevent bloat.) It is always
recommended to cancel contexts when they are no longer needed, and to
never use the background context directly, so all users should always be
doing this.
3. The user calls RecvMsg (or Recv in generated code) until a non-nil error is
returned.
4. The user receives any error from Header or SendMsg (or Send in generated
code) besides io.EOF. If none of the above happen, this will leak a goroutine
and a context, and grpc will not call the optionally-configured stats handler
with a stats.End message.
Before this change, if a user created a stream and the server ended the stream,
the stats handler would be invoked with a stats.End containing the final status
of the stream. Subsequent calls to RecvMsg would then trigger the stats handler
with InPayloads, which may be unexpected by stats handlers.
WithBalancerName dial option specifies the name of the balancer to be used by the ClientConn. Service config updates can NOT override the balancer option.
This is in preparation for preventing any user-supplied metadata starting with "grpc-", which is reserved.
* stats: add methods to allow setting grpc-trace-bin and grpc-tags-bin headers
Pick these up in grpc's transport when sending and fill them when receiving.
* Add tags/trace to metadata and tests for that behavior
This is temporary to maintain compatibility and provide a migration strategy.
* First commit
* Imported tests from the original PR by @apolcyn.
* Formatting fixes.
* More formating fixes
* more golint
* Make logs more informative.
* post-review update
* Added test to check flow control accounts after sending large messages.
* post-review update
* Empty commit to kickstart travis.
* Post-review update.
This change ensures consistency for the user when accessing metadata values:
they are never encoded except when sent on the wire. Previously, they would
appear encoded to client code, but not to server code. As such, this
represents a behavior change, but one unlikely to affect user code, as it's
unusual to inspect the metadata after setting it.
This will prevent the incoming RPCs' metadata from appearing in outgoing RPCs
unless it is explicitly copied, e.g.:
incomingMD, ok := metadata.FromContext(ctx)
if ok {
ctx = metadata.NewContext(ctx, incomingMD)
}
Fixes#1148
When an error implemented by the status package is returned from a service
handler, the server will transmit a rich status message in the
"grpc-status-details-bin" trailing metadata field if any detailed data is
attached to the error. Client-side, we will decode them if present in the
server's response and return them to the user code performing the RPC.
This is backward compatible with the existing errors supported by the grpc
package. However, the grpc.Errorf, grpc.Code and grpc.ErrorDesc functions for
managing errors are now deprecated; status.Errorf and status.Status type
asserions should be used instead.
* Add the initial service config support
* start scWatcher later
* remove timeoutCh
* address the comments
* deal with dial timeout
* defer cancel for the newly created context for correct lifetime management
* fix the defer order
* added other 2 missing cancels
Remove the add and cancel methods of quotaPool. Their use is not required, and
leads to logical races when used concurrently from multiple goroutines. Rename
the reset method to add.
The typical way that a goroutine claims quota is to call the add method and
then to select on the channel returned by the acquire method. If two
goroutines are both trying to claim quota from a single quotaPool, the second
call to the add method can happen before the first attempt to read from the
channel. When that happens the second goroutine to attempt the channel read
will end up waiting for a very long time, in spite of its efforts to prepare
the channel for reading.
The quotaPool will always behave correctly when any positive quota is on the
channel rather than stored in the struct field. In the opposite case, when
positive quota is only in the struct field and not on the channel, users of
the quotaPool can fail to access available quota. Err on the side of storing
any positive quota in the channel.
This includes a reproducer for #632, which fails on many runs with this
package at v1.0.4. The frequency of the test failures depends on how stressed
the server is, since it's now effectively checking for weird interleavings of
goroutines. It passes reliably with these changes to the transport package.
The behavior described in #734 (an RPC with a streaming response hangs
unexpectedly) matches what I've seen in my programs, and what I see in the
test case added here. If it's a logical flow control bug, this change may well
fix it.
Updates #632
Updates #734