|
Programiranje Java, Perl, VB, ASP, .NET, C, C++, Pascal, Delphi Sponzor: |
|
Alati teme | Način prikaza |
19. 05. 2012. | #11 | |
Domagoj Horvat
Expert
|
http://www.cogin.com/articles/IntroductionToMSMQ.php
upravo sam proguglo ali, ne vidim jednu stvar: kako mi MSMQ osigurava da mi se akcija izvrsi u tocno odredjeni trenutak? a koliko vidim, pasus Citat:
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo |
|
19. 05. 2012. | #12 |
Dejan Grujic
Professional
Datum učlanjenja: 29.09.2005
Poruke: 380
Hvala: 9
64 "Hvala" u 40 poruka
|
MSMQ kao ne daje nikakvu garanciju kad će se akcija izvršiti, niti može da se zakaže vreme kad poruka treba da stigne. On je namenjen za druge stvari - kad ti nije bitno kad će se desiti ta druga akcija, ali hoćeš da se sigurno desi, bez obzira da li proces, mreža, baza ili neki drugi resurs trenutno ne rade.
Čini mi se da sam pogrešno shvatio šta tvoj sistem treba da radi, jer sam mislio da je poenta da se preživi veće opterećenje i tu bi MSMQ mogao da igra ulogu. Sad kad sam opet pročitao, deluje mi da imaš proces koji ima nekoliko koraka, i da oni moraju da se dese u određenim trenucima - npr. korak B mora da bude tačno 60s posle koraka A, itd. Tj. tebe muči najpre problem da se svaki korak desi u određenom trenutku, a to što može da se desi da bude 20 događaja u jednoj sekundi je sporedna stvar. Jedno rešenje jeste da upisuješ događaje u bazu, a drugi proces/thread da čita periodično bazu i da gleda šta ima novo. Koliko je to opterećenje za bazu - zavisi od raznih faktora, a može da bude problem ako hoćeš svake sekunde da čitaš, a posle i da radiš update. Ako performanse nisu problem možda ti to nije loše rešenje da ne bi sad uvlačio i MSMQ u priču. Ako performanse jesu problem, može i MSMQ da se primeni u ovom scenariju tako što ćeš npr. u labeli poruke (to je nešto kao subject mail-a) da upišeš kad treba da se izvrši sledeći korak. Drugi proces/thread koji čita poruke gleda samo labelu poruke na vrhu, gleda da li je došlo vreme za nju i ako nije pokušava ponovo sledeće sekunde. To periodično čitanje poruke sa vrha je zanemarljivo opterećenje, naročito pošto po pravilu to čitanje radiš iz lokalnog queue-a. Ovo je primenljivo samo ako svaka poruka može da ide na kraj queue-a, tj. da je situacija takva da uvek treba sve prethodne poruke da se obrade pre ove zadnje. A ako na primer imaš situaciju da u jednom slučaju sledeći korak ide za 60s, a u drugom za 30s onda ne možeš da koristiš MSMQ pošto njemu ne možeš da kažeš "ubaci ovu poruku u pola queue-a, tačno tamo gde joj je mesto". Treća varijanta je da sve to držiš u memoriji i da imaš tajmere koji će da okidaju kad dođe vreme za sledeću poruku. To rešenje ima problem što je osetljivo na restart procesa jer možeš da izgubiš sve operacije koje su trenutno u toku. Četvrto je ovo što si pominjao za Windows scheduler, ali stvarno ne znam kako se ponaša kad mu se preko nekog apija stalno kreiraju i brišu taskovi i kako se nosi sa većom količinom događaja. |
"Hvala" Gruja za poruku: |
19. 05. 2012. | #13 | |||
Domagoj Horvat
Expert
|
da, nisam opisivao cijeli sistem jer mi ostatak radi i nije sporan.
ali je, to je workflow: useri rade subscriptions raznih dogadjaja u buducnosti. sve to zavrsi u bazi. kasnije, drugi proces cita te dogadjaje i odradjuje. ovo sto si naveo Citat:
Citat:
moja dilema je bila bas to sto kazes: Citat:
PS. performanse ovog rjesenja su rjesive tako sto znam da mi se predbiljezba za dogadjaj nece desiti unutar posljednje minute samog dogadjaja. to znaci da mogu komotno staviti da se svakih 45 sekundi iz baze dovlaci lista dogadjaja koje treba odraditi u npr. slijedecih sat vremena. a onda timer ima tick svaku sekundu, dvije, tri (nebitno) i prolazi kroz listu dogadjaja i okida one kojima je dosao cas.
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo |
|||
|
|