надо, что-то типа бэкграунд Thread, но на корутинах

Корутины уже могут работать как бэкграунд тред

Приложение на spring и я погуглил, вроде как высвобождаются ресурсы после ответа от контроллера, поэтому файлы могу не дозаписываться. Но мне кажется в другом проблема все таки. Если загружать один файл размером 300mb, то все ок он запишется спустя какое-то время, а если за ним сразу загрузить второй, то не запишутся оба... Для загрузки файла использую, что-то типа launch { Files().write(path, bytes) }.start

Зачем нужен start? Launch и так по умолчанию стартует и этот код выполнится в бэкграунде

можно и убрать, но проблемы это не решит)

Я не знаю как спринг менеджерит такие ресурсы, т.е. вы записываете файл от юзера полученный в реквесте? Если так, то конечно возвращать результат нельзя, пока файл не скачан и не закеширован на диск, иначе просто запрос прервется

Андрей, все верно)

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

Я вчера начал в эту же сторону копать, но все равно не до конца понимаю. Если нам от юзера прилетает файл и дальше мы его закинем в channel, то все равно, если сразу после этого прилетит второй файл от того же юзера у нас ссылка переопределиться и мы будем в другое место памяти смотреть. Поправьте если неправ

Для начала нужно понять что такое “от юзера прилетает файл”

Смотрите, пользователь делает upload со своей локальной машины, далее файл из контроллера я передаю в процессинговую часть, там очень быстро разбирается мета инфа файла и ему присваивается уникальное имя, запись мета информации в БД происходит до записи файла на диск, то есть в принципе ничего не мешает вернуть ответ юзеру с сылкой на загруженный файл, а файл потихоньку загрузить в фоне. Но, если этот же самый юзер в рамках своей сессии, сразу закинет еще один файл, то я не очень понимаю как дописать предыдущий файл т.к новый файл переопределит ссылку записываемого файла в heap jvm... Если только каждый раз делать копию объекта и пихать его в worker.

ничего не мешает вернуть ответ юзеру с сылкой на загруженный файл, а файл потихоньку загрузить в фоне

Не представляю как это может работать в рамках HTTP запросов. В HTTP ответ всегда следует за запросом, не возможно прочитав часть запроса, сделать ответ и потом вернуться к получению запроса

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

что-то я очень в этом сомневаюсь, видимо просто ответ не уходит пока вы его читаете или еще нечто подобное

можно вернуть из контроллера Mono/CompletableFeature и разрешить их по факту завершения launch{} таска