Aplikacja w podzie przestaje odpowiadać po @PostConstruct

Aplikacja springowa uruchamia się w podzie, następnie po wejściu na localhost:8080 uruchamiają się metody oznaczone @PostConstruct w klasach np.

class MyClass {

    @PostConstruct
    void init() {
        ...
    }
}

Takich @PostConstructów jest kilka. Po zainicjowaniu jednego z nich aplikacja staje na amen i przestaje cokolwiek logować. Jak to można zinwestygować i jakie mogą być przyczyny?
Pod też nie rzuca żadnych błędów.

Co to znaczy, że aplikacja „staje na amen”? Nie obsługuje requestów czy co się dzieje?

@PostConstruct odpala się tylko raz po zbudowaniu kontekstu Springa, nie na wejściu w żaden url :)

tu jest jakiś vaadin. Te klasy są @Lazy dlatego dopiero przy uderzaniu do tego vaadina one się inicjalizują. Staje to znaczy, że powinno się tak z 10 klas zainicjalizowac z tym @PostrConstruct a zatrzymuje się po jednej z inicjalizacji ciągle na tej samej klasie i nie wiadomo co dalej robi. Nie odpowiada.
Lokalnie ten problem nie występuje.

Może jakiś sieciowy problem (np. zły port) - sprawdź czy requesty na pewno dochodzą do aplikacji. Lokalnie tez odpalasz Kubernetesa czy testujesz bezpośrednio serwer?

lokalnie bezpośrednio, bez k8.
Problem polega na tym, że ja nie znam kubernetesa i chmur, a devopsi nie znają javy. :)

A lecą jakieś błędy w konsoli przeglądarki? Co się dzieje z tymi requestami?

Niech Ci się deviopsi podłącza do poda i zrobią heap dumpa i thread dumpa z jvm. Mając takie materiały, przeanalizujesz np. w visualvm. Lokalnie sam możesz zrobić. Inaczej black magic i zgadywanie.

Charles_Ray napisał(a):

A lecą jakieś błędy w konsoli przeglądarki? Co się dzieje z tymi requestami?

nic nie leci własnie, zamiera wszystko, timeouty

Szklana kula mówi mi, że k8s nie dobija się do portu 8080, na którym słucha aplikacja. Może spróbuj lokalnie na jakimś minikubie sobie to odpalić i zdebugować, ewentualnie siądźcie razem z devopsem

Dobija się do portu 8080 i to właśnie uruchamia te @Lazy @PostConstructy ale nie odpalaja sie wszystkie tylko w t rakcie sie zatryzmuje

Pierwsze pytanie to dlaczego masz te @PostConstructy? - to chyba jeden z gorszych antypaternów w javie.
A pomysł z threaddumpami do najprostsze rozwiązanie (kill -3 powinno je wypluć na stdout)

Dawno dawno temu miałem taki problem z Dockerem i Javą, aplikacja totalnie stawała. Rozwiązaniem było podmontowanie /dev/urandom jako źródła pseudolosowości.

Jak nie umiesz into dumpy. To lecisz metodą babci zakomentuj wszystko. I krok po kroku usuwaj komentarze.

kelog napisał(a):

Dawno dawno temu miałem taki problem z Dockerem i Javą, aplikacja totalnie stawała. Rozwiązaniem było podmontowanie /dev/urandom jako źródła pseudolosowości.

Kiedyś pisałem o podobnym problemie z Java i brakiem entropii, tam rozwiązaniem była instalacja demona rngd

Jak zwiększyłem poziom chaos...
Jak zwiększyłem poziom chaos...

LitwinWileński napisał(a):

Problem polega na tym, że ja nie znam kubernetesa i chmur, a devopsi nie znają javy. :)

"DevOps" dobre. Wręcz piękne. Betonowa ściana pomiędzy development i operations nazwana "DevOps".

Takie oczywiste fakty, k8s nie ma żadnego wpływu na działanie kontenera, kontener nie ma żadnego wpływu na działanie aplikacji. Dalej nie rozumiem co znaczy "się zatrzymuje"? Co właściwie się dzieje:

• aplikacja nie startuje
• kontener w kubernetesie się restartuje (podłącz się np. przez k9s do klastra i zobacz)
• co się dzieje w logach?

Jeżeli już masz zlokalizowany @PostConstruct, który "nie przechodzi", to problem prawdopodobnie leży w nim. To co może się dziać:

• Masz tam jakieś połączenie do usługi zewnętrznej, które jest niemożliwe do zrealizowania. Baza danych, key vault, kolejka whatever,
• Błędne sekrety
• Nie zgadzają się limity pamięci dla aplikacji, poda.

Co znaczy, że "lokalnie nie występuje", piszesz o odpaleniu aplikacji java -jar app.jar, czy uruchomieniu kontenera w dockerze, czy uruchomieniu kilku kontenerów w minikube?
Sorki, musisz oganąć podstawy zabaw z kontenerami:
Zacznij od:

• K9s - narzędzie konsolowe, ale z interfacem
• IntelliJ ma jakieś pluginy do kubernetesa, podobno działają
• nauczenie się jak pobrać logi z klastra kubernetesowego też nie jest zadaniem szczególnie wymagającym, weź jakiegoś devopsa za twarz i niech cię nauczy
• możesz zmienić definicję kontenera, tak, żeby aplikacja w środku odpalała się w trybie debug https://www.baeldung.com/java-application-remote-debugging oczywiście w definicji kontenera musisz wystawić na zewnątrz port debuggera, później możesz to nawet wypchnąć na środowisko docelowe, podłączyć się kubectl do klastra, otworzyć tunel dla debuggera sobie sprawdzać do woli pogooglaj jak używać kubectl port-forward

Quick guess - pierwszy PostConstruct zależy od innych klas i się normalnie wykonuje, a pozostałe mając te Lazy nie mają dalej powodu do uruchomiania. Nie ma żadnego zatrzymywania aplikacji.

chart napisał(a):

Quick guess - pierwszy PostConstruct zależy od innych klas i się normalnie wykonuje, a pozostałe mając te Lazy nie mają dalej powodu do uruchomiania. Nie ma żadnego zatrzymywania aplikacji.

tak i to się zadziało.
Aplikacja wymagała by do niej uderzyć, wtedy dalsza inicjalizacja klas się rozpoczynała. Devopsi źle skonfigurowali load balancery i request ginął gdzieś po drodze i nie docierał do aplikacji.