Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [milo-dev] UnknownHostException for a host not used in connect

The host that Milo connects to is only ever derived from 2 places:

1. from the `endpointUrl` parameter passed to `OpcUaClient.create`, which it uses to call the GetEndpoints service
2. from the `endpointUrl` field of of the `EndpointDescription` in the config you provided

You are probably connecting to servers that have an unresolvable hostname in the endpoint URL returned by their GetEndpoints service. This is not uncommon. See https://stackoverflow.com/a/40555243/85927 for a relevant discussion.

On Thu, May 5, 2022 at 12:09 AM Lothar Kimmeringer <job@xxxxxxxxxxxxxx> wrote:
Hi,

We're (still) using Milo 0.5.4 and sometimes have an issue when
connecting to certain servers where an attempt lead to an exception
with the following (huge) stacktrace:

mypackage.services.ServiceException: an error occurred while trying to connect client
        at mypackage.services.iot.opcua.OpcUaSessionProvider.createClient(OpcUaSessionProvider.java:131)
        at mypackage.services.iot.opcua.OpcUaSessionProvider.createClient(OpcUaSessionProvider.java:79)
        at mypackage.services.iot.opcua.OpcUaSessionProvider.connect(OpcUaSessionProvider.java:66)
        at mypackage.services.iot.opcua.OpcUaSessionProvider.connect(OpcUaSessionProvider.java:1)
[...]
Caused by: java.util.concurrent.ExecutionException: java.net.UnknownHostException: company_data
        at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
        at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1908)
        at mypackage.services.iot.opcua.OpcUaSessionProvider.createClient(OpcUaSessionProvider.java:125)
        ... 36 more
Caused by: java.net.UnknownHostException: company_data
        at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
        at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
        at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
        at java.net.InetAddress.getAllByName0(InetAddress.java:1277)
        at java.net.InetAddress.getAllByName(InetAddress.java:1193)
        at java.net.InetAddress.getAllByName(InetAddress.java:1127)
        at java.net.InetAddress.getByName(InetAddress.java:1077)
        at io.netty.util.internal.SocketUtils$8.run(SocketUtils.java:146)
[...]
        at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
        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:474)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:909)
        ... 1 more

The host "company_data" is not the host configured to connect to; there we've
used something like opc:tcp://123.456.789.012:4840. When connecting to
that server using a different opc-client, it seems that this value comes from
the property NamespaceArray or ServerArray, where this appears in some of the URNs,
e.g. for an entry in the NamespaceArray: urn:company_data/BR/UA/EmbeddedServer or
the ServerArray's entry (there is only one): urn:company_data/BR/UA/EmbeddedServer.

Why is Milo trying to connect to an URN (as it seems to)? URNs aren't
providing a location so connecting to it seems wrong to me. In past
occasions it was possible to work around this by adding an entry to
the host-file to resolve this "server name" but in one particular case
this is not an option due to OSI 8/9 limitations. Is this fixed in
0.6 (and is this version "compatible" to implementations using 0.5)
or should I open an issue about this on GitHub?


Thanks and cheers, Lothar
_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/milo-dev

Back to the top