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] <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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. For more options, visit https://groups.google.com/d/optout.
