Then channelz GUI will take this into account. This is particularly
useful for InProcessTransport, where I have decided we do not need
special support for in channelz. The server and channel stats are
already sufficient.
The peer socket is read from TRANSPORT_ATTR_REMOTE_ADDR from the
stream attributes. We only log the peer on receive initial metadata.
The call id assumes census is available. The call ID read from the
context via SERVER_CALL_ID_CONTEXT_KEY on server side, and read from
CallOptions via CLIENT_CALL_ID_CALLOPTION_KEY on client side. The
value is copied from CONTEXT_SPAN_KEY which is set by census.
Pass around CallId with two longs, not a byte[].
Server listen sockets differ from normal sockets in that they do not
have a remote address, do not have stats on calls started/failed/etc,
and do not have security info.
This fixes a serial warning that breaks the build when building
_without_ ErrorProne. I have no clue why _disabling_ ErrorProne makes
the warning pop up, but whatever, the warning is legit.
I also gave it a name, since the anonymous $1 seems weird if we're
providing a serialVersionUID. Not to say we're actually supporting
serializing this object. But if we ever see a serialized form show up in
the future, having a more clear name would make it obvious what it is.
- To make unit tests easier, added the BinaryLogSinkWriter abstract
class, which allows verifying high level arguments rather than low
level protobufs.
- remove InputStream based marshaller (IDENTITY_MARSHALLER) in favor
of byte[] because retries will need to call serialize multiple
times. This is achieved with a special InputStream that lets us
access the internal byte[] without copying.
- Change ByteBuffer based internal methods to use byte[]
- Update unit tests to reflect the above
Rather than querying the ServerImpl for its sockets, we register them
into channelz as with all the other entities, for consistency.
Error conditions are checked with `assert` statements, so we throw in
tests.
Fix NPE and refactor tests to make it more obvious whether tests
assume empty or non empty metadata.
Add null checks to applicable places in binary log.
This adds the proto and generated output.
These options are used:
option java_multiple_files = true;
option java_package = "io.grpc.channelz.v1";
option java_outer_classname = "ChannelzProto";
The `BinaryLog` will write `GrpcLogEntry`s to the sink, which is
intended as a pluggable interface. It is the sink's
responsibility to send the binlog protos to disk, to a remote
logging service, etc.
This moves away from the global String-based Span name registry which
is not as flexible as we desire.
Also renamed the option name to be more accurate. This is not
API-breaking because the origianl addition to MethodDescriptor and
code-gen didn't make it into the 1.7.0 release.
* MethodDescriptor is lazy loaded, so protobuf loading only happens on demand. This also means tracing registration happens on demand.
* The names of the getters all being with `method`. This makes it harder for autocomplete to pick them up.
* A new field is used, which matches the getter name. Rather than make the new-getters reference the old-fields, make the old-fields reference the new getters. This makes removal of the old-fields a simple operation.
* The getters may not be inlineable, but thats an easy fix if it ends up being a problem. Not worth premature optimization (but is worth future work).
The expected timeline for this is adding this to the 1.8 cut, and deprecating the old-fields. They will be removed in 1.9.
This is a more favorable approach than #3467. Doing the registration
in MethodDescriptor should allow us to deregister in case the
generated stub and its MethodDescriptors are garbage-collected
routinely, e.g., if they are loaded by a separate ClassLoader.
This bump changelist is applied a bit late with respect to the
1.6.0 branch cut. Look at the 1.6.0 to see the source of truth of
where it was cut. Do not assume it is the commit that precedes
this one.
Carl Mastrangelo