Michael,
I haven't tried grpc.closeClient(client) yet, but I did try
client.$channel.close(), which seems to be the same.
To the best of my knowledge CloseWait/FinWait2 means that the client and
server have started termination of the TCP session, but not finalized it.
The impact is that
You've misunderstood :)
The server application needs to request incoming calls, and we need to
match them to requests as they come in. We arbitrarily reverse to order of
matching (because we get a faster implementation), but preserve the order
of actual requests presented to the application.
On
The rationale is discussed in https://github.com/grpc/grpc/issues/5371
For server side, Mocking/DI works fine for abstract base class.
For client side, you should never mock the stubs, because a mock/fake stub
is totally inconsistent with how the gRPC library actually works. For
testing, a
When protoc generates java stubs, it doesn't create interfaces for stubs or
services. Instead, the blocking/async stubs are final classes and the
service is an abstract base class. Interfaces would make mocking, DI, and
utility classes easier to implement.
Is the absence of generated
As for middleware, i would keep an eye on this
issue: https://github.com/grpc/grpc/issues/8767
On Tuesday, February 14, 2017 at 12:16:42 PM UTC, yan...@chaitin.com wrote:
>
> I'd like to add some metadata like token or version at each call, and
> server should check it.
>
> I know how to add
As has been noted before, I think this would be possible by doing a pure
implementation, wrapping the java client, or with a JNI wrapper over the
C-core (these implementations probably end up relatively different from
C-wrapping grpc-ruby).
Actually one thing hasn't been noted yet: If only a
Hi,
After figuring out how to achieve authorization and looking at the test
code in grpc source, i notice that in the AuthMetadataProcessor, the
consumed metadata is added as a property to AuthContext. What is the
purpose of this AuthContext? Is it used as an authorization cache? Or is it
It's a little awkward, but you can close a client with
grpc.closeClient(client). That just closes the channel, though, so if that
didn't work, that's a bug. I don't recognize the names "CloseWait" and
"FinWait2", can you be more specific about how this is failing?
On Tue, Feb 14, 2017 at 7:54 PM
This is the command I used to make a grpc request to my server:
$ /work/Go/src/github.com/grpc/bins/opt/grpc_cli call 0.0.0.0:50051
ExampleServerData example.proto "server_id: '---xxx'"
--enable_ssl=false
connecting to 0.0.0.0:50051
E0215 16:11:59.4383776278343 cli_call.cc:73]
Hi,
I am integrating currently gRPC C# into a program which uses several third
party libraries.
Thus it is also forced to use x86/32 bit.
When calling even a trivial server implementation I receive "Received
RST_STREAM with error code 8".
The full stack can be found below.
The used Nuget
10 matches
Mail list logo
