Re: [grpc-io] [C++] Modifying rpc url paths

[Divakar Y]

Any update or any other suggestion for the same.

On Friday, November 3, 2017 at 3:07:20 AM UTC+5:30, Arpit Baldeva wrote:
>
> Okay - thx for the info. 
>
> As per previous comment about protoc forking,we want to avoid it. The 
> reason being we'd want people to be able to use an off the shelf protoc. 
>
> On Thursday, November 2, 2017 at 10:48:48 AM UTC-7, Eric Anderson wrote:
>>
>> Use a custom header. gRPC does not like alternative paths. It is 
>> possible, just a pain.
>>
>> On Wed, Nov 1, 2017 at 3:01 PM, Arpit Baldeva  wrote:
>>
>>> Hi,
>>>
>>> Currently, looks like rpc urls are generated in the form of />> name>/. Is there a way to prefix the urls such that grpc client 
>>> could call //? The receiver can chop 
>>> off the prefix and call the correct rpc.
>>>
>>> Use case: We'd like to have a proxy sitting between our client and grpc 
>>> server. The proxy will serve multiple clients. So a client could call 
>>> ourdomain.com///. 
>>> The proxy will chop off  and reroute the rpc 
>>> to correct handling instance. 
>>>
>>> One option to do it would be via custom header but was wondering if url 
>>> prefixing has been thought of/brought up before?
>>>
>>> Thanks. 
>>>
>>> -- 
>>> 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+u...@googlegroups.com.
>>> To post to this group, send email to grp...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/grpc-io.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/grpc-io/65e47a3f-c51e-4d34-b6a0-601badd8091f%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/01c8672b-fc0c-4f93-bd49-e5a4a2c3c548%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Getting UNIMPLEMENTED with Java client and server with protobuff 3.4 and grpc 1.8.0

[Hrishi Joshi]

We found the solution ourselves. It was because of wrong package scan path

On Wednesday, 14 February 2018 01:22:41 UTC+8, Hrishi Joshi wrote:
>
>
> We have a java based gRPC server and client. Both using version 1.8.0.
> After verifying both client and the server have the same proto file and 
> java lib generated from the same proto, while client sending the request to 
> server is getting 
> ```io.grpc.StatusRuntimeException: UNIMPLEMENTED: Method not found: 
> package.Servicename/method
> at io.grpc.Status.asRuntimeException(Status.java:526)
> at 
> io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:418)
> at 
> io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:41)
> at 
> io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:663)
> at 
> io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:41)
> at 
> io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:392)
> at 
> io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:443)
> at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:63)
> at 
> io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:525)
> at 
> io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$600(ClientCallImpl.java:446)
> at 
> io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:557)
> at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
> at 
> io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)```
>
> What may be happening wrong ? We checked almost everything that could be 
> checked
>
> 1. gRPC version
> 2. protobuff version
> 3. proto file
> 4. Java lib from proto file
> on both client and server and also
>
> 5. Server listening on the port after startup
>
> We are currently clueless on what should be done next. Any pointers are 
> appreciated.
>
> Rishi
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/1c04f0be-4635-447a-8bd1-5bf8126a3bbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: C fork() server->embedded Python->gRPC-python deadlock on method call

['Srini Polavarapu' via grpc.io]

Looks similar to https://github.com/grpc/grpc/issues/14258 . Have you tried 
setting GRPC_ENABLE_FORK_SUPPORT=FALSE as described in 
https://github.com/grpc/grpc/issues/14056 ?


