Hi carl,Thanks for the invaluable replies. Regards, Isuru On Wed, 15 Aug 2018, 2:56 am 'Carl Mastrangelo' via grpc.io, < [email protected]> wrote:
> Hmm, that should not be used, I might have to send a PR to the author. > > I don't know why you always get the same backend. I'm afraid I would have > to see a reproducing case before I could say with any authority why it's > happening. > > On Monday, August 13, 2018 at 6:18:12 PM UTC-7, Isuru Samaraweera wrote: >> >> Hi Carl, >> I got the above example from a sample code from google author it self >> where they use DNS factory. >> >> https://github.com/saturnism/grpc-java-by-example/blob/master/kubernetes-lb-example/echo-client-lb-dns/src/main/java/com/example/grpc/client/ClientSideLoadBalancedEchoClient.java >> >> Do you have a sample code for picker#subchannel because we are running >> out of time for delivery.Surely I 'll do Rn D in this picker/subchannel >> once our imminent delivery is completed. >> >> Thanks >> >> On Mon, Aug 13, 2018 at 10:54 PM, 'Carl Mastrangelo' via grpc.io < >> [email protected]> wrote: >> >>> Responses inline >>> >>> On Friday, August 10, 2018 at 7:40:25 PM UTC-7, Isuru Samaraweera wrote: >>>> >>>> Hi Carl, >>>> Thanks for the reply.Due to timeline constraints I switch back to round >>>> robin default dns solver as below.It is serving the purpose for the current >>>> work load.In future surely I ll do further R n D on Eureka considering your >>>> inputs as well.Here is the code I fallabacked to. >>>> >>>> ManagedChannelBuilder.forTarget(grpcHostTmp.getHost() + ":" + >>>> grpcHostTmp.getPort()) >>>> .nameResolverFactory(new >>>> DnsNameResolverProvider()).executor(messagingThreadPoolExecutor) >>>> >>> >>> I would avoid using DnsNameResolverProvider. It's in our >>> io.grpc.internal package, which means we can make breaking changes to that >>> API. Also, DnsNameResolver is the default name resolver, so there is no >>> need to specify it. >>> >>> >>> >>>> >>>> .loadBalancerFactory(RoundRobinLoadBalancerFactory.getInstance()).usePlaintext(true).build()); >>>> >>>> >>>> Is there anyway to load balance requests evenly across nodes with >>>> DnsNameResolverProvider .Rightnow whats happening is till a node is going >>>> down same node takes the load after that node goes down next node takes the >>>> load. You can see the implementation in >>>> RoundRobinLoadBalancerFactory.Picker#nextSubchannel(). >>>> >>> >>> Are you using streaming RPCs, or unary? Streaming RPCs can't change >>> their backend once started, but every new RPC can. RoundRobinLoadBalancer >>> should pick a new backend for every single RPC. >>> >>> >>>> >>>> Is there a way to rotate requests as in active active mode rather than >>>> above active passive mode. >>>> >>> >>> I think you may be using PickFirstLoadBalancer which has that behavior. >>> >>> >>>> >>>> I am looking for a grpc built in solution without 3rd party eureka ,zoo >>>> keeper.Or Do you have plans to incorporate better load balancing apis to >>>> the grpc core libs?? >>>> >>> >>> We keep most things out of the core library because not everyone needs >>> them. We do promote other implementations of gRPC components here: >>> https://github.com/grpc-ecosystem >>> >>> >>>> >>>> Thanks, >>>> Isuru >>>> >>>> >>>> On Fri, Aug 10, 2018 at 10:41 PM, Carl Mastrangelo <[email protected]> >>>> wrote: >>>> >>>>> I believe you need to create the InetSocketAddress from an IP address, >>>>> rather than a host name. Typically host names are looked up via DNS (not >>>>> sure what Eureka returns to you). If you use the normal >>>>> InetSocketAddress >>>>> constructor, Java will do the DNS lookup for you. >>>>> >>>>> (It is also possible to not use Java's DNS resolver, but that's more >>>>> complex. I'd avoid it until you know you need it) >>>>> >>>>> On Thu, Aug 9, 2018 at 11:28 PM Isuru Samaraweera <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Carl, >>>>>> Thanks for the reply.However when I do the eureka address lookup >>>>>> ,lookup seems fine.But at the time stub method is invoked asynchronously >>>>>> below error pops up. >>>>>> >>>>>> Caused by: java.nio.channels.UnresolvedAddressException >>>>>> at sun.nio.ch.Net.checkAddress(Net.java:101) >>>>>> at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:622) >>>>>> at io.netty.util.internal.SocketUtils$3.run(SocketUtils.java:83) >>>>>> at io.netty.util.internal.SocketUtils$3.run(SocketUtils.java:80) >>>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>>> at io.netty.util.internal.SocketUtils.connect(SocketUtils.java:80) >>>>>> at io.netty.channel.socket.nio.Ni >>>>>> oSocketChannel.doConnect(NioSocketChannel.java:310) >>>>>> at >>>>>> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:254) >>>>>> at >>>>>> io.netty.channel.DefaultChannelPipeline$HeadContext.connect(DefaultChannelPipeline.java:1366) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:545) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:530) >>>>>> at >>>>>> io.netty.handler.codec.http2.Http2ConnectionHandler.connect(Http2ConnectionHandler.java:461) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:545) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext.connect(AbstractChannelHandlerContext.java:530) >>>>>> at >>>>>> io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:50) >>>>>> at >>>>>> io.grpc.netty.ProtocolNegotiators$AbstractBufferingHandler.connect(ProtocolNegotiators.java:466) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext.invokeConnect(AbstractChannelHandlerContext.java:545) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext.access$1000(AbstractChannelHandlerContext.java:38) >>>>>> at >>>>>> io.netty.channel.AbstractChannelHandlerContext$11.run(AbstractChannelHandlerContext.java:535) >>>>>> at >>>>>> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) >>>>>> at >>>>>> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404) >>>>>> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:465) >>>>>> at >>>>>> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) >>>>>> at >>>>>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>>>>> >>>>>> >>>>>> >>>>>> I do the lookup as below . >>>>>> >>>>>> Application application = eurekaClient.getApplication(serviceName); >>>>>> List<EquivalentAddressGroup> servers = new ArrayList<>(); >>>>>> for (InstanceInfo serviceInstance : application.getInstances()) { >>>>>> servers.add(new EquivalentAddressGroup( >>>>>> InetSocketAddress.createUnresolved(serviceInstance.getHostName(), >>>>>> serviceInstance.getPort()))); >>>>>> } >>>>>> listener.onAddresses(servers, Attributes.EMPTY); >>>>>> >>>>>> >>>>>> Lookup looks up addressed properly. >>>>>> >>>>>> Do you have any clue on why above exception is thrown when stub >>>>>> method is invoked?? >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 10, 2018 at 3:24 AM, 'Carl Mastrangelo' via grpc.io < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> It is safe to share the channel. The decision of which server is >>>>>>> actually up to the load balancer, and it will correctly stop sending >>>>>>> traffic to a server if the connection fails. >>>>>>> >>>>>>> On Thursday, August 9, 2018 at 8:56:08 AM UTC-7, Isuru Samaraweera >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I am trying to use Eureka as a discovery server and do roundrobin >>>>>>>> clientside load balancing in the grpc client level.I have 3 GRPC server >>>>>>>> nodes registered in Eureka. >>>>>>>> >>>>>>>> Here is the way I create a ManagedChannel in the client. >>>>>>>> >>>>>>>> EurekaClientConfig eurekaClientConfig = new >>>>>>>> DefaultEurekaClientConfig(); >>>>>>>> ManagedChannel channel = ManagedChannelBuilder >>>>>>>> .forTarget("eureka://" + >>>>>>>> "service-aeroline-passenger-messaging") >>>>>>>> .nameResolverFactory(new >>>>>>>> EurekaNameResolverProvider(eurekaClientConfig, "9071")) >>>>>>>> >>>>>>>> .loadBalancerFactory(RoundRobinLoadBalancerFactory.getInstance()) >>>>>>>> .usePlaintext(true) >>>>>>>> .build(); >>>>>>>> >>>>>>>> My question is is it ok to create one channel and share across the >>>>>>>> client application presuming that channel rotation across various >>>>>>>> nodes of >>>>>>>> GRPC server is taken care by >>>>>>>> the ManagedChannel it self. i.e if server1 goes down does the >>>>>>>> channel automatically diverted to server2 without creating a new >>>>>>>> channel >>>>>>>> object??? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Isuru >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to a topic in >>>>>>> the Google Groups "grpc.io" group. >>>>>>> To unsubscribe from this topic, visit >>>>>>> https://groups.google.com/d/topic/grpc-io/7g4PAv_7Clo/unsubscribe. >>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>> [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> 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/4460b577-ebd2-40d5-aa1f-182a1f4af411%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/grpc-io/4460b577-ebd2-40d5-aa1f-182a1f4af411%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Isuru Samaraweera >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Isuru Samaraweera >>>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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/65c00c3a-b675-4944-9583-8225f3d0cbe8%40googlegroups.com >>> <https://groups.google.com/d/msgid/grpc-io/65c00c3a-b675-4944-9583-8225f3d0cbe8%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Isuru Samaraweera >> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/d35e5be6-e6f5-4251-958a-929e98a51751%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/d35e5be6-e6f5-4251-958a-929e98a51751%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To post to this group, send email to [email protected]. 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/CAOtGh-o3x_WJ7WewXAUD9cF__fGaDJEa%3DbpJHqbVgMj8_Viqww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
