[RASSUS] 2. laboratorijska vježba - 2021/2022

in1

rozy Možeš preko dockera, installiraš docker i pratiš ovo: https://developer.confluent.io/quickstart/kafka-docker/. Prva 3 koraka su bitna.

ruza0001

imam vec docker tako da jako najs, hvala tii

saitama

Je li prije generiranja novog ocitanja cvor mora pricekati da primi potvrde za trenutno ?

RogerRoger

laranotreallycroft da, ali blokira thread, što ne?
Imaš thread za slanje svog očitanja ostalim senzorima, kad pošalje paket s očitanjem, stvori novi thread koji čeka potvrdu (jesam dobro shvatio?), ali taj novi thread može zapeti beskonačno dugo ako se potvrda izgubila u mreži.
Metoda receive() nema nikakav timeout parametar, a po defaultu je na socketu postavljeno na inf (blokiranje bez timeouta).

laranotreallycroft

RogerRoger ne ne, za svaku poruku koja se salje se stvara novi thread. Znaci pozovem ovaj StupidUDPClient kao novi thread i onda nek blokira sam sebe kolko hoce u vlastitom threadu. Isti je thread za slanje i cekanje odgovora na poslano.

RogerRoger

laranotreallycroft u redu, tako sam i ja mislio napraviti, ali i dalje me buni ovo.
Ako želiš poslati očitanje, stvoriš jedan novi thread za server koji šalje to očitanje, on ga pošalje, čeka potvrdu jer je blokiran receive() metodom, ali potvrda se izgubila (realan slučaj jer je lossRate 30% po tekstu zadatka). U tom slučaju, on nikad ne dobije potvrdu, nema timeouta, a ako nije dobio potvrdu jer nije ni poslana, tj. zagubio se originalan paket, onda ni druga strana nikad ne dobije poslano očitanje. Kako dođe do retransmisije onda, ako je server cijelo vrijeme blokiran jer čeka potvrdu koja neće doći?

laranotreallycroft

RogerRoger
Server je jedan odvojeni thread koji je zasebno pokrenut i koji slusa kaj mu dolazi i salje odgovore.
Klijent je zaseban thread i vise ih moze biti odjednom pokrenuto jer je to odvojeni thread koji ne blokira main thread koji stvara i salje nova ocitanja niti ne utjece na server thread. Takoder treba implementirat retransmisiju ako ne dobije odgovor, znaci osim ako je cvor koji salje ugasen,dobit ce odgovor prije il kasnije

RogerRoger

laranotreallycroft hvala ti na objašnjenju, al ne kužim i gotovo. Razumijem što želiš reći sa serverom i klijentom, ali ne kužim kako ti radi za sljedeći scenarij: thread (server ili klijent, ovisi kako ga zoveš) pošalje paket, paket se izgubi u mreži, on čeka potvrdu metodom receive(), ne dobije ju jer paket nije primljen, kako on može pokrenuti retransmisiju ako je blokiran receiveom? Kako itko skuži da potvrda nije primljena?

in1

RogerRoger Prva rečenica 5.6 poglavlja:
“Ako čvor ne primi potvrdu za poslani podatkovni promet, ponovno šalje taj podatknovni promet.”

WickyWinslow

RogerRoger
Imaš thread koji sluša za incoming poruke i thread koji šalje poruke. Ovaj koji sluša dolazeće ce ack poruku staviti u necki blocking queue koji ce probuditi thread koji je poslao. Thread koji je poslao i ceka ack radi poll na taj blocking queue.

Googlaj malo i pretrazi na gitlabu DZ sa java vjestine ili sa OPRPP2 predmeta bio je za zadacu chat UDP server i klijent na kojem je trebalo rjesiti istu problematiku.

RogerRoger

in1 okej, nisam debil, kužim to
Ali ako ju očekuje, očekuje ju koristeći receive, jel da
A ako ju ne dobije, ostaje blokiran jer je receive blokirajuć, a socket klasa koju su nam dali je namještena da nema timeout
I što onda, voditi neki dictionary u glavnom programu i samo otvarati novi thread za svaki koji ne primi potvrdu?

adhdd

WickyWinslow gdje se može pronaći taj dio sa predmeta OPRPP2, koliko vidim na materijalima nema ništa?

VelikiMarko

Znači li to da zapravo mi koristimo u ovom labosu samo jedan socket jer vidim da su stavili napomenu da promet potvrda i očitanja treba ići preko samo jednog porta?

WickyWinslow

VelikiMarko Socket po nodeu/peeru, da.

VelikiMarko

Čemu su nam onda dali dva konstruktora za onaj SimpleSimulatedDatagramSocket? Jedan kao za klijentsku stranu, a drugi za serversku.

Erpeg

kako vi inkrementirate vektore ?
jel samo sa slanjem/primanjem ocitanja, ili se tu racuna retransmisija i potvrda ?
i na kako bi trebao sortirati ocitanja po vektorima, to mi uopce nije jasno

Erpeg

isto ne kuzim kako bi trebali implementirat mijenjanje skalarnog vremena
ako mi trenutno vrijeme dohvacamo sa currentTimeMillis() i recimo da je to vrijeme 3 npr, a vrijeme od primljenog paketa je 4, kako cemo mi sad promijenit vrijeme 1. senzora na 5 ?
jer ako ne promijenimo, moze se desit da sljedece ocitanje od 1. senzora bude ocitano u vremenu 4 zbog currentTimeMillis jer ga nismo promijenili

RogerRoger

Erpeg ja sam to implementirao tako da imam fju update() koja prima vrijednost sata i racuna razliku izmedu te nove vrijednosti i this.currentTimeMillis() i onda tu razliku (ako je pozitivna) sprema u privatnu varijablu. Vrijednost te varijable sam samo zbrojio na kraj returna od currentTimeMillis().

sphera

dobivam ovo kad pokrećem zookeeper u cmd-u u 3.3? kako se to rješava?
The input line is too long.
The syntax of the command is incorrect.

sphera

sphera
kafka ne voli duge putanje pa stavite na neke kratke putanje kao u uputi C:\kafka..., druga stvar je da ako ne može nać putanju, ’can’t find path specified’ onda možda imate razmake u putanji java_home-a ili je ta putanja invalidna pa se pobrinite da je validna

narval13068

Kako spojiti vise consumera na kordinator, meni jedan uhvati poruku a drugi ne, isto mi se dogodi s njihovim primjerom kafke s ferneta kad pokrecem dva consumer procesa i jedan producer proces…

burek

Dima To ti se događa jer kafka za istu grupu stvara particije i procesi unutar iste grupe ne mogu čitati iste poruke nego svaki dobije svoj “set”, trebaš za groupid stavit UUID.randomUUID().toString() tako da ti svaki Consumer bude u novoj grupi

Erpeg

Dima
stavi ovo prije .poll ->
<tvoj_consumer>.seekToBeginning(<tvoj_consumer>.assignment());
i ovo nakon neke petlje u kojoj citas ->
consumer.commitAsync();
onda ce ti svi consumeri citati sve poruke

« Prethodna stranica Sljedeća stranica »