oes this change should go? Even we are facing issue with heavy
> payload and would like to resolve it.
>
> On Monday, 22 August 2016 00:43:42 UTC+5:30, Stephen Haberman wrote:
>>
>> Okay, apologies for the self-replies, but I've got it working with an
>> interceptor
Ironically, I have a grpc-java project that uses a long-lived, two-way
stream, but I had to add manual, ping-based health checks to detect
disconnections.
I am anticipating/assuming eventually grpc will handle this, but for me
neither the server or client side would notice when the connection w
Cool, issue filed here:
https://github.com/grpc/grpc-java/issues/2196
Thanks!
- Stephen
On Wed, Aug 24, 2016 at 10:58 AM wrote:
> You should post an issue in the issue tracker.
>
> Good catch, by the way.
>
>
> On Sunday, August 21, 2016 at 2:13:42 PM UTC-5, Step
traffic), which exactly matches the client-sent
compression with essentially the same payload.
I naively still think it'd be cool/desirable for the server to
automatically match the client's compression, but IANAE. :-)
Thanks!
- Stephen
On Sun, Aug 21, 2016 at 8:47 AM Stephen Haberma
ers could still call serverCall.setCompression(...) to change that
(however you do that), but using the same encoding in the response as the
request seems like a more reasonable/less surprising default?
Thanks!
- Stephen
On Sat, Aug 20, 2016 at 2:48 PM Stephen Haberman
wrote:
> Hi,
>
> I'm
Hi,
I'm using grpc-java 1.0.0.pre2, and it seems like server-side/response
compression may not be working.
I'm making a synchronous call from a client, and sending ~40k objects, e.g.
FooRequest.newBuilder().addAllPaths(...40k...).build().
The server then collects it's own 40k objects (again path
