Имам уеб услуга на Java, която връща голямо количество данни. Има ли стандартен начин за поточно предаване на отговор, вместо да се опитвате да върнете огромна част от данните наведнъж?
Изпращане на големи данни през уеб услуга на Java
comment
от гледна точка на дизайна можете или да хвърлите цялото парче, или да поискате чрез ajax ... да кажем, че поискате 10 публикации, след което стигнете до края на стека, задействате друга заявка и така нататък, заменете 10 с 10 000, въпреки че Не съм сигурен какво се опитвате да направите... сегментирането на големи данни на части вече се извършва от 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
@Tom честно, вероятно трябва да обхвана по-добре проблема.
- person Jeff Storey schedule 09.01.2013
Отговори (3)
Този проблем е аналогичен на по-стария проблем с връщането на големи RSS емисии. Можете да го направите, като параметризирате заявката: http://host/myservice?start=0&count=100 или като включите следващи/предишни URL адреси в самия отговор.
Последният подход има много предимства. Ще потърся връзка, която го описва, и ще я публикувам тук, ако намеря.
person
ccleve
schedule
08.01.2013
Надявах се да избегна прехвърлянето на работата върху клиента (ако е възможно). Би било хубаво, ако клиентът може просто да поиска един URL адрес и да получи данните на части - не съм сигурен дали това е възможно обаче.
- person Jeff Storey; 09.01.2013
Зависи от вашия клиент. Http поддържа накъсване. en.wikipedia.org/wiki/Chunked_transfer_encoding
- person ccleve; 09.01.2013
Бих разгледал подход, подобен на comet:
От WIKI:
Comet е модел на уеб приложение, при което дълго задържана HTTP заявка позволява на уеб сървър да изпраща данни към браузър, без браузърът изрично да ги изисква.
По принцип, вместо да изпращате големите данни наведнъж, позволете на вашия уеб сървър да изпраща данни със собствено темпо и според вашите нужди.
person
Goaler444
schedule
08.01.2013
Тук всъщност не правя натискане на сървъра. Това все още е заявка при поискване от клиент.
- person Jeff Storey; 09.01.2013
Не, това, което имах предвид, беше, че след като потребителят направи заявка, сървърът избутва парчета данни със собствено темпо. Това е нещо като комета, защото клиентът не трябва да изисква всяка част, а се обработва от сървъра
- person Goaler444; 09.01.2013
О, виждам. Това има смисъл. Единственото нещо, от което клиентът ще се нуждае, е маркер за край на данните или нещо, за да знае, че прехвърлянето е завършено.
- person Jeff Storey; 09.01.2013
Клиентът може да разбере, че прехвърлянето е приключило, когато http връзката е прекратена.
- person Goaler444; 09.01.2013
би било добре да се прави разлика между успех и необичайно завършен трансфер, но това са подробности за изпълнението
- person Jeff Storey; 09.01.2013
За повече информация, това може да се направи с помощта на буфери и промиване. Бързо потърсих с google. Може да искате да погледнете това за указание: ibm.com/developerworks/library/ wa-cometjava По същия начин, ако разбирате PHP, можете да получите по-ясна представа, като погледнете това: w3shaman.com/article/php-progress-bar-script. Що се отнася до това дали прехвърлянето е било успешно или не, можете да съхраните флаг от страна на сървъра и да извършите ajax повикване, след като http връзката приключи. Флагът ще покаже дали цялата информация е изпратена
- person Goaler444; 09.01.2013
Уеб услугата може да не е добър метод за пренос на данни.
Ако бях на ваше място, бих искал да настроя друга услуга като FTP или SFTP.
Сървърът поставя данните в конкретния път на FTP сървъра и изпраща информацията за пътя на клиента чрез отговора на уеб услугата.
person
David Ruan
schedule
08.01.2013
