Coordinator

[korczis]

Features

• Prevent Duplicate Work
• Re-queue Work
  • Crashed Workers
  • Disconnected Workers
  • 429 Too many requests

Implementation

• Do Not Use Couchbase for Sharing Global State
• {crawler, processor, url} => {state, pid}

Braindump

sha({worker, processor, url}) => {state, timestamp}

state = requested | queued | done

scenare

1. Process 1 chce nejakou praci, tak si rekne koordinatorovi.
   Ten zadny takovy zaznam nenajde, tak si ulozi requested a
   zacne process 1 monitorovat.
2. Process 2 chce stejnou praci, tak si rekne koordinatorovi.
   Ten najde zaznam requested, tak si tam zadost prida a zatim neodpovida.
3. Process 1 spadne. Koodinator najde zaznam requested (podle pidu, ktery spadnul)
   , najde v seznamu process 2, tak ho monitoruje a posle mu ok.
4. Process 2 posle praci do rabbita a rekne koordinatorovi, ze queued.
   Koordinator pokud najde zaznam requested, tak vsem ve fronte cekajicich rekne
   ne - prace uz je v queue a vytvori zaznam queued
   Pozn.: Pokud worker spadne mezi tim, co poslal praci do rabbita a tim,
   ze posila koordinatorovi queued, koordinator smaze zaznam requested
   a pokud v te chvili nekdo pozada o stejnou praci, muze bezet 2x. Ale
   to je hodne mala pravdepodobnost (nema proc spadnout).
5. Process 3 chce stejnou praci, ale koordinator rekne ne, protoze queued
6. Worker 1 dostane z rabbita praci, kdyz spadne, rabbit to posle jinam
7. Kdyz worker praci dodela:
   • ulozi praci do cauche
   • rekne koordinatorovi, je prace je done
   • udela ack na rabbit
     Pozn.: Pokud process spadne mezi done a ack do rabbita, rabbit necha praci
     znova spocitat. Ale to se opet bude stavat malokdy.

chovani koordinatora

1. request
   • prace neexistuje -> ok
   • prace je requested -> zaradit do fronty cekajich v requested (pak obvykle vratit no)
   • prace je queued -> no
   • prace je done a neni uz "stary" -> no
   • prace je done, ale je to uz hodne davno -> ok (a chovani jako kdyby tam zadny zaznam nebyl)
   • koordinator spadne - requestor dostane vyjimku a nejak se s tim vyrovna,
     treba taky sam spadne (bud je to nejaky call z clienta, tak ho klient zopakuje,
     nebo je to job z rabbita a rabbit ho requeue)
2. queue
   • nastavit tam zaznam queued, pokud je tam requested od stejneho pidu
   • vratit chybu, kdy tam neni nebo je tam cokoliv jineho - to je bud
     spatne pouziti, nebo koordinator mezi volanimi spadnul. S tim se pak
     musi nejak vyrovnat volajici - treba zkusit opet nejdriv reques
3. done
   • nastavi done v jakemkoliv pripade

Obecne kdyz koordinator spadne, tak se proste prijde o stav a nektere vypocty se muzou spustit
vicekrat. Ale po case se to zase ustali...

[bossek]

Currenly coordinator implements only 'Prevent Duplicate Work' feature. Feature 'Re-queue Work' will be handled by RabbitMQ.