Have worked out what the issue is. GRPC 1.0.0 and 1.0.1 are both based on
Netty 4.1.3.Final. This version of Netty is affected by a memory leak bug
referenced and fixed in the following commit:
https://github.com/netty/netty/commit/94d7557dead5e7780769d44bbb4aa7530149ca34
The vanilla GRPC
Its the difference between "/service/method" (a fixed string identifying
the operation - RPC) and /collection/{resource-id} (where a parameter of
the call is a variable component of the REST path). Using fixed strings
speeds up dispatching logic and on HTTP2 improves header caching behaviors.
On
Hi
I am reading gRPC FAQ "Why is gRPC better/worse than REST?" The answer says
"We diverge from typical REST conventions as we use static paths for
performance reasons during call dispatch as parsing call parameters from
paths, query parameters and payload body adds latency and complexity."
That sounds like a good summary of the complications with XP. We have no
plans to support the platform, especially since it's well past end of life.
On Wed, Oct 19, 2016 at 8:39 AM Amit Waisel wrote:
> I am trying to compile the C++ code for XP platform. I know it is not
>
I am trying to compile the C++ code for XP platform. I know it is not
officially supported. By changing the _WIN32_WINNT to 0x501 in
global.props, I get many errors:
1. Using RTL_RUN_ONCE API which is supported Vista+ only
2. Support for IPv6 (inet_ntop at
Hi,I am using JAVA
--
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
We have just encountered the same issue, been in production for about a
week, exactly the same leak. We have just started investigating. Will let
you know how we go.
Cheers
Craig
On Wednesday, September 28, 2016 at 8:26:34 AM UTC+8, Taehyun Park wrote:
>
> Hello I have a memory leak problem
In one part of my C++ app, I'm using gRPC as IPC to control a server
daemon. When the daemon is not running, there's nothing listening on the
designated port.
Nevertheless, the client call is bounded by the deadline. Shouldn't the
call fail immediately if there is no port listening ?
This