2017-02-05 12 views
1

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

ригель 2.5.4 «плей-authenticate_2.11»% «0.8.1»

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

Play framework [2.5.0 java] - Blocked netty-event-loop threads resulting in timeout

Play 2.5 application requests hang

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

Для получения дополнительной информации см. https://www.coalliance.org/play-25-upgrade.

+0

по умолчанию Deadbolt использует 'HttpExecution.d efaultContext() 'как его контекст выполнения. Если вы создадите собственную реализацию 'DeadboltExecutionContextProvider', чтобы использовать собственный пул потоков и связать его в модуле, Deadbolt будет использовать это вместо этого. Не могли бы вы спросить меня? Вы можете найти информацию о настройке пулов потоков [здесь] (https://www.playframework.com/documentation/2.5.x/ThreadPools#Many-specific-thread-pools) –

+0

Конфигурация пула потоков по умолчанию, измененная между Play 2.3 и 2.4, так что вы можете видеть побочный эффект этого. Подробнее см. Здесь [здесь] (https://playframework.com/documentation/2.5.x/Migration24#thread-pool-configuration). –

+1

Спасибо за ваш ответ, я сделаю, как вы предлагаете, и сообщите вам об этом. – Chet

ответ

0

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

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

я узнал, что это была проблема с использованием статического Ebean в классе TokenAction из игры аутентифицировать , я должен был изменить это:

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(); 
} 
+0

Спасибо за ответ, Это действительно хорошая информация, я отпишу ее для будущих проблем. Сначала я работал над ответом Стива, и это, казалось, был точной проблемой, с которой я имел дело. – Chet