Hi Kun,
Based on your input, once a new server (server 3 listening on 9097, once it
is ready, LB will be notified and updated, however I see from the log,
server3 is in ready state, but the request is never routed to server3, can
you please suggest where should I look into the issue? Thanks a
Got it! Thanks a lot
On Thursday, January 17, 2019 at 2:35:54 PM UTC-8, Kun Zhang wrote:
>
> You don't need to worry about the timing. As soon as the Subchannel
> becomes ready, RoundRobinLoadBalancer should notice that by yet another
> call to updateBalancingState() and add it to the
Hi Kun,
I am trying to debug further, in
io.grpc.util.RoundRobinLoadBalancerFactory::handleResolvedAddressGroups
will be called if the NameResolver.Listener::onAddress is called,
inside handleResolvedAddressGroups method, it is calling
updateBalancingState(getAggregatedState(),
Hi Kun,
I did see that the new server3 (listening on 9097) has its
InternalSubchannel gets created:
[io.grpc.internal.InternalSubchannel] (grpc-default-worker-ELG-3-9)
[io.grpc.internal.InternalSubchannel-20]
io.grpc.netty.NettyClientTransport-21 for localhost/127.0.0.1:9097 is ready
Hi Kun,
please see the logs below:
[io.grpc.internal.ManagedChannelImpl] (pool-3-thread-1)
[io.grpc.internal.ManagedChannelImpl-4] Created with target
a_ECHOSERVICE_echo_1_0_3
[io.grpc.internal.ManagedChannelImpl] (pool-3-thread-1)
[io.grpc.internal.ManagedChannelImpl-4] Created with
Hi Kun,
please see log below
[io.grpc.internal.ManagedChannelImpl] (pool-3-thread-1)
[io.grpc.internal.ManagedChannelImpl-4] Exiting idle mode
[io.grpc.internal.ManagedChannelImpl] (pool-3-thread-1)
[io.grpc.internal.ManagedChannelImpl-4] Exiting idle mode
Hi Eric,
one more question, when the subchannel gets updated from a channel, how
about the Streams that is created from the channel? I assume that the
stream is for a particular tcp connection, meaning a particular subchannel?
On Tuesday, January 15, 2019 at 10:04:09 AM UTC-8,
Hi Eric,
Thanks a lot for the reply, actually I do have my custom NameResolver, and upon
changes for the server list, NameResolver will be notified. And I do have the
RoundRobinLoadBalancer
configured, please see code below.
ManagedChannel channel = ManagedChannelBuilder.forTarget(...)
Hi Kun,
please see below the logs from the gRPC client, so server1 (localhost:9095)
is running first, then the client start making requests, afterward, I
started up server2 (localhost:9096), then I see the following logs, and the
request is not sent to server2.
Hi Eric,
Thanks for the reply, but I only enabled ping on client side, and only
configured server to allow client sending pings, but the server is not
configured to send pings.
On Thursday, January 10, 2019 at 5:07:09 PM UTC-8, Eric Anderson wrote:
>
> The client sends a keepalive ping after
Hi Kun,
Thanks for your reply, I did see that new SubChannel gets created for the
new server, do you mean that so long as the new server's subchannel gets
created, it should take effect immediately, meaning the new server should
also get the traffic?
Thanks a lot!
On Thursday, January 10,
Hi,
in my java gRPC client, when I create the ManagedChannel, I am passing my
custom NameResolver, and using RoundRobinLoadBalancer. When my NameResolver
is notified with a change to the server list (new server added), it will
call Listener.onAddress and pass the updated the list.
I see from
Hi,
I have enabled client side keepalive and also on the server side, enable
permission to send ping via NettyServerBuilder.permitKeepAliveTime(),
however, what I see from the wireshark, the keepalive ping seems to be
initiated from server side (gRPC server listens on 9096):
[image:
Hi Carl,
Thanks for the reply:
1. how do I kill the instances: docker stop the container of the gRPC
server. is this what you meant by 'pull the plug?'
2. when you say: DNS is pull based, so we implemented as a timer based
refresh, but it isn't desirable, so you mean the DNS refresh will be
Here is the test case:
I have implemented my custom NameResolver, and using RoundRobinLoadBalancer
in managedChannelBuilder.
1. initially has 4 instances running (serverA, serverB, serverC, serverD)
2. then kill 2 instances (serverC, serverD), then serverA and serverB
continues serving the
Hi,
My project uses gRPC bi-directional streaming call. We are not using grpc
LB, but have our own logic implemented to select which server. So when I
kill one of the server, client StreamObserver.onError is called and the
original message is lost.
I just wonder is there anyway to obtain
Hi Penn,
Thanks a lot! will take a look!
On Thursday, September 13, 2018 at 2:55:52 PM UTC-7, Penn (Dapeng) Zhang
wrote:
>
>
>
> On Thursday, September 13, 2018 at 2:03:36 PM UTC-7, eleano...@gmail.com
> wrote:
>>
>> Hi
>>
>> my current project is using gRPC (*java*) for service
Hi
my current project is using gRPC (*java*) for service communications. We
have our own way of authenticate and authorize the client request. Reading
from https://grpch
*Q1: is this the interface that I should implement?*
public interface CallCredentials {}
*Q2: given the code example in
Hi Eric,
Thanks a lot, I got it!
On Friday, August 24, 2018 at 3:34:49 PM UTC-7, Eric Anderson wrote:
>
> On Fri, Aug 24, 2018 at 9:05 AM > wrote:
>
>> If I understand you correctly, at certain point in time, there will only
>> be 1 thread processing the callback, and there will NEVER be
Hi Eric,
Thanks a lot for the explanation. If I understand you correctly, at certain
point in time, there will only be 1 thread processing the callback, and
there will NEVER be multiple threads processing the callbacks concurrently.
If this is the case, what is the point of having the
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
Hi Carl,
It is hard to show my code as I have a wrapper API on top of grpc.
However, are you suggesting that using 1 tcp connection per stream should
be faster than using 1 tcp connection for all streams?
On Monday, August 20, 2018 at 11:14:43 AM UTC-7, Carl Mastrangelo wrote:
>
> Can you
Hi,
I would like to use the grpc java load balancing library, I looked at the
example code, it looks like below:
public HelloWorldClient(String zkAddr) {
this(ManagedChannelBuilder.forTarget(zkAddr)
.loadBalancerFactory(RoundRobinLoadBalancerFactory.getInstance())
The single connection time for the whole process is about 2.75 sec, and the
multiple connection time is about 3.5 sec. I run this test multiple times,
and the single connection is always a bit faster than the multiple
connections
On Saturday, August 18, 2018 at 8:37:22 PM UTC-7, Srini
Hi Srini,
The way how I do it:
for single connection:
1. send 1 request via request StreamObserver, to let initial connection
established
2. start the timer, send 1 requests
3. end the timer when see all results from the response
StreamObserver.onNext() that the client passed to the
Hi Carl,
Thanks for the very detailed explanation! my question is why I observed
using a separate TCP connection per stream was SLOWER!
If the single TCP connection for multiple streams are faster (Regardless
the reason), will the connection get saturated? e.g. too many streams
sending on
Hi Carl,
Thanks for the explanation, however, that still does not explain why using
single tcp for multiple streamObserver is faster than using 1 tcp per
stream.
On Friday, August 17, 2018 at 12:45:32 PM UTC-7, Carl Mastrangelo wrote:
>
> gRPC does connection management for you. If you
Thanks a lot for the clarification
On Friday, August 17, 2018 at 12:29:15 PM UTC-7, Carl Mastrangelo wrote:
>
> Yes, that is correct. Load Balancing is done on a per-call basis. Once
> an RPC has been assigned to a backend, it will continue on that backend.
>
> On Friday, August 17, 2018 at
Hi,
I just wonder how does gRPC LB handles the bi-directional stream? Once it
picks which server instance to serve the streaming request, then it will
continue the streaming request only with that particular server?
On Tuesday, July 31, 2018 at 11:30:41 AM UTC-7, Carl Mastrangelo wrote:
>
>
Hi,
I am doing some experiment with gRPC java to determine the right gRPC call
type to use.
here is my finding:
creating 4 sets of StreamObservers (1 for Client to send request, 1 for
Server to send response), sending on the same channel is slightly after
than sending on 1 channel per
Hi Eric,
Thanks a lot! Yes I indeed create a new channel everytime for the unary
call, after changing to use the same channel, I only see 1 tcp connection
created.
On Wednesday, August 8, 2018 at 9:47:53 AM UTC-7, Eric Gribkoff wrote:
>
> There should only be a single TCP connection when
sorry what do you mean?
On Tuesday, August 7, 2018 at 4:31:34 PM UTC-7, pizzas...@gmail.com wrote:
>
> Bvfdc
--
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
BTW, I am using grpc-java
On Tuesday, August 7, 2018 at 4:21:53 PM UTC-7, eleano...@gmail.com wrote:
>
>
> Hi,
>
> I am doing an experiment to decide whether my application should choose
> unary call, or bi-directional streaming. Here is what I observe by enable
> the debug logging:
>
> for
Hi,
I am doing an experiment to decide whether my application should choose
unary call, or bi-directional streaming. Here is what I observe by enable
the debug logging:
for unary call, the tcp connection is created per call:
client side single thread making 5 calls in a for loop: total 5
34 matches
Mail list logo
