а то у меня у самого чат на 150 чел, думаю может кто захочет

ну пиар за счет нас - это мимо кассы

Да чета много мертвых душ (:

не я в свой чат людей когда набираю то в лс , я про то чтоб сюда пригласить

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

не я в свой чат людей когда набираю то в лс , я про то чтоб сюда пригласить

выше ссылка

Да чета много мертвых душ (:

Каких нафиг мёртвых душ? Ты где видел профессиональные тематические чаты, где хотя бы 100 человек в один и тот же момент времени говорят? И, главное, зачем?

Плюс часовые пояса

а у этого чата есть курилка чтоб фильтровать сообщения тут?

а у этого чата есть курилка чтоб фильтровать сообщения тут?

@flood, если ты об этом

нормально все в этом чате, говорят ровно столько сколько надо имхо

флуда не так много

у меня тут попрос по спрингу, как сделать эндпоинт для отдачи больших файлов?

у меня тут попрос по спрингу, как сделать эндпоинт для отдачи больших файлов?

Мультипарт?

Мультипарт?

это для приема

у меня тут попрос по спрингу, как сделать эндпоинт для отдачи больших файлов?

ну первое, что приходит в голову - ResponseEntity<byte[]>

но если реально большие, надо гуглить как стриминг сделать

у меня тут попрос по спрингу, как сделать эндпоинт для отдачи больших файлов?

http://techblog.games24x7.com/2017/07/18/streaming-large-data-as-zipped-file-from-rest-services/

Ну вот так я стриминг делал

Есть ощущение что HTTP не особо подходит

Он же текстовый протокол. Биты в base64 переводятся?

http://techblog.games24x7.com/2017/07/18/streaming-large-data-as-zipped-file-from-rest-services/

пасиба, гляну

ну первое, что приходит в голову - ResponseEntity<byte[]>

гигабайтные файлы, в памяти такое держать не прикольно

гигабайтные файлы, в памяти такое держать не прикольно

ну стриминг

Есть ощущение что HTTP не особо подходит

у Http есть range хедер который позволяет запрашивать произвольный диапазон байт, так что все ок

что подразумевается под стримингом?

в HTTP 1.1 есть поддержка передачи чанками. http://www.oracle.com/technetwork/systems/chunking-155634.html

меня больше смущает, что сервлеты построены на блокирещем api, чанки-нечанки, поток ждет, пока клиент прочитает данные

надеюсь, где-то в глубине спринг может задействовать неблокирующую запись

что подразумевается под стримингом?

потоковая обработка

те не сохраняем все в памяти, а потом обрабатываем

а обрабатываем сразу

меня больше смущает, что сервлеты построены на блокирещем api, чанки-нечанки, поток ждет, пока клиент прочитает данные

Бери нетти с webFlux

я не могу проапдейтиться до второго бута

жду релиза 5.1

не похоже, что StreamingResponseBody осилит много реквестов =(

when using this option it is highly recommended to configure explicitly the TaskExecutor used in Spring MVC for executing asynchronous requests. Both the MVC Java config and the MVC namespaces provide options to configure asynchronous handling

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

надеюсь, где-то в глубине спринг может задействовать неблокирующую запись

У тебя впереди наверное nginx стоит... Он быстро все заберёт... А потом отдаст сам...

У тебя впереди наверное nginx стоит... Он быстро все заберёт... А потом отдаст сам...

у меня файла целиком нет, я его с s3 в процессе вычитываю

ребята, может кто сталкивался, использую hazelcast для hibernate second level cache и вот что получаю: There is no suitable de-serializer for type -205. This exception is likely to be caused by differences in the serialization configuration between members or between clients and members.

есть отдельная нода с hazelcast, в приложении использую spring.jpa.properties.hibernate.cache.hazelcast.use_native_client=true

Бери нетти с webFlux

кстати, а как там это реализовать?

Mono<byte[]> я так думаю

Mono<byte[]> я так думаю

а если мне гигабайт нужно отдать?

даже Mono<Resource>

надо будет потестировать

а если мне гигабайт нужно отдать?

Так он же их отдаёт по готовности. Готова часть - отдал, следующая готова - отдал. Правда клиент должен быть асинхронным тоже. Я на самом деле хз как это реализовано под капотом. Polling? Пуша та нет)

никогда не думал, что скажу такое, но скорее бы spring 5.1 зарелизился

Так он же их отдаёт по готовности. Готова часть - отдал, следующая готова - отдал. Правда клиент должен быть асинхронным тоже. Я на самом деле хз как это реализовано под капотом. Polling? Пуша та нет)

скажем, у меня все части готовы, клиент тормозит, пока он качает со скоростью 128кб/c мне нужно не держать все в памяти и не блокировать поток, который записывает

скажем, у меня все части готовы, клиент тормозит, пока он качает со скоростью 128кб/c мне нужно не держать все в памяти и не блокировать поток, который записывает

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

скажем, у меня все части готовы, клиент тормозит, пока он качает со скоростью 128кб/c мне нужно не держать все в памяти и не блокировать поток, который записывает

и так гигабайт раздавать)

