Problem z Scheduled Executor Service

Hej,
Mam problem i nie mam pojecia gdzie co i jak to rozwiazac. W robocie mam proces, ktory podpina sie do roznych gield i sciaga z nich ceny roznych kontraktow. Normalnie uzywam do tego websockets, ale jedna z tych "gield" nie oferuje takie rozwiazania, wiec musze wykorzystac REST. A wiec zrobilem to:

public class CenyFX {
    private ScheduledExecutorService exe = Executors.newScheduledThreadPool(1);

    public CenyFX(List<String> coins) throws URISyntaxException {
        exe.scheduleAtFixedRate(sciagnijCeny, 0, 2, TimeUnit.SECONDS);
    }

    final Runnable sciagnijCeny = new Runnable() {
        @Override
        public void run() {
            try {
                String url = getURL();
                logger.info("URL: " + url);
                ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);
                JSONObject json = new JSONObject(response.getBody());

                //prices to jest po prostu mapa
                for (Map.Entry<String, Price> entry : prices.entrySet()) {
                    BigDecimal cena = json.getJSONObject(entry.getKey()).getBigDecimal("usd");
                    logger.info("Cena to: " + cena);
                }
            } catch (Exception e) {
                logger.error("Error: " + e.getMessage());
            }
        }
    };
}

I teraz problem jest taki, ze ten kod dziala, ale po paru dniach (czasami) godzinach ten ScheduledTask sie nie wykonuje. Patrzylem czy sa jakies wyjatki, ale ich brak. Nawet ta linijka logu "URL:" sie nie wyswietla.
Jakies sugestie mile widziane. Dzieki z gory

Ja bym podszedł do tego tak:

1. Używasz newScheduledThreadPool(int corePoolSize, ThreadFactory threadFactory), podajesz własne ThreadFactory które ustawi ładną nazwę wątku "my-costam-thread-1"
2. Gdy nastąpi opisany przez ciebie problem użyjesz jcmd żeby zrzucić stacktrace'y ze wszystkich wątków (https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html) ewentualnie jstackiem jak siedzisz na starszym JVM
3. Szukasz threada o swojej nazwie, będziesz wtedy wiedział co się z wątkiem stało.

Opcja alternatywna to popatrzeć w kod ScheduledExecutorService i zobaczyć co się może spierdolić. Może być tak że masz jakiś wyścig w kocie i Ci się po prostu deadlock robi...

EDIT:
Ze SO:

If any execution of the task encounters an exception, subsequent executions are suppressed

catch(Exception e) nie złapie wszystkiego, wszakrze są też Errory typu OutOfMemoryError.

Dzieki za odpowiedz. Moj program sie podlacza do roznych gield i inne ceny z websockets dzialaja. Tylko ten REST ma problemy. Czy moge to uzyc jako dowod ze OutOfMemoryException sie nie wydarzyl?

tom.dwan10 napisał(a):

Dzieki za odpowiedz. Moj program sie podlacza do roznych gield i inne ceny z websockets dzialaja. Tylko ten REST ma problemy. Czy moge to uzyc jako dowod ze OutOfMemoryException sie nie wydarzyl?

nie. out-of-memory-error może teoretycznie polecieć i nie wysadzić aplikacji. dla przykładu: ktoś próbuje w pewnym miejscu zaalokować pierdylion gigabajtów naraz i dostaje tego exceptiona, ale reszta kodu alokuje powolutku i tam już problemy nie występują.

zrób tego thread dumpa (tak jak @0xmarcin napisał albo inaczej) i będziesz wiedział co się z wątkiem dzieje

Ok. Ale zalozmy zrobie thread dump o ktorym Marcin powiedzial i zalozmy bede widzial "OutOfMemoryError". To co moge w tym wypadku z tym zrobic?

Nie będziesz widział OoME. Zobaczysz czy wątek żyje (jeśli nie, to pewnie poleciał jakiś gruby error, np. wspomniany OoME) albo na czym wisi (np. jakaś operacja trwa wieczność, bo czekasz na coś co się nigdy nie zdarzy).

Jeśli stworzysz własny ThreadFactory to będziesz mógł ustawić (obok nazwy wątku) kod, który może zalogować wyjątek kończący wątek: https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler-java.lang.Thread.UncaughtExceptionHandler-

Przyszedl mi jeszcze jeden pomysl na mysl, tylko chcialbym sie upewnic czy on moze zadzialac. A co by sie stalo gdyby stworzyl klase ktora sprawdza czy przez ostatnie 10minut byl jakis update z klasy CenyFX. Jak nie bylo zadnego update-u, to stworzy nowa klase CenyFX i nowy ScheduledExecutorService. Czy to ma rece i nogi?

Jaki masz timeout na tym RestTemplate? Może tam wątek wisi długo. I mam nadzieje, że masz jedna instancje, a nie tworzysz nowej per task?

Dobrze by było jeszcze wiedzieć, czy zadania się wykonują, czy nie są kolejkowane przed pula wątków. Domyślnie rozmiar kolejki jest nieograniczony, wiec jest opcja na OOME. Sugerowałbym użyć ThreadFactory i to ucywilizować, ustawić DiscardPolicy, zalogować, kiedy zadanie zostanie odrzucone.

RestTemplate uzywa "default constructor".

 private RestTemplate restTemplate;

    public CenyFX()  {
        restTemplate = new RestTemplate();
    }

I nie, nie tworze per task.

A co jesli tutaj bym zmienil z "catch Exception" --> "catch Throwable" ??:

final Runnable sciagnijCeny = new Runnable() {
        @Override
        public void run() {
            try {
                String url = getURL();
                logger.info("URL: " + url);
                ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);
                JSONObject json = new JSONObject(response.getBody());

                //prices to jest po prostu mapa
                for (Map.Entry<String, Price> entry : prices.entrySet()) {
                    BigDecimal cena = json.getJSONObject(entry.getKey()).getBigDecimal("usd");
                    logger.info("Cena to: " + cena);
                }
            } catch (Throwable e) {       // <-----------------------------------------------------
                logger.error("Error: " + e.getMessage());
            }
        }
    };

Zjadanie Throwable'i to moim zdaniem śliski biznes, ale niektórzy tak robią i nawet nie widać specjalnie, żeby od razu z tego powodu coś wybuchało.

Lepiej jednak dorzucić tam rzucanie wyjątku z powrotem, tzn:

            } catch (Throwable e) {
                logger.error("Error: " + e);
                throw e;
            }

a tak w ogóle to czy logger nie ma specjalnej metody przyjmującej exceptiona i wypisującej jego stacktrace? to mogłoby pomóc.

@tom.dwan10: a czy ty nie masz przez przypadek jakichś ograniczeń na tym RESTowym API? Bo scheduleAtFixedRate działa niezbyt intuicyjnie jeżeli masz przekroczone czasy:

If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.

Mówiąc inaczej, sprawdź, czy nie doprowadzasz do sytuacji, w której żądanie REST „wisi” i zadanie jako całość nie kończy się, a kolejna iteracja nie może wystartować.