Смотрю в давно напиленный spring batch job

там стоит commitInterval = 500

соответственно, всё окей, у нас больше 200-то и не бывает

меняю на 50

запускаю

первые 50 коммитятся в базу, после чего подключение к БД закрывается ко всем херам

Это что еще за штучки?

так это и есть сколько записей в батче

так это и есть сколько записей в батче

так во входных данных, скажем, 200 записей. А потом идет update на степ и вообще все падает

ну нахер, тут ваще спринг батч не нужен

надо переписать

Знатоки спринга подскажут? Можно ли сделать асинхронный Interceptor (или на Filter) в спринге следующим образом: 1. В условном preHandle запустить асинхронную таску. 2. После завершения таски выполнится основной метод контроллера. 3. При этом поток, в котором запустилась обработка (preHandle) не блокируется, т.е. вообще всё асинхронно.

а зачем? у тебя в любом случае 1 воркер на 1 запрос

если какой-нибудь undertow

Знатоки спринга подскажут? Можно ли сделать асинхронный Interceptor (или на Filter) в спринге следующим образом: 1. В условном preHandle запустить асинхронную таску. 2. После завершения таски выполнится основной метод контроллера. 3. При этом поток, в котором запустилась обработка (preHandle) не блокируется, т.е. вообще всё асинхронно.

После завершения таски вызовется метод ? Это уже синхронно

Не понимаю, что и зачем хочешь сделать.

Если имеется в виду, что ты запустил таску и одновременно выполняешь контроллер

То я бы обернул в фильтре response в onCommitedResponseWrapper, запустил таску и во враппере переопределил onResponseCommited с ожиданием выполнения таски

Если я правильно понял то, что ты хочешь, а не то, что ты написал - если я не прав напиши детали

Но, это можно сделать и в контроллере. А ещё есть замечательный класс DefferedResult(или CompletableFuture, whatever) который отпускает треды томката

Кто-нибудь перешел на JUnit 5? Есть там какие-нибудь интересные фичи (типа property tests или тестирование стат. методов)?

Junit же еще не релизнулся?

Мы пробовали в нашем опенсорном шаблонизаторе. Когда я начал пилить интеграцию со спрингом - отхватил много боли

В тестах

Но это было год назад

Не понимаю, что и зачем хочешь сделать.

Смысл в том, чтобы не держать потоки.

Смысл в том, чтобы не держать потоки.

А в контроллере, что мешает не держать их ?

Как в Java получить класс параметризированного дженерика? Типа: Class<List<Integer>> c = List<Integer>.class;

но так не компилится

В Interceptor общая логика выполняется (связанная, например, с авторизацией).

Как в Java получить класс параметризированного дженерика? Типа: Class<List<Integer>> c = List<Integer>.class;

смотря зачем

в общем случае — никак

type erasure и все такое

ну чтобы указать правильный класс для десериализации, например

В Interceptor общая логика выполняется (связанная, например, с авторизацией).

Ща тебе скину логику

точнее код

набросаю

если используешь Jackson, то смотри в сторону TypeReference

Ок, спасибо.

Map<String, Object> m = new ObjectMapper().convertType(obj, Map<String, Object>.class);

Map<String, Object> m = new ObjectMapper().convertType(obj, Map<String, Object>.class);

тебе правильно подсказали про тайп референс

Map<String, Object> m = new ObjectMapper().convertType(obj, new TypeReference<Map<String, Object>>() {});

http://www.baeldung.com/jackson-collection-array

чет тип того

в этой статье все варианты рассмотрены

спасибо, погляжу

Ок, спасибо.

