v
Size: a a a
2020 September 22
v
Проблема в том, что в дебаг зайти на сервере нельзя) А других идей для локализации ошибки нет
Может не в тему, но выглядит похоже
https://www.cuba-platform.ru/discuss/t/problemy-s-logirovaniem/1653
https://www.cuba-platform.ru/discuss/t/problemy-s-logirovaniem/1653
ВБ
Ну, как минимум, logDir разные в этих файлах
<property name="logDir" value="../app_home/logs"/>
<property name="logDir" value="../app_home/logs"/>
Да, пробовал менять. Не помогло. Да и аппендер на самом деле нужен для кибаны
ВБ
Может при сборке файл конфигурации не туда попадает и не подхватывается?
Вот это кстати вполне может быть. По ссылке покопаюсь, спасибо огромное!!!!
KS
умнеет, можно указать в цепочке что с какого-то шага все последующие в отдельном пуле
Интересовало сказать "выполняй это вычисление на вот этом пуле, а потом самостоятельно вернись в тот, откуда был прыжок".
B
Kirill Shelopugin
Интересовало сказать "выполняй это вычисление на вот этом пуле, а потом самостоятельно вернись в тот, откуда был прыжок".
К сожалению так не получится, нужно явно будет возвращать выполнение на нужный скедулер(пул), возможно Нетти сам в коде переключит на нужный, но точно это можно узнать по логу, в каком потоке был респонс
AE
Kirill Shelopugin
Интересовало сказать "выполняй это вычисление на вот этом пуле, а потом самостоятельно вернись в тот, откуда был прыжок".
так оно так и делает
AE
Balas
К сожалению так не получится, нужно явно будет возвращать выполнение на нужный скедулер(пул), возможно Нетти сам в коде переключит на нужный, но точно это можно узнать по логу, в каком потоке был респонс
нет
IG
Что нет то? Ты тред читал?
AE
Что нет то? Ты тред читал?
флоу реактора позволяет указать что нижележащая цепочка будет выполняться на другом пуле, не так?
IG
флоу реактора позволяет указать что нижележащая цепочка будет выполняться на другом пуле, не так?
Верно, но изначально был разговор о том, чтобы выделить ОТДЕЛЬНЫЙ пул для DB Connection Pool (JDBC) и переключать автоматически на выделенный (без scheduleOn)
IG
Input Flux (Netty pool) -> JDBC call (unbonded pool) -> Netty
IG
без ручного переключения. А вот так нельзя.
AE
Верно, но изначально был разговор о том, чтобы выделить ОТДЕЛЬНЫЙ пул для DB Connection Pool (JDBC) и переключать автоматически на выделенный (без scheduleOn)
ну это можно с r2dbc
AE
Input Flux (Netty pool) -> JDBC call (unbonded pool) -> Netty
это пожалуй нельзя, да
IG
ну это можно с r2dbc
Конечно можно (что и было указано изначально). А речь шла об JDBC
AE
Конечно можно (что и было указано изначально). А речь шла об JDBC
jdbc в условиях реактора невелирует все плюсы реактивщины, скатываешься в блокирующий код с меньшей производительностью, просто пулов несколько
SA
Интересно, были ли хоть у кого-нибудь проблемы с производительностью блокирующего jdbc.
IG
Интересно, были ли хоть у кого-нибудь проблемы с производительностью блокирующего jdbc.
Он быстрее чем async. Производительность приложения может пострадать если используется netty pool для incoming http requests (webflux)