|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
Андрей Панфилов, автор, что в коте врублен http/2совсем не обязательно ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 05:23 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
Андрей Панфилов Stanislav Bashkyrtsev Если мы приняли соединение, не верю что это сработает. Да, мы получим ошибку когда начнем писать в сокет потому что тот окажется закрытым. Но это произойдет уже в конце, когда мы провели всю работу с БД. Чтоб суметь оборвать БД запрос - это нужно в самом Томкате знать про БД (и если бы это и могло работать, то только с пулом самого томката), в общем звучит unreal. Вы не верите только из-за того, что разработчики редко используют фичу, уже ставшую де-факто стандартом :) (Вади не хватает, он бы все здесь разрулил) Я специально проверил и повторно убедился что оно работает, а именно: - создал сервлет с Thread.sleep() - вызвал его из curl, жамкнул Ctrl+C - в org.apache.tomcat.util.net.SocketWrapperBase#close приехала инфа, что клиент разорвал соединение - вызвал из браузера и закрыл браузер - в org.apache.tomcat.util.net.SocketWrapperBase#close опять же приехала инфа, что клиент разорвал соединение однако прежде чем бросаться проверять, убедитесь, что в коте врублен http/2 и настроен ssl, и вы хорошо дунули, а то фокуса не получится. Прерывать запросы в БД после отвала клиента - это уже дело техники, нужно всего-то уметь Statement#executeXXX ассоциировать с потоком. Хм не воспоизвелось. Правда пока еще не получилось уровень логирования у томката повысить ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 13:44 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
пардон, вчера два часа просидел не мог включить логирование, нужен был свежий взгляд (для http2 отдельный нужно расскоментировать строку если вдруг кто попробует) org.apache.coyote.http2.level = FINE ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 13:48 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
вадя Андрей Панфилов, автор, что в коте врублен http/2 на http1.1 ворнига о разрыве соединения нет, на http2 есть видимо особенности http2 требуется постоянно отслеживать соединение из за мультиплекирования. в http1.1 после того запрос ушел уже неважно. насколько помню всегда для http1.1 было что бакенд как готово ответить пишет в outputstream и тут прилетает IOException что outputstream уже закрыть из за разрыва соединения. Но я не был уверен что томкат отслеживает разрыв соединения. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 13:55 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
lleming на http1.1 ворнига о разрыве соединения нет, на http2 есть у меня есть отработка обрыва. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 15:32 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
у меня тоакое Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 15:49 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
вадя у меня тоакое Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9.
это websocket и тут тоже логично, нет в чистом ввиде запрос ответ, данные в обе стороны ходят и требуется постоянно отслеживать соединение (там вроде даже чтото вроде пинга предустотрено в спеке вебсокета так что можно отслеживать) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 15:52 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
lleming требуется постоянно отслеживать соединение ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 17:37 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
mayton Андрей Панфилов пропущено... Я это место никогда не понимал и до сих пор не понимаю: вот если мы уже проделали некоторую полезную работу, а потом решили что нужно что-то выполнить асинхронно, а нам на submit выкидывают RejectedExecutionException - что с этим исключением делать? как его компенсировать? 100% согласен. Я-бы вообще не накладывал ограничений на длину очереди задач. Вот сколько памяти - столько пускай и растет. Но алёрты и мониторинг на PROD должны быть выставлены в какой-то 99й процентиль очереди. Пускай превышение очереди будет просто сигналом о другой проблеме. Например о том что пул не справляется. Предполагаю, что ограничение на очередь задач в пуле выполняет примерно такую же роль, как ограничение на длину массива, или ограничение на деление на ноль. В норме пул задач наверное должен быть обернут логикой, не должно быть у клиентов прямого доступа к пулу и возможности неограниченно субмитить задачи в пул. И если случилось переполнение очереди задач пула, то это ошибка где-то в логике оболочки пула. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 19:02 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
вот тут https://habr.com/ru/company/superjob/blog/598857/ некоторые "исследования" по схожей теме, хоть и о php, но есть что-то и про пул. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 19:13 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
Roman Osipov, Вы не охватите все многообразие задач. Вполне могут существовать задачи в созвездии Пса, при которых юзер кидает столько задачек, сколько ему захотелось. По примеру архивирования файлов. Выделите весь диск С: и нажмите архивировать. Вы просто будете ждать бесконечно. Но это обратная связь. Будете умнее в след.раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 21:27 |
|
Spring @Async - увеличение пула в реальном времени ?
|
|||
---|---|---|---|
#18+
Я могу прикинуть задачу где ограничение на буферы имеет смысл. Это например ковейерная обработка данных. Есть сет потоков. Они соединены в pipeline либо BlockingQueue либо Disruptor либо просто самодельным буфером. Идея в том что скорость процессинга событий - неравномерная. Где-то чтение запись в БД идет пачками. А процессинг - строго последовательно. И нам выгодно ограничить очереди. Ведь скорость всего каравана равна скорости медленного верблюда. Но ограничения на почтовые ящики - это просто мемори менеджмент. Мы экспериментально подбираем такую среднюю длину очереди чтобы компенсировать выбросы скорости. И мы делаем push в очередь блокирующим. Ничего отправитель подождет. Зато понятен лимит по памяти. И мы сознательно идем на такое ограничение потому-что задача - фоновая. Никакой пользователь за экраном не сидит и не ждет. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 23:10 |
|
|
start [/forum/topic.php?fid=59&msg=40125014&tid=2120269]: |
0ms |
get settings: |
26ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
248ms |
get tp. blocked users: |
2ms |
others: | 377ms |
total: | 733ms |
0 / 0 |