Отправка больших данных через веб-службу Java

У меня есть веб-служба Java, которая возвращает большой объем данных. Существует ли стандартный способ потоковой передачи ответа вместо того, чтобы пытаться сразу вернуть огромный кусок данных?


java stream rest web-services
person Jeff Storey    schedule 08.01.2013    source источник
comment
с точки зрения дизайна, вы можете либо выбросить весь кусок, либо запросить через ajax... скажем, вы запрашиваете 10 сообщений, затем вы достигаете конца стека, вы запускаете другой запрос и так далее, замените 10 на 10000, хотя Я не уверен, что вы пытаетесь сделать... сегментация больших данных на куски уже выполняется TCP/IP.   -  person cristi _b    schedule 09.01.2013
comment
несколько миллионов строк json... очевидный вопрос - почему!   -  person cristi _b    schedule 09.01.2013
comment
Я пытался избежать загрузки всего набора данных в память на стороне сервера. Если бы у меня было несколько пользователей, запрашивающих большие наборы данных, попытка загрузить их все в память для отправки клиенту вызвала бы проблемы с памятью.   -  person Jeff Storey    schedule 09.01.2013
comment
Что касается причин, я просто тестирую и разбираюсь в потоковой передаче больших данных из веб-сервисов. С таким же успехом это может быть огромный файл изображения или что-то, что я транслирую по частям за раз.   -  person Jeff Storey    schedule 09.01.2013
comment
Вы работаете с сервисами SOAP или REST?   -  person ach    schedule 09.01.2013
comment
@JeffStorey не уверен, что кэширование может помочь в этом случае ... но действительно ли клиентам нужен мгновенный доступ к миллионам строк json или им нужен доступ к нему по запросу?   -  person cristi _b    schedule 09.01.2013
comment
@ach, это службы REST   -  person Jeff Storey    schedule 09.01.2013
comment
@cristi_b Это могут быть другие данные, а не json. Они могли передавать большой файл обратно с сервера.   -  person Jeff Storey    schedule 09.01.2013
comment
@JeffStorey, если ваши данные только и только текст, тогда ответ ccleve в порядке   -  person cristi _b    schedule 09.01.2013
comment
Не будет ли подход во многом зависеть от рассматриваемого формата, а также от структуры ваших ресурсов? Это вполне разумный подход — требовать дополнительную информацию о области видимости, чтобы избежать загрузки такого огромного куска данных в память. В качестве альтернативы вы можете использовать специальное решение. Если вы обрабатываете изображения или видео, было бы достаточно легко разгрузить службу, перенаправив клиента на выделенный сервер.   -  person toniedzwiedz    schedule 09.01.2013
comment
@ Том, честно говоря, мне, вероятно, следует лучше понять проблему.   -  person Jeff Storey    schedule 09.01.2013

Ответы (3)


arrow_upward
4
arrow_downward

Эта проблема аналогична старой проблеме с возвратом больших RSS-каналов. Вы можете сделать это, настроив запрос: http://host/myservice?start=0&count=100 или включив следующие/предыдущие URL-адреса в сам ответ.

Последний подход имеет массу преимуществ. Я поищу ссылку, которая описывает это, и опубликую здесь, если найду.

person ccleve    schedule 08.01.2013
comment
Я надеялся не ставить работу на клиента (если это возможно). Было бы неплохо, если бы клиент мог просто запросить один URL-адрес и получить данные кусками - хотя не уверен, что это возможно. - person Jeff Storey; 09.01.2013
comment
Зависит от вашего клиента. Http поддерживает фрагментацию. en.wikipedia.org/wiki/Chunked_transfer_encoding - person ccleve; 09.01.2013

arrow_upward
2
arrow_downward

Я бы рассмотрел подход, подобный comet:

Из ВИКИ:

Comet — это модель веб-приложения, в которой длительный HTTP-запрос позволяет веб-серверу передавать данные в браузер без явного запроса браузера.

По сути, вместо того, чтобы отправлять большие данные сразу, позвольте вашему веб-серверу передавать данные в своем собственном темпе и в соответствии с вашими потребностями.

person Goaler444    schedule 08.01.2013
comment
Я действительно не делаю толчок сервера, хотя здесь. Это по-прежнему запрос от клиента. - person Jeff Storey; 09.01.2013
comment
Нет, я имел в виду, что когда пользователь выполняет запросы, сервер отправляет куски данных в своем собственном темпе. Это похоже на комету, потому что клиенту не нужно запрашивать каждый фрагмент, а обрабатывается сервером. - person Goaler444; 09.01.2013
comment
Ага, понятно. Это имеет смысл. Единственное, что нужно клиенту, это маркер конца данных или что-то еще, чтобы знать, что передача завершена. - person Jeff Storey; 09.01.2013
comment
Клиент может знать, что передача завершена, когда HTTP-соединение было завершено. - person Goaler444; 09.01.2013
comment
было бы хорошо различать успешный и ненормально завершившийся перевод, но это детали реализации - person Jeff Storey; 09.01.2013
comment
Для получения дополнительной информации это можно сделать с помощью буферов и сброса. Я быстро искал с помощью Google. Вы можете посмотреть это для указания: ibm.com/developerworks/library/ wa-cometjava Точно так же, если вы понимаете PHP, вы можете получить более четкое представление, посмотрев это: w3shaman.com/article/php-progress-bar-script. Что касается того, чтобы узнать, была ли передача успешной или нет, вы можете сохранить флаг на стороне сервера и выполнить вызов ajax после завершения http-соединения. Флаг укажет, была ли отправлена ​​вся информация - person Goaler444; 09.01.2013

arrow_upward
0
arrow_downward

Веб-сервис может быть не лучшим методом для передачи данных.

На вашем месте я хотел бы настроить другую службу, например FTP или SFTP.

Сервер помещает данные по определенному пути FTP-сервера и отправляет информацию о пути клиенту через ответ веб-службы.

person David Ruan    schedule 08.01.2013