JBoss 7.1.0: executor.submit () как отлаживать (нет исключений, но задача не запущена) - PullRequest
Новая
       9

JBoss 7.1.0: executor.submit () как отлаживать (нет исключений, но задача не запущена)

0 голосов
/ 26 ноября 2018

У меня проблема с JBoss EAP 7.1.0 GA.На одном сервере (мой DEV) это работает как чудо, в то время как на другом (среда TEST) Callable, выполняемый с помощью executor.submit (), похоже, не запускается (я не вижу сообщения «Это вызов» в журнале), но никаких исключений или какой-либо другой подсказки не дано.

Вопрос в том, где я должен выглядеть / как мне следует отлаживать эту проблему?

Код вызова: 

@Resource(name = "DefaultManagedExecutorService")
ManagedExecutorService executor;

try {
    DownloadPlayers dp = new DownloadPlayers();
    Future<Queue<PlayerForDownload>> f = executor.submit(dp);
    Queue<PlayerForDownload> q = f.get();
    L.info(q.size());
} catch (Exception e) {
    L.error("EXCEPTION" + e.getMessage());
}

Класс, который он вызывает: 

public class DownloadPlayers implements Callable<Queue<PlayerForDownload>> {

    // the constructor gets called, I'm sure as it writes to log

    // the call is as simple as this
    @Override
    public Queue<PlayerForDownload> call() {
        L.info("This is call()");
        try {
            return this.getPlayersForDownload();
        } catch (WorkerException e) {
            L.error(e);
            return null;
        }       
    }
}

Как указано выше, сам код выглядит нормально, так как он работает на одном сервере, но не работает на другом.Оба являются 7.1.0GA автономными.Любой совет, как отладить ManagedExecutorService?

Спасибо.

1 Ответ

0 голосов
/ 28 ноября 2018

В данном конкретном случае проблема заключалась в том, что в среде TEST было разрешено запускать только два потока, которые мы уже выполняли (в какой-то совершенно другой части приложения, которую я не осознавал).Таким образом, проблема теперь решается путем установки более высокого значения параметра «Основные потоки» в ManagerExecutorService, задачи выполняются.

Однако сложность заключалась в том, что между серверами JBoss не было очевидной видимой разницы (я сравнилконфиг standalone.xml ...) только потому, что ManagerExecutorService в JBoss имеет некоторые значения по умолчанию (пустые), которые на самом деле зависят от конфигурации системы (ядра v-CPU в моем случае).Таким образом, несмотря на то, что конфигурация одинакова, «основные потоки», по-видимому, имеют значение по умолчанию 2 в TEST и более высокое (неизвестное мне) значение в моем DEV.

Так что никогда не зависите от настроек по умолчанию в ManagerExecutorService при сравнении двухокружения.

Я также переписал логику, вместо того, чтобы использовать блокировку Future.get () или проверку на Future.isDone () в цикле и делать Future.get () с тайм-аутом и в обработчике исключений Iрешить, продолжать ли ждать или нет.

...