Nesla by na to pouzit kafka?
Dňa 16. 11. 2017 o 11:44 Oto Buchta napísal(a):
Ahoj,
pokud je problem co s daty, ktere se zmeni behem strankovani, stejny
problem je i v pripade, kdyz to trva dlouho byt v prubehu jednoho
requestu.
Jenom je race-condition mene pravdepodobna.
Doporucil bych nasledujici postup:
1) Klient se registruje na JMS a bude bufferovat zpravy, dokud
neprobehne prvotni inicializace
2) Asynchronne si vyzada data pres REST
3) Server udela kopii/klon/branch dat
4) Server do souboru/db/... nacpe data v predepsanem formatu
5) V ramci async volani vrati data v jednom baliku.
6) Nakonec smahne data
7) Klient doresi inicializaci a odblokuje buffer
Snad to pomuze...
2017-11-16 10:01 GMT+01:00 Ing. Rastislav Siekel <sie...@siera.sk
<mailto:sie...@siera.sk>>:
Ahojte Javisti,
chcel by som sa spýtať, či má niekto praktické skúsenosti s
posielaním veľkého množstva dát ce REST alebo JMS, alebo inak.
Máme aplikáciu, ktorá posiela zmeny dát pomocou JMS. Potrebujeme
dorobiť, aby klient pri inicializácii dostal všetky dáta a potom
bude dostávať už len zmeny.
Napadlo nám viacero riešení:
1. Použiť REST. Ale príprava takého množstva dát môže byť dlhá a
môže nastať timeout. Preto môžeme posielať dáta po stránkach,
kde v každej stránke bude URL na nasledujúcu stránku. Napr.
ako tu:
https://stackoverflow.com/questions/13872273/api-pagination-best-practices.
Tam môže nastať problém čo s dátami, ktoré sa zmenia medzitým.
<https://stackoverflow.com/questions/13872273/api-pagination-best-practices>
2. Použiť JMS - klient si pripraví dočasnú frontu a server mu tam
dáta pošle cez JMS. Po odoslaní dát sa fronta zruší. Tam je
potrebné mať JMS klienta na oboch stranách, ako je to popísané
napr. tu:
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
<http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html>
Nemáte s tým niekto praktické skúsenosti? Použili ste REST alebo
JMS, alebo niečo úplne iné?
Vďaka za každý názor,
Rastislav "Bedo" Siekel.
--
Oto 'tapik' Buchta, ta...@buchtovi.cz <mailto:ta...@buchtovi.cz>,
http://tapikuv.blogspot.com
