Do I understand the purpose of this framework wrong and why can't I get it running with Quarkus?

[Bevor]

Hello,
I came here because I had a problem with Quarkus rest client. Obviously the default rest client cannot deal with multiple A type entries which are returned by a DNS when fetching some (remote service) domain. See this example here: https://stackoverflow.com/questions/78304027/quarkus-restclient-dns-failover-on-multiple-a-type-ip-addresses. I thought at first, Stork can solve this.

So first question is, is Stork a framework which can handle this automatically or do I understand the purpose of this framework wrong?
The documentation says I only have to exchange the real URL with the stork-URL, add properties and the dependency: https://smallrye.io/smallrye-stork/2.6.0/quarkus/#the-client

If I understand the purpose right, why can't I get this running with Quarkus? Here is an example with DNS which does not work for me https://stackoverflow.com/questions/78316327/quarkus-and-smallrye-stork-cannot-find-dns. (Problem is describe there)
But to simplify, I also tried to just use the "static" functionality instead of DNS, but not even this works (see below).

Is this the only thing I have to do? https://smallrye.io/smallrye-stork/2.6.0/service-discovery/static-list/#dependency
If yes, I cannot even get this running with a public address like github.com. This is my application.properties:

quarkus.stork.my-test.service-discovery.type=static quarkus.stork.my-test.service-discovery.address-list=github.com

And this is how I use it in code:
testApi = RestClientBuilder.newBuilder() .baseUri(URI.create("stork://my-test")) .build(TestApiInterface.class);

With github.com I get HTTP 301, with other URLs I get Bad Request 400 and so on.

If I do this (although this probably does not make any sense), the behaviour is different again. For github.com I get 406 not acceptable then.

Stork stork = Stork.getInstance();
    Service service = stork.getService("my-test");
    ServiceInstance serviceInstance = service.selectInstance().await().atMost(Duration.ofSeconds(1));
    String url = "https://" + serviceInstance.getHost();

    testApi = RestClientBuilder.newBuilder()
        .baseUri(URI.create(url))
        .build(TestApiInterface.class);

What do I understand wrong here? Why can't Quarkus resolve the stork-URLs?

[aureamunoz]

Hi Bevor,

Thank you for reaching out.
Yes, you're right, Stork is the service discovery framework used by Quarkus RestClient under the hooks.

Have you tried with the default dns server? It should be used if you don't configure the dns-servers property. Are you sure the service is running in the 8443 port?

For static list service discovery yes, that's correct. The problem with github.com is that Stork is using a default port 80 and it's why you get the 301 error but the address resolution is been done correctly.

Here you can check some code:

• Dns quickstart
• Dns record type A test

[Bevor]

Hello, thanks for your answer. I tried with default DNS server, non-default DNS server. The service is running on 8443 and the connection works with default QuarkusRest client without problems. The problem is, that Quarkus Rest client cannot deal with multiple A type entries (if one is not reachable). So I tried this solution: https://smallrye.io/smallrye-stork/2.6.0/service-discovery/dns/ and my thought was that I just have to do this setup, with "stork://my-service/" s baseUri and it is possible without Consul. Is this correct?
But if I do that, I get the problems described here: https://stackoverflow.com/questions/78316327/quarkus-and-smallrye-stork-cannot-find-dns

[cescoffier]

Do you have the exception passed to handleResolutionFailure?

[cescoffier]

BTW, I've run tests with 8.8.8.8, and it worked fine.

[Bevor]

Sure, this is the stacktrace:

cause = {VertxException@21759} "io.vertx.core.VertxException: DNS query timeout for service.example.com."
 backtrace = {Object[7]@21773} 
 detailMessage = "DNS query timeout for service.example.com."
 cause = {VertxException@21759} "io.vertx.core.VertxException: DNS query timeout for service.example.com."
 stackTrace = {StackTraceElement[12]@21776} 
  0 = {StackTraceElement@21779} "io.vertx.core.dns.impl.DnsClientImpl$Query.lambda$null$0(DnsClientImpl.java:363)"
  1 = {StackTraceElement@21780} "io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:276)"
  2 = {StackTraceElement@21781} "io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:258)"
  3 = {StackTraceElement@21782} "io.vertx.core.impl.ContextInternal.lambda$runOnContext$0(ContextInternal.java:56)"
  4 = {StackTraceElement@21783} "io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)"
  5 = {StackTraceElement@21784} "io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)"
  6 = {StackTraceElement@21785} "io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)"
  7 = {StackTraceElement@21786} "io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)"
  8 = {StackTraceElement@21787} "io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)"
  9 = {StackTraceElement@21788} "io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)"
  10 = {StackTraceElement@21789} "io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)"
  11 = {StackTraceElement@21790} "java.base/java.lang.Thread.run(Thread.java:1583)"

Does your (working) example have a CNAME alias in DNS?

I also tried it with a public website (is port 80 or 443 then?) with no CNAME in DNS, but in both cases I get the same result, hmmm.

[Bevor]

OK, I think I know what is wrong now:
First of all, I opened all my local ports, so the timeout problem is gone (I still need to narrow it down which ports were exactly the problem).
Second, I have to create some Header Handler (implement org.eclipse.microprofile.rest.client.ext.ClientHeadersFactory) that extends the header by "Host: service.example.com". This is needed, because otherweise the request runs into a "wrong location" or in other words, it is like invoking the IP in browser (and obviously it doesn necessarily mean that the "real" website is the landing page)

The basic problems are solved now. Thanks for your support.

[aureamunoz]

You can check this project based in the stork-dns-quickstart with a mvn service correctly resolved