Hi,
I was taking a look at the example below.
https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_client2.cc
Here one thread access completion queue on the receive side & different
thread write on the completion queue.
Does the api user has to acquire locks in order
My applications needs to send a gRPC request from the WPF program to the
Python service, request data is an opencv mat The contents of my proto file
are as follows:
Service gRPCRecognition {
Rpc Compare (CompareRequest) returns (CompareReply) {}
}
Message CompareRequest {
Bytes CurrImage
In my opinion, gRPC should not set an artificial limit on min value of
TCP_USER_TIMEOUT. It is a well know option available in Linux for a long
time. It should be a pass-thru value for gRPC as it does not modify the
kernel behavior w.r.t this setting. There are applications (e.g. in
graphics
https://github.com/grpc/proposal/pull/96
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to
Hi Carl,
Thanks for the reply! I have a question regarding this:
my grpc client and server are doing bi-directional streaming, in the
StreamObserver.onNext() the client passed to server, its just print out the
response from the server.
And on the client side, when creating the channel, I
You can see the change
here:
https://github.com/grpc/grpc-java/commit/defb955f3ab233e11d960a42495ca955306d57a4
. StreamObserver wraps a ClientCall.
On Thursday, August 23, 2018 at 1:09:55 PM UTC-7, eleano...@gmail.com wrote:
>
> Hi Carl,
>
> what about StreamObserver thread safety? can you
Hi Jasper,
Thanks for your reply!
The error we encounter was `Netty lib does not support Sparc64: could not
load a native library: io_grpc_netty_shaded_netty_tcnative_sparc_64`
Did you encounter it before?
On Tuesday, August 21, 2018 at 1:18:34 PM UTC-7, Jasper Siepkes wrote:
>
> Hi!
>
> We
Also,
https://github.com/grpc/proposal/blob/master/A8-client-side-keepalive.md
specifies
that KEEPALIVE_TIME is restricted to 10 seconds, but doesn't seem to impose
a similar restriction on KEEPALIVE_TIMEOUT
On Thursday, August 23, 2018 at 10:21:08 AM UTC-7, yas...@google.com wrote:
>
> I
I like the idea of reusing the channel option KEEPALIVE_TIMEOUT for this,
but I am hesitant for exactly the reason that you pointed out. It would
give meaning to KEEPALIVE_TIMEOUT even if keepalive is disabled by setting
KEEPALIVE_TIME to infinite. Also, given the fact that TCP_USER_TIMEOUT is
Also, this stuff is pretty complex for users already. Adding *yet
another* configuration
parameter just worsens that. I'd much rather they just set one set of
parameters and we make the most use of them as we can on each platform.
On Thu, Aug 23, 2018 at 8:43 AM Eric Anderson wrote:
> I'd
I'd prefer we re-used KEEPALIVE_TIMEOUT for this. This would change the
semantics slightly, as right now the value does nothing when KEEPALIVE_TIME
is infinite (the default). However, it makes a lot of sense to use the same
value for both entries because they have mostly-shared fate. The only
11 matches
Mail list logo
