DNS timeout check about eet-client HOT 13 CLOSED

Díky za test! Ono se toho při tom ověření neděje mnoho. Zato Java sama o sobě provádí ve třídě InetAddress poměrně hodně, včetně synchronizace vláken. Bylo by možné test zopakovat ještě jednou, jen místo dig použít javu napřímo? Třeba jen jednoduchou utilitku typu:

import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.concurrent.TimeUnit;

public class Application {
    public static void main(String[] args) {
        final String host = args[0];
        final long start = System.nanoTime();
        try {
            InetAddress address = InetAddress.getByName(host);
            final String ip = address.getHostAddress();
            System.out.println(host + " -> " + ip);
        } catch (UnknownHostException e) {
            System.err.println("Failed to lookup " + host);
        } finally {
            final long stop = System.nanoTime();
            System.out.println("Lookup took " + TimeUnit.NANOSECONDS.toMillis(stop - start) + " ms");
        }
    }
}

Zatím bohužel nemám, čeho bych se chytil a co bych mohl upravit.

Díky,
Tomáš

from eet-client.

Tim testem jsem chtel naznacit, ze problem neni v lookup hostname potazmo problemu se siti, ale v samotne jave. Kod mohu vyzkouset, nicmene spise podezrivam konkretne tu cast kodu samotheno executoru a jeho vytvareni vlaken obzvlaste pokud to bezi pod JVM celeho kontejneru a kde neni zrejme s jakou prioritou je to vlakno pusteno, sychronizovano ap., ale jak pisete, mozna i samotne trida InetAdress muze lagovat.
Tady je primo reseni od Oracle coz je hodne podobne tomu Vasemu.
Napada me jeste takove reseni nastavit system prop networkaddress.cache.ttl=-1 viz InetAddress tim by mel stacit prvni uspesny lookup a dale by uz k blokovani DNS nedoslo a vytimeoutovalo by to az v samotne WS. Ale nicmene jsem si vsiml, ze produkcni eet ukazuje na vice IP adres, ktere pravdepodbne vraci podle aktualniho vytizeni.

from eet-client.

Produkční endpoint EET je za load-balancerem, dlouhodobé cachování IP by tak byla asi chyba.

Souhlasím, že problém může být v Javě a overheadu, který přidávají vlákna. Pak ale taková aplikace nejspíš běží na hraně zdrojů, nebo ne?

Jak dál? Doplníme nějaké logování, abychom zjistili, jestli to brzdí samotný lookup a třída InetAddress nebo executor a vlákna?

Máte změřeno, za jakou dobu se vykoná celé odeslání a přečtení odpovědi? Je to očekávaných několik sekund nebo znatelně víc?

Díky!
Tomáš

from eet-client.

Zde mam nejake vysledky testovani. Nechal jsem soubezne bezet kazdou minutu a testoval query time pomoci dig a Vasi java test aplikace. Ve vetsine pripadu jsou ty casy +- stejne nicmene java app za dobu asi 1.5dne vykazala cca 4 excesy. Ukazka nejhorsich casu dig:

02-22 23:03|598
02-22 15:47|603
02-22 15:45|609
02-21 14:59|671
02-22 16:57|707
02-21 15:53|744
02-22 14:12|807

java:

prod.eet.cz -> 5.145.105.132 Lookup took 748 ms
prod.eet.cz -> 5.145.105.133 Lookup took 750 ms
prod.eet.cz -> 5.145.105.132 Lookup took 802 ms
prod.eet.cz -> 5.145.105.132 Lookup took 3964 ms
prod.eet.cz -> 5.145.105.133 Lookup took 5159 ms
prod.eet.cz -> 5.145.105.133 Lookup took 10377 ms
prod.eet.cz -> 5.145.105.133 Lookup took 10984 ms

Java app startovala vzdy nove JVM, tzn nebezelo to pod zadnym j2ee kontejnerem.
Jinak na hrane zdroju kontejner rozhodne nebezi.

from eet-client.

Super test, díky! Teď jak z toho ven? Pokud i tahle zcela holá java aplikace vykazuje podezřelé záseky, není z pohledu knihovny nejspíš žádná možnost, jak to řešit.

Zkusím obdobný test zopakovat na mém připojení a systému. Třeba se k něčemu doberu.

Máte nějaký nápad, kde by mohl být problém?

from eet-client.

Bylo by mozne pridat do logovani tech casu EET response, cas behu cele metody submit. Ja ten lookup test mam aktualne deaktivovany a docela by me zajimalo jaky je skutecny cas celeho volani. Popr. to mohu merit sam, ale kdyz to bude na jednom miste v jednom radku bylo by to fajn.

Jinak k tomu problemu, tezko rict jestli ten vysledek neni nahoda a lookup casy takove jsou v dany moment, proto bude lepsi udelat jeste test jak pisete u Vas. Ale osobne si myslim, ze takto laguje samotna java. Jeste jsem udelal testovaci aplikaci pomoci toho prikladu od Oracle, ktery vyrabi executor s vlastnim Thread. Tak zkusim jake budou odezvy.

from eet-client.

Jeste jsem neco objevil http://www.xbill.org/dnsjava/
Obsahuje mimo jine SimpleResolver tridu s moznosti nastaveni timeoutu (throws SocketTimeoutException).
Samotny lookup probiha vlastni TCP nebo UDP tridou. Aktualne testuji tu prilozenou java dig aplikaci jake vraci query time, ale casy vypadaji dost realne...
Takze zde je mozna reseni.

from eet-client.

Zde jsou vysledky mereni za 3 dny (1min interval) resolveru pomoci dnsjava knihovny, nejhorsi casy:

02-25 11:55|709
02-26 23:53|717
02-27 07:27|748
02-27 07:30|748
02-26 23:49|762
02-24 15:48|798
02-26 23:55|828
02-27 03:53|834
02-26 05:21|1192
02-26 20:46|1196
02-24 14:43|3681

Zda se, ze toto funguje...

from eet-client.

To vypadá dobře, ale pokud použiji tuto knihovnu pro ověření timeoutu DNS, stejně nakonec dojde uvnitř CXF na InetAddress a problém tak budeme řešit dvakrát. Nebo jsem něco přehlédl?

from eet-client.

Jde o to, ze se korektne otestuje resolver resp. network, coz byl asi puvodni zamer a eliminuji se chybne timouty java InetAddress class. S tim, ze to nakonec zalaguje asi nic neudelame. Navic co jsem vypozoroval, tak nasledne lookupy samotonou tridou ihned po otestovani tou knihovnou byly defakto okamzite, asi diky loklani dns cache samotheno systemu.

from eet-client.

Nerad bych přidával další závislost a raději bych ponechal InetAddress jako default implementaci. Ale chápu, že by bylo vhodné mít možnost použít vlastní DNS resolver, pokud default z nějakého důvodu nevyhovuje.

Můj návrh vypadá takhle: https://github.com/todvora/eet-client/blob/dns-resolver-configurable/src/main/java/cz/tomasdvorak/eet/client/dto/WebserviceConfiguration.java#L51

Dns resolver lze podstrčit v konfiguraci z venku a můžete tak klidně použít implementaci založenou na dnsjava. Kontrolní vlákno a timeout stále zůstávají.

Bylo by to takhle vyhovující?

from eet-client.

Muze byt, ale jak jsem uz psal, ja DNScheck pouzivat nebudu

from eet-client.

OK, každopádně díky za input, merguji a zavírám issue.

from eet-client.