Приложение Play 2.5 (засов?) перестает отвечать на запросы

Недавно обновился до версии 2.5. Все работает, пока система не начнет генерировать отчеты (в отдельных потоках), когда я внезапно не смогу получить доступ ни к одной странице в веб-приложении. Я не вижу никаких ошибок в журнале. Версия play 2.3.8 отлично работает при тех же обстоятельствах/нагрузке. Я не вижу решения, кроме удаления засова, чтобы посмотреть, решит ли это проблему, как это было для пользователей, перечисленных ниже. ТИА

засов 2.5.4 "play-authenticate_2.11" % "0.8.1"

Я вижу, что у пары других пользователей была похожая проблема, и им пришлось удалить засов, чтобы решить ее.

Play framework [2.5.0 java] — потоки netty-event-loop заблокированы, что приводит к тайм-ауту

запросы приложений Play 2.5 зависают

(8 февраля 2017 г.) Я все еще работаю над этой проблемой, поскольку она не работает на двух производственных машинах, но работает на двух машинах для разработки. Машины разработки являются физическими и имеют несколько более новые версии Java. Обе производственные машины являются виртуальными и работают под управлением Java build 1.8.0_66. Как только я решу эту проблему, я буду работать над настройкой пулов потоков. Я опубликовал два решения, оба из которых работали на двух машинах разработки (физические машины с Java > 1.8.0_66).

Подробнее см. https://www.coalliance.org/play-25-upgrade. Информация.


playframework play-authenticate deadbolt-2
person Chet    schedule 05.02.2017    source источник
comment
По умолчанию Deadbolt использует HttpExecution.defaultContext() в качестве контекста выполнения. Если вы напишете свою собственную реализацию DeadboltExecutionContextProvider для использования пользовательского пула потоков и привяжете его к модулю, Deadbolt будет использовать его вместо этого. Не могли бы вы попробовать и сообщить мне? Подробную информацию о настройке пулов потоков можно найти здесь   -  person Steve Chaloner    schedule 06.02.2017
comment
Конфигурация пула потоков по умолчанию изменилась между Play 2.3 и 2.4, поэтому вы можете увидеть побочный эффект этого. Подробнее см. здесь.   -  person Steve Chaloner    schedule 06.02.2017
comment
Спасибо за ваш ответ, я сделаю, как вы предлагаете, и дам вам знать.   -  person Chet    schedule 06.02.2017
comment
Я установил конфигурацию akka по умолчанию (по ссылке выше), и это решило проблему. Я также создал CustomDeadboltExecutionContextProvider и буду играть с ним, используя конфигурацию play 2.5 по умолчанию. Если я найду что-то, что работает лучше, я опубликую это здесь.   -  person Chet    schedule 07.02.2017
comment
Отлично, спасибо!   -  person Steve Chaloner    schedule 07.02.2017
comment
Я все еще работаю над этой проблемой, поскольку она не работает на двух производственных машинах, но работает на двух машинах для разработки. Машины разработки являются физическими и имеют несколько более новые версии Java. Обе производственные машины являются виртуальными и работают под управлением Java build 1.8.0_66. Как только я решу эту проблему, я буду работать над настройкой пулов потоков. Я разместил два решения, оба из которых работали на двух машинах разработки (физические машины с Java › 1.8.0_66) coalliance.org/play-25-upgrade   -  person Chet    schedule 08.02.2017

Ответы (1)


arrow_upward
0
arrow_downward

У меня была аналогичная проблема, в моем случае приложение перестало отвечать после этой ошибки:

PersistenceException: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms.

Я обнаружил, что это проблема со статическим использованием Ebean в классе TokenAction из play-authenticate, мне пришлось это изменить:

public static void deleteByUser(final User u, final Type type) {
    QueryIterator<TokenAction> iterator = find.where()
            .eq("targetUser.id", u.id).eq("type", type).findIterate();
    Ebean.delete(iterator);
    iterator.close();
}

К этому:

public static void deleteByUser(final User u, final Type type) {
    QueryIterator<TokenAction> iterator = find.where()
            .eq("targetUser.id", u.id).eq("type", type).findIterate();
    while(iterator.hasNext()) {
        iterator.next().delete();
    }
    iterator.close();
}
person Gus    schedule 06.02.2017
comment
Спасибо за ответ, это действительно хорошая информация, я сохраню ее для будущих проблем. Сначала я работал над ответом Стива, и, похоже, это была именно та проблема, с которой я имел дело. - person Chet; 09.02.2017