Буферизовать на диск

Как делает например nginx

Для медленного клиента

Буферизовать на диск

Руками?

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

Получается что да, врятли webflux сам такое умеет)

Из готового вроде vert.x такое реализует, хотя я могу ошибаться

А не вариант ещё делать временные ссылки в S3?

Вообще да, если файл здоровый, и не нужно его менять на лету - проще линк оформить на него

Кажется это называется signed url в терминах s3

Ну ещё проблема держать коннект. Его держать не хочется, а выбора нет, если клиент медленный.

Но опять же могу ошибаться

Только оптимизировать, отменяя сессии тех, кто отвалился

А хочется именно стримить файлы? Не будет ли в такой задаче быстрее сделать DownloadAndStore на диск, а потом прогнать клиенту уже через WebFlux

ERROR: S client not available

В таком случае сработает Zero copy

Но добавит проблем с актуальностью данных очисткой и прочим добром конечно

Так, я вдруг вспомнил

Можно рестримить через nginx

С помощью заголовка X-Accel

И X-Accel-Redirect

Ну ещё проблема держать коннект. Его держать не хочется, а выбора нет, если клиент медленный.

коннект держать вообще не проблема

Из готового вроде vert.x такое реализует, хотя я могу ошибаться

у меня свой фреймворк есть, который так умеет, вот только тут мне нужно на спринг-буте 1.5

В таком случае сработает Zero copy

zero copy не особо и нужен, даже с несколькими копированиями скорость будет измереться гигабайтами в секунду

А хочется именно стримить файлы? Не будет ли в такой задаче быстрее сделать DownloadAndStore на диск, а потом прогнать клиенту уже через WebFlux

хочется держать очень маленький инстанс с диском на пару гигабайт

Кажись идея давать им ссылки в S3 - самое нормальное. Иначе придется класть файл на диск в том или ином виде, если не хочется его держать в памяти, пока клиент не скачает.

А если класть файл на диск то инстанс вырастет)

Mono<Resource> с кастомным ресурсом должно нормально работать, хотя не понятно как оно random access реализует

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

Mono<Resource> с кастомным ресурсом должно нормально работать, хотя не понятно как оно random access реализует

ну или да, реализовать потоковую отдачу)

правда мне все равно не очень понятно как это реализовано. Клиент должен периодически стучать, опрашивая не готова ли следующая часть?

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

это не проблема, проблема во фреймворках

правда мне все равно не очень понятно как это реализовано. Клиент должен периодически стучать, опрашивая не готова ли следующая часть?

клиент просто читает данные, когда читать нечего, считывается новая часть в буфер

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

Почему отвалится, chunked будет отдаваться

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

можно и без чанков, если клиент точно знает, что не дочитал до конца

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

это проблемы клиента

можно и без чанков, если клиент точно знает, что не дочитал до конца

А, ну да, длинна же известна заранее

что-то я опять уперся в ограничения спринга =(

что-то я опять уперся в ограничения спринга =(

Я делал отдачу файла, без разницы откуда ты будешь читать его с диска или с с3. Даже кешировать предварительно не нужно. Но ты будешь платить за задержки... И вроде основные проблемы возникают, когда клиент медленный. А ещё нужно посмотреть Apache camel, может он умеет такое!?

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

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

А ты запроксируй сразу через nginx!?

Пусть у него с3 как бэк енд будет

А ты запроксируй сразу через nginx!?

так файла целиком нет, да и нужно авторизацию смотреть

кажется мне даже webflux не поможет

> public class PostgreSQLContainer<SELF extends PostgreSQLContainer<SELF>> extends JdbcDatabaseContainer<SELF>