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.NioSocketChannel.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-me
>> ssaging")
>>                 .nameResolverFactory(new 
>> EurekaNameResolverProvider(eurekaClientConfig,
>> "9071"))
>>                 .loadBalancerFactory(RoundRobi
>> nLoadBalancerFactory.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/to
> pic/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/ms
> gid/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

-- 
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-pham%2Bb%3DqoJADP5GH%2BH1nayUNms7VbZ9JryEAivXcD%3D1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to