On Monday, February 12, 2018 at 10:50:05 PM UTC-8, ascani...@gmail.com 
wrote:
>
>
> (gdb) py-bt
> #4 Waiting for a lock (e.g. GIL)
> #11 Frame 0x30654e0, for file 
> /usr/local/lib/python2.7/site-packages/grpc/_channel.py, line 475,
>  in _blocking (self=<_UnaryUnaryMultiCallable(_managed_call= remote 0x3080320>, _request_serializer= hod_descriptor at remote 0x2f40ab8>, _channel= at remote 0x2ffde10>, _response_deseriali
> zer= remote 0x2eec1c0>, _method='/
> Service/Retrieve') at remote 0x307cbd0>, request= remote 0x3080230>, ti
> meout=None, metadata=None, credentials=None, state=<_RPCState(code=None, 
> due=set([0, 1, 2, 4, 5, 6]), callbacks=[], 
> trailing_metadata=None, cancelled=False, initial_metadata=None, 
> response=None, condition=<_Condition(_Condition__loc
> k=<_RLock(_Verbose__verbose=False, _RLock__owner=None, 
> _RLock__block=, _RLock__coun
> t=0) at remote 0x307cc90>, acquire=, 
> _is_owned= self._method, None, deadline)
>
>
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/7d34b9d7-13f7-4c8f-bac0-5cd5647157a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: What is up with the extremely poor C# performance throughput benchmarks?

[ourtexasinc]

I've also opened another Issue on protobuf github related to C# ByteString 
implementation and how this is killing my throughput due to excessive 
garbage collection.
https://github.com/google/protobuf/issues/4206

Wonder if anyone else has run into similar obstacle...

On Friday, February 3, 2017 at 11:57:06 AM UTC-6, Peter Tiedemann wrote:
>
> I was looking over the benchmarks here (1.0.0, master does not seem to 
> work):
>
>
> https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5712453606309888
>
> Mostly, it seems sensible enough, C++ is fastest, Java and C# roughly 
> tied. Then i took a look at the throughput tests, where Java shows ~10x 
> more QPS, leaving C# closer to Python and Node.
>
> Is there some performance issue with the C# implementation i need to be 
> aware of?
>
>
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/08fb2a5e-d216-4ce2-bbf0-3b4025a8dd44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: What is up with the extremely poor C# performance throughput benchmarks?

[ourtexasinc]

I am running into pretty severe throughput issues with both C# and C++ grpc 
on Windows.

I've opened an Issue here which describes what I am seeing and has sample 
code for both Windows and Linux: 
https://github.com/grpc/grpc/issues/14378

I am seeing drastically better throughput numbers on Linux as compared with 
Windows running exactly the same app code.

I wonder if anyone else can help me understand what I am doing wrong or 
whether grpc on Windows is just not being optimized as much as on Linux?

On Friday, February 3, 2017 at 11:57:06 AM UTC-6, Peter Tiedemann wrote:
>
> I was looking over the benchmarks here (1.0.0, master does not seem to 
> work):
>
>
> https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5712453606309888
>
> Mostly, it seems sensible enough, C++ is fastest, Java and C# roughly 
> tied. Then i took a look at the throughput tests, where Java shows ~10x 
> more QPS, leaving C# closer to Python and Node.
>
> Is there some performance issue with the C# implementation i need to be 
> aware of?
>
>
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/7f88f33e-800a-433f-8a8b-fcac0787d58f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Server side transport keepalive in C++

[Arpit Baldeva]

What you need to use is the GRPC_ARG_MAX_CONNECTION_IDLE_MS option. 
However, that option is currently buggy. Before 1.9.0, it could cause a 
crash and starting 1.9.0, it could cause memory leak if enabled. See this 
issue - https://github.com/grpc/grpc/pull/13594 

On Saturday, February 10, 2018 at 6:27:38 PM UTC-8, deepako...@gmail.com 
wrote:
>
> Hi,
>
> I am using gRPC C++ async server for single/unary RPC. One of the problems 
> I noticed is that if a client disappears after making successful RPC 
> call(s) i.e. client doesn't gracefully shutdown the transport, server keeps 
> the transport  open forever.  I am looking at the TCP connection on server 
> and it remains open forever. Since gRPC library doesn't expose underlying 
> transport to the application, is there any knob that can allow server to 
> close such stale TCP connections?
>
> I did try to use GRPC_ARG_KEEPALIVE_TIME_MS but no luck. I tried changing 
> the greeter_async_server.cc in example/cpp/helloworld as follows:
>
> ServerBuilder builder;
> // Listen on the given address without any authentication mechanism.
> builder.AddListeningPort(server_address, 
> grpc::InsecureServerCredentials()/*grpc::SslServerCredentials(sslCredentialsOptions)*/);
> // Register "service_" as the instance through which we'll communicate 
> with
> // clients. In this case it corresponds to an *asynchronous* service.
> builder.RegisterService(&service_);
> // Get hold of the completion queue used for the asynchronous 
> communication
> // with the gRPC runtime.
> cq_ = builder.AddCompletionQueue();
> builder.AddChannelArgument(GRPC_ARG_KEEPALIVE_TIME_MS, 2);
> <
> builder.AddChannelArgument(GRPC_ARG_KEEPALIVE_TIMEOUT_MS, 1);  
>   <
> builder.AddChannelArgument(GRPC_ARG_HTTP2_BDP_PROBE, 1);  
> <
> //builder.AddChannelArgument(GRPC_ARG_KEEPALIVE_PERMIT_WITHOUT_CALLS, 
> 1);
> // Finally assemble the server.
> server_ = builder.BuildAndStart();
> std::cout << "Server listening on " << server_address << std::endl;
>
> Test Run:
> 
> bash-4.2$ ./greeter_async_server &
> [1] 9592
> bash-4.2$ Server listening on 0.0.0.0:50051
>
> TCP:
> ---
> bash-4.2$ ss -antp | grep async
> LISTEN 0  128 :::50051   :::*  
>  users:(("greeter_async_s",pid=9592,fd=4))
> bash-4.2$
>
>
> RPC call from client:
> ---
> bash-4.2$ Server listening on 0.0.0.0:50051
> Processing call
>
> Client disappeared but transport remains open forever:
> -
> bash-4.2$ ss -antp | grep async
> LISTEN 0  128 :::50051   :::*  
>  users:(("greeter_async_s",pid=9592,fd=4))
> ESTAB  0  0 :::172.23.137.19:50051  
> :::172.23.142.2:59686  
>  users:(("greeter_async_s",pid=9592,fd=7))
> bash-4.2$ ss -antp | grep async
> LISTEN 0  128 :::50051   :::*  
>  users:(("greeter_async_s",pid=9592,fd=4))
> ESTAB  0  0 :::172.23.137.19:50051  
> :::172.23.142.2:59686  
>  users:(("greeter_async_s",pid=9592,fd=7))
> bash-4.2$
>
>
> Regards,
> Deepak
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/73ac3054-5650-48ec-a04f-8742dd9cb6dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [GSoC 2018] Will grpc-go team participate in this year's GSoC?

['April Kyle Nassi' via grpc.io]

Hello! We welcome all proposals - so please do share your idea when
proposals are open!




*April Kyle Nassi, Program Manager*

Google, Inc. | Open Source Strategy | Developer Relations

345 Spear Street, San Francisco, CA 94105


ana...@google.com | @thisisnotapril 





On Mon, Feb 12, 2018 at 11:48 PM He Yu  wrote:

> Hi
>
> I've just learned that gRPC is accepted as a mentoring organization in
> this year's Google Summer of Code 2018 and read through the idea lists
> .  But I
> can only find ideas from grpc-core and grpc-python.
>
> As I have some background in Go, and I am interested in contributing to
> this project and the grpc community, I'm wondering if there will be any
> plan from the grpc-go team to list their ideas.
>
> Or in another way, if I come out with some custom ideas, will they be
> appreciated?
>
>
> Thanks.
>
>
> --
> 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 grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/c3c84f9a-fdae-42bf-8939-5f2755418592%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAAgWDxKdCG2j%2BsURfcdSVJCtWZfuU7fErqL2%2B2XttUJTBP%2BmZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC via USB

[bansheee1337 via grpc.io]

Hey,

is it possible to somehow use gRPC with USB, be it with 3rd party 
implementations? The bandwith limitation of Gigabit Ethernet is an issue 
for us and we'd like to achieve the data rates of a USB connection for big 
data types.

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/bee0c57c-8b74-4c5c-8e61-b56e1357%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Getting UNIMPLEMENTED with Java client and server with protobuff 3.4 and grpc 1.8.0

[Hrishi Joshi]

We have a java based gRPC server and client. Both using version 1.8.0.
After verifying both client and the server have the same proto file and 
java lib generated from the same proto, while client sending the request to 
server is getting 
```io.grpc.StatusRuntimeException: UNIMPLEMENTED: Method not found: 
package.Servicename/method
at io.grpc.Status.asRuntimeException(Status.java:526)
at 
io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:418)
at 
io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:41)
at 
io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:663)
at 
io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:41)
at 
io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:392)
at 
io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:443)
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:63)
at 
io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:525)
at 
io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$600(ClientCallImpl.java:446)
at 
io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:557)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at 
io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)```

What may be happening wrong ? We checked almost everything that could be 
checked

1. gRPC version
2. protobuff version
3. proto file
4. Java lib from proto file
on both client and server and also

5. Server listening on the port after startup

We are currently clueless on what should be done next. Any pointers are 
appreciated.

Rishi

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/331d73eb-730d-46d1-8e32-959276e4d07d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gRPC stream error handling

[Glyn Normington]

I'm trying to decide how to handle stream errors correctly, both in the 
client and in the server. My working assumption, in Go, is that io.EOF 
indicates 
a normal termination and that all other errors are abnormal and permanent, 
but I'd like to check that assumption.

It would be great to know which gRPC errors are permanent and which, if 
any, are transient. The Go Stream 
 interface talks about 
streams being "done" or "aborted" (both of which sound like permanent 
states), but without defining these terms further.

The available example code isn't particularly useful as it's not clear 
which parts are normative.

The gRPC documentation has a section on error handling 
, but this doesn't describe which 
errors are permanent and which are transient. It's not even clear how the 
status codes described map to language-specific error values. For instance, 
which value(s) corresponds to io.EOF (surely a permanent error!) in Go?

Please could someone offer some definitive information?

Regards,
Glyn



-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/df2e12d6-faac-400f-be2f-78c9f5502555%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [GSoC 2018] Will grpc-go team participate in this year's GSoC?

[Ihor Dvoretskyi]

An extra note: CNCF has been recently approved as an officially
participating organization in GSoC 2018 -
https://summerofcode.withgoogle.com/organizations/6453865516367872/.

On Tue, Feb 13, 2018 at 9:48 AM, He Yu  wrote:

> Hi
>
> I've just learned that gRPC is accepted as a mentoring organization in
> this year's Google Summer of Code 2018 and read through the idea lists
> .  But I
> can only find ideas from grpc-core and grpc-python.
>
> As I have some background in Go, and I am interested in contributing to
> this project and the grpc community, I'm wondering if there will be any
> plan from the grpc-go team to list their ideas.
>
> Or in another way, if I come out with some custom ideas, will they be
> appreciated?
>
>
> Thanks.
>
>
> --
> 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 grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/grpc-io/c3c84f9a-fdae-42bf-8939-5f2755418592%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2BhxP0vS3UVZ3a7V2rPSLV9XB9_a%2BY-u%3DbchQS5oW7ZPHY27GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.