Hi Louis,
Thank you for the milestones information, and am comfortable to hear that
more options are being evaluated for engaging users with the progress.
Some of the milestones make sense, but some feel like tickets on issues,
and the Jenkins ones I do not believe fall under user features.
In the past I've used haproxy to load balance all sorts of things.
I would imagine a TCP based load balancing would be sufficient to ensure
high availability.
Has anyone tried this or has any advice on this matter?
TIA
--
You received this message because you are subscribed to the Google
Remember there's no such thing as bad feedback. We want to know how it
works for you based on your typical usage case.
On Wed, Jul 27, 2016 at 5:49 PM, 'Kailash Sethuraman' via grpc.io <
grpc-io@googlegroups.com> wrote:
>
> At the moment, the website (grpc.io) documentation not fully reflect the
At the moment, the website (grpc.io) documentation not fully reflect the
pre-release. They reference the last full release, 0.15.
I would recommend something in-between both the paths you mention. Try
these packages in your test environments as you normally would, see if it
works and report any
Paul,
On Wed, Jul 27, 2016 at 10:00 AM, Paul Grosu wrote:
>
> I understand the need, but rushing things with a complex programming
> project such as this does not always translate into quality. With this
> project I would prefer Google to take their time to do it right. The
Hi Kailash,
This is fantastic news! Big Congratulations to the whole team!
Just wondering how thoroughly should we test these releases? Basically
should we put:
- A naive user hat (i.e. let me find the documentation and follow it),
or
- An expert user hat (i.e. let me tweak the
A step function like that is pretty odd. What kind of payload are you
using? Just to isolate that out could you benchmark your message
serialization for the same range of sizes?
As a general rule I would expect to see a benchmark of sequential
request/responses with 'typical' 1k protobufs between
Hi Everyone,
The gRPC team is pleased to announce that we have our first 1.0-pre
packages ready for testing. Instructions and release notes below.
Please give these a try and report any issues via our issue trackers on
Github, it will help ensure that our 1.0 release is robust and works
Hi, i'm trying to close all tcp / http2 connexions for a gRPC objective-c
client for when my app goes in background (i want absolutely 0 activity in
this case). Calling "cancel" on the GRPCall closes ongoing gRPC streams,
but doesn't close the underlying tcp connexion (i guess because reusing
Thanks Louis - appreciated.
On Tuesday, July 26, 2016 at 8:08:18 PM UTC-6, Louis Ryan wrote:
>
> Currently the GRPC server won't port share with your servlet engine which
> may or may not be a consideration for you. GRPC does not use classloader
> magic so you're unlikely to have issues
I understand the need, but rushing things with a complex programming
project such as this does not always translate into quality. With this
project I would prefer Google to take their time to do it right. The gRPC
team are doing fantastic service, but already they feel way too stretched
out
Thanks for the replies.
Initially my main uses will be in Java, Node, and C#.
On Tuesday, July 26, 2016 at 8:32:35 PM UTC-7, Nathaniel Manista wrote:
>
> On Tue, Jul 26, 2016 at 8:56 AM, wrote:
>
>> I know that different parts of gRPC are more mature than others but in
>>
12 matches
Mail list logo