public class WhateverFilter extends OncePerRequestFilter { //На примере фильтра @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { //Долгая - долгая таска. CompletableFuture<Integer> asyncTask = CompletableFuture.supplyAsync(() -> { int counter = 0; //неважно что тут. for (int i = 0; i < 1_000_000; i++, counter++) { } return counter; }); //Оборачиваем response во враппер, onResponseCommitted вызовется ровно до того, как отдастся ответ //пользователю. Т.е. самая последняя точка, перед тем как юзер что-то получит filterChain.doFilter(request, new OnCommittedResponseWrapper(response) { @Override protected void onResponseCommitted() { //Дожидаемся выполнения задачи, чтобы она точно выполнилась, до того, как юзер получит //результат asyncTask.join(); } }); } }

public class WhateverFilter extends OncePerRequestFilter { //На примере фильтра @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { //Долгая - долгая таска. CompletableFuture<Integer> asyncTask = CompletableFuture.supplyAsync(() -> { int counter = 0; //неважно что тут. for (int i = 0; i < 1_000_000; i++, counter++) { } return counter; }); //Оборачиваем response во враппер, onResponseCommitted вызовется ровно до того, как отдастся ответ //пользователю. Т.е. самая последняя точка, перед тем как юзер что-то получит filterChain.doFilter(request, new OnCommittedResponseWrapper(response) { @Override protected void onResponseCommitted() { //Дожидаемся выполнения задачи, чтобы она точно выполнилась, до того, как юзер получит //результат asyncTask.join(); } }); } }

В данном примере выполнение метода контроллера и таска из Filter не упорядочены. Хочется получить что-то наподобие того, как реализуется цеочка CompletionStage при выполнении CompletableFuture.

В данном примере выполнение метода контроллера и таска из Filter не упорядочены. Хочется получить что-то наподобие того, как реализуется цеочка CompletionStage при выполнении CompletableFuture.

Тогда это синхрон и не нужно выполнять таску в другом треде

Любая цепочка в completableFuture это синхрон, просто в разных тредах

Вот тебе задачка, как думаешь в каких тредах выполнится supplyAsync и thenApply? public static void main(String[] args) { CompletableFuture.supplyAsync(() -> null).thenApply(result -> result).join(); }

Знатоки спринга подскажут? Можно ли сделать асинхронный Interceptor (или на Filter) в спринге следующим образом: 1. В условном preHandle запустить асинхронную таску. 2. После завершения таски выполнится основной метод контроллера. 3. При этом поток, в котором запустилась обработка (preHandle) не блокируется, т.е. вообще всё асинхронно.

у вас какая то тяжелая таска в preHandle? иди зачем это все

Три варианта ответа: в треде common pool, в треде мейн или нерегламентированно?

Цель в том, чтобы избежать множества потоков в состоянии wait, чтобы в итоге минимизировать перключение контекста.

так pool может регулировать количество потоко

потоков в зависимости от нагрузки

нагрузка низкая - удалит лишние потоки

нагрузка высокая - создаст

Насчёт комон пулов киньте почитать поподробнее где оно применяется а реальности плиз

Насчёт комон пулов киньте почитать поподробнее где оно применяется а реальности плиз

Джавадок жи

не слышал про common pool

но в java есть дефолтные механизмы создания пулов

не слышал про common pool

А про forkJoin?

ERROR: S client not available

ну слова common там нет

ну слова common там нет

Переменная называется common pool

Сорян, метод

а понял

Возвращает дефолтный пул на которых все эти ваши стримы параллельные выполняются и комплитабл фьючи

но лучше кастомный юзать

ну и вообще ForkJoin только для определенного типа задач

ну и вообще ForkJoin только для определенного типа задач

Передать экзекутор в саплай асинк несложно

если ты говоришь про задачу @K_Gregory то мне кажется они пытаются что-то выдумать

что им реально не нужно

если ты говоришь про задачу @K_Gregory то мне кажется они пытаются что-то выдумать

Да, я ему ответил в лоб. Потому, что не понимаю что и зачем

Понятно, что если мы сделаем в конце get(), то всё схлопнется в синхрон. Хочется весь код оставить асинхронным. Представь ситуацию, что приходит 1000 запросов, у каждого есть толстая таска, которая сейчас выполняется синхронно (а в ней долгий IO) - по факту забьём все потоки

ну и вообще ForkJoin только для определенного типа задач

А касательно скоупа задач в основном это независимые вычисления, которые можно разбить на рекурсивные подзадачи. Благодарю алгоритму workStealing форк джоин даёт преимущества

Понятно, что если мы сделаем в конце get(), то всё схлопнется в синхрон. Хочется весь код оставить асинхронным. Представь ситуацию, что приходит 1000 запросов, у каждого есть толстая таска, которая сейчас выполняется синхронно (а в ней долгий IO) - по факту забьём все потоки

Да даже thenApply выполниться синхронно, после завершения первой цепочки вычисления в supplyAsync. Как могут две задачи, в которой вторая зависит от первой, выполняется асинхронно?

Понятно, что если мы сделаем в конце get(), то всё схлопнется в синхрон. Хочется весь код оставить асинхронным. Представь ситуацию, что приходит 1000 запросов, у каждого есть толстая таска, которая сейчас выполняется синхронно (а в ней долгий IO) - по факту забьём все потоки

так возьмите либу которая умеет делать все из коробки

Junit же еще не релизнулся?

Вроде уже https://jug.ru/2017/09/junit-5-released/

и пробрасывайте реквесты туда

да, уже посмотрел. 2 дня назад

так возьмите либу которая умеет делать все из коробки

Например?

Spring reactor

spring batch

akka streams

напишите конвейер и он полностью асинхронно вам перемолет ваши задачи

В общем я понял, что ты хочешь. Запустить задачу в фильтре(например), а потом в контроллере схлопнуть. Тогда тебе придется эту задачу обернуть во фьючу, далее записать куда-нибудь(в сессию, в аттрибуты реквеста, в principal) и уже в контроллере по надобности вынимать задачу оттуда и делать join

либо напишите свое решение но не зависящее от Servlet стека

В общем, стандартного способа в спринге нет :)

при чем тут спринг вы придумали задачу

которая 100% вам не нужна

и пытаетесь ее решить

но виноват спринг

Нам по смыслу async / await шарповый нужен.