)

- Usually the pattern is to establish a stream and read messages
in the loop until io.EOF. If the server become unavailable after
sending a good message in the stream, the client has to retry from
establish stream and handle the backoff logic.

google.golang.org/grpc now implements the functionality directly.

The four (client/server, unary/stream) interceptors have to wrap a slice
of interceptors in functions which satisfy the handler interface, but
which are closures over the other parameters an interceptor is expected
to have.

The previous approach accomplished this goal with recursion. This had
two drawbacks: first, the code was difficult to understand, as most
recursion attempts to fully encode state in function parameters, but
here state was necessarily also encoded in the closure; and second,
the recursive base-case meant that even the innermost interceptor was
not calling the bare handler, it was calling a wrapped handler.

This new approach instead iteratively constructs wrappers from the
inside out. It results in fewer lines of code, with fewer variables
held in each closure. Hopefully this results in higher readability.

…#426)

The caller annotations made by the shorthand logging functions are
`ctxzap/context.go:xx` regardless of where the shorthands are called.

This commit adds caller skip so that each log message has the correct
caller annotation.

Since `zapGrpcLoggerV2` wraps a zap's logger, caller annotations always
point `grpclogger.go` instead of the expected file. This commit adds
caller skip so that each log message has the correct annotation.

This commit also upgrades zap's version to v1.18.1 to use `zap.OnFatal`
in tests. That function is necessary to catch fatal level log messages.

Signed-off-by: Rajiv Ranjan Singh <rajivperfect007@gmail.com>

Co-authored-by: Amir_Ali97 <Amir@fenix.life>

Signed-off-by: cuishuang <imcusg@gmail.com>

* Fix memory leakage in kit.PayloadUnaryServerInterceptor


Closes issue #498

A wrong assign creates multiple object for GC, and with every call appends new objects, so GC have to walk through thousands of objects. This causes high increasing memory and CPU usage. We saw in our services that it leads to CPU throttling and increasing of a memory usage.

* Fix logging in PayloadUnaryServerInterceptor

Issue #498

…release notes for this). (#542)

* v1: Mentioned v2 in README and removed changelog (we will use release notes for this).

Signed-off-by: bwplotka <bwplotka@gmail.com>

* Fixed CI.

Signed-off-by: bwplotka <bwplotka@gmail.com>

---------

Signed-off-by: bwplotka <bwplotka@gmail